Estimates fail for structural reasons, not because people are bad at guessing. What separates a defensible estimate from an optimistic one.
Every experienced buyer of software has been burned by an estimate. The instinct afterwards is to demand firmer numbers, which usually makes things worse — a firmer number on the same information is just a more confident guess.
It is more useful to understand why estimates fail, because the failure modes are consistent.
The work you can see is not the work
Estimates are built from described features. Delivery includes everything nobody described: error states, permissions, migration of existing data, the integration whose documentation is wrong, and the compliance requirement that surfaces in month two.
This is not padding. It is the difference between a feature list and a working system, and it is routinely a large share of the effort.
Optimism compounds along the chain
An engineer estimates the good-path version of a task. A lead rolls several of those up. A manager presents the roll-up to a client who has already formed a budget expectation.
At no point does anyone lie. But optimism at each layer compounds, and the number that reaches the client is the most optimistic reading of the most optimistic inputs.
What a defensible estimate contains
A range rather than a point. A single number communicates a precision that does not exist, and everyone downstream treats it as a commitment.
Stated assumptions. What is assumed about data quality, API availability, decision turnaround and access. When an estimate overruns, it is almost always because one of these was wrong — and unwritten assumptions cannot be checked in advance.
A phase boundary. What is included, and explicitly what is not.
Questions that expose a weak estimate
"What are you assuming about our existing data?" — if the answer is vague, migration effort has not been considered.
"What would make this take 50% longer?" — a good estimator answers immediately, because they already thought about it. Silence means the risks have not been examined.
"What is explicitly out of scope?" — an estimate with no exclusions has not been scoped, only priced.
Phasing beats precision
The most reliable protection is not a better estimate but a smaller commitment. Eight to sixteen week phases, each ending in something usable, mean an estimate only has to hold for one phase at a time.
You also get real information: after phase one you know how this team estimates against this codebase, which is worth more than any amount of upfront analysis. And you keep the option to stop.
