The estimate is wrong because the work is undiscovered
The claim When a software estimate turns out to be half of what the project actually cost, the usual explanation — padding was insufficient, the team was optimistic — misses the me...
The claim
When a software estimate turns out to be half of what the project actually cost, the usual explanation — padding was insufficient, the team was optimistic — misses the mechanism. The estimate was not too low; it was an estimate of a different, smaller project, because most of the real work had not been discovered when the number was produced. You cannot estimate work you have not yet found, and in software the finding is most of the job.
Why software estimates behave differently
Estimating a physical build works because the units are known: a wall of a given length needs a known quantity of materials and a known number of hours, refined over thousands of similar walls. Software has no equivalent, because if a piece of work were truly identical to something done before, you would copy it rather than build it again. Every genuinely new feature is, by definition, work nobody has done in exactly this form, which means the estimate is a forecast about territory not yet mapped.
The consequence is a systematic, one-directional error. Undiscovered work is almost always additional work — an integration that needs an extra step, a rule that has an exception, a screen that is unusable until it is reworked. Discovery reveals things to do, rarely things you can skip. So the error compounds in the direction of underestimation, reliably, across the industry.
The three-point estimate exposes the uncertainty
A single number hides how little is known. Ask instead for three: the optimistic case if everything goes right, the likely case, and the pessimistic case if the hidden work is substantial. A common weighting produces a usable expected value:
expected = (optimistic + 4 x likely + pessimistic) / 6The gap between optimistic and pessimistic is the real output. A feature quoted at "5 to 8 days" is well understood. A feature quoted at "3 to 30 days" is not an estimate — it is an admission that the work is mostly undiscovered, and the correct response is not to average it but to reduce the uncertainty before committing.
Buy down the uncertainty with a spike
When the range is wide, the answer is a time-boxed investigation — a spike — whose deliverable is a better estimate, not working software. Two or three days spent building a throwaway prototype of the riskiest part converts "3 to 30 days" into "we found the two hard problems, it is 9 to 12". You are spending a small, fixed amount to remove a large, open-ended risk, which is almost always a good trade on anything substantial.
This reframes estimation from a one-time guess into a process: estimate coarsely, identify the widest ranges, spend a little to narrow them, re-estimate. The projects that overrun are usually the ones that committed to a firm number and a firm deadline while the ranges were still wide.
Track your own ratio
Every team has a characteristic gap between what they estimate and what work actually takes, and it is stable enough to be useful once you measure it. Record the estimate and the actual for completed work over a couple of months and compute the ratio:
| Work | Estimated | Actual | Ratio |
|---|---|---|---|
| Feature A | 5 d | 8 d | 1.6 |
| Feature B | 3 d | 7 d | 2.3 |
| Feature C | 10 d | 14 d | 1.4 |
A team that consistently runs at 1.7 does not have an estimation problem to be scolded about; it has a known multiplier to apply. Multiply the next estimate by the measured ratio and the forecast becomes honest. This is more reliable than trying to make the raw estimates bigger, because the multiplier captures the undiscovered work empirically rather than asking people to imagine it.
What this means for how you commit
The practical conclusion is to match the commitment to the knowledge. For well-understood work with a narrow range, a firm estimate is fine. For work with a wide range, commit to the spike, not the delivery date — promise to know more in a week, then commit to the delivery once you do. And structure the engagement so that direction can change at short intervals, because the discovery that blows up the estimate is also the discovery that tells you whether the feature is worth finishing at all.
An estimate is a claim about how much is known, disguised as a claim about time. Read the width of the range, not the midpoint, and spend deliberately to narrow it before you turn a forecast into a promise.
