Estimating Accuracy: Why Projects Are Always Late
Ask any project manager whether they have ever delivered a project on the original estimate, and the honest answer is rarely reassuring. Overruns are so common in construction, software, infrastructure, and government projects that they have become the default expectation rather than the exception. The question is not why individual projects are late — the question is why estimates are so consistently wrong.
The Planning Fallacy
Daniel Kahneman and Amos Tversky described the planning fallacy in 1979: people systematically underestimate the time, cost, and risk of future actions while overestimating the benefits. This bias affects individuals and organisations alike, and it does not diminish with experience. Even people who have lived through multiple overruns tend to believe their next estimate will be more accurate, because they focus on the specific plan rather than on the statistical distribution of outcomes for similar projects.
The planning fallacy is compounded by anchoring. Once a number is in the room — whether from a rough order of magnitude estimate, a client's budget expectation, or a political target — it becomes the anchor around which subsequent estimates are unconsciously calibrated. Detailed bottom-up estimates that arrive at a higher number are often challenged and revised downward, not because the analysis is wrong but because the anchor has more political weight.
Pressure to Win Approval
In organisations where projects compete for funding, there is structural pressure to underestimate. A project with a realistic cost estimate may lose a budget competition to a project with an optimistic one. The optimistic project gets approved, the realistic one does not. Over time, the organisation selects for underestimation. By the time the overrun emerges, the approving executive may have moved on and the project team is too committed to cancel.
Scope Creep and the Missing Unknown Unknowns
Even a perfectly unbiased estimate at project inception faces a structural problem: scope at the start of a project is never fully defined. Unknown unknowns — requirements that are not yet known to be missing — will emerge. Regulatory requirements will shift. Integration with other systems will prove more complex than expected. These are not failures of estimating skill; they are the natural consequence of committing to a number before the full scope is understood.
The Cone of Uncertainty
The Cone of Uncertainty, popularised by Barry Boehm in software engineering, captures this dynamic visually. At project inception, the actual cost or duration could be anywhere from a fraction to a multiple of the initial estimate. As the project progresses and unknowns are resolved — design is completed, vendors are selected, risks are retired — the range narrows. By the time a project is half complete, the final outcome is generally predictable within a much tighter band.
The practical implication is that estimates should be presented with explicit confidence ranges, not as point estimates. An estimate of "$10 million, +40% / -20%" is more honest and more useful than "$10 million" stated as though it were a fact. Sponsors who receive range estimates are better positioned to hold appropriate contingency and make informed go/no-go decisions.
Techniques to Improve Estimates
Analogous estimating — use the actual outcomes of similar completed projects as the baseline. If your last three office fit-outs came in at $X per square metre, the next one will likely be in that range. Historical actuals are humbling and more accurate than bottom-up plans.
Parametric estimating — derive estimates from statistical relationships between project parameters and cost or duration. Software development productivity rates, construction cost indices, and engineering labour norms are all parametric tools.
Bottom-up estimating — break the work into the smallest plannable units, estimate each, and sum. More accurate than top-down methods but time-consuming and still vulnerable to missing scope.
Three-point estimating (PERT) — for each work package, elicit an optimistic estimate (O), a most likely estimate (M), and a pessimistic estimate (P). The weighted average (O + 4M + P) / 6 produces a more calibrated expected value, and the range P - O reflects uncertainty.
Tracking Estimate Accuracy Over Time
One of the most powerful improvements an organisation can make is to systematically track estimate accuracy over time. When every completed project records its original estimate alongside its final cost and duration, patterns emerge. Certain project types, team configurations, or planning approaches produce systematically better or worse estimates. This organisational learning is far more valuable than any estimating technique applied in isolation.
Communicating Uncertainty Honestly
Project managers are often reluctant to present range estimates because they fear appearing uncertain or incompetent. The opposite is true. A project manager who presents a point estimate and then overruns looks like they failed to plan. A project manager who presents a range, explains the assumptions, and then delivers within that range looks like they understood the work. Honest communication of uncertainty is a professional strength, not a weakness.
XNM Consulting supports organisations in building rigorous project planning and estimating capabilities. Learn more on our Program and Project Delivery page.