Same six months, opposite verdicts
Two teams build the same thing. Both deliver in six months. Both write solid code, hit the same surprises, ship something that works.
Team A estimated six months. They’re heroes — on time, on budget, trust intact.
Team B estimated three. They’re a failure — “twice over budget,” “three months late,” the cautionary tale in the post-mortem. And here’s the cruel part: Team B felt like failures by month five, grinding through the back half of a perfectly good project under a cloud, judged against a number someone said out loud before anyone had written a line of code.
Same work. Same outcome. Opposite verdicts. The variable wasn’t execution. It was the estimate.
The estimate becomes the yardstick
We like to think projects are judged on what they deliver — working software, business value, happy users. In practice, they’re judged against the estimate. And the estimate is made at the exact moment we know the least about the work, then quietly promoted to the standard everything else is measured against.
Steve McConnell named how little we know at that moment: the Cone of Uncertainty. At the initial-concept stage, a software estimate can be off by as much as 4x in either direction — a 16x spread from the low end to the high end. Then we take the most optimistic point on that enormous cone, put it on a slide, and spend the rest of the project being measured against it.
McConnell’s own framing is the one most teams skip:
The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.
An estimate is a feasibility check, not a promise. We keep treating it as a promise.
Why the three-month estimate happens
Team B didn’t lie. They fell into the best-documented trap in forecasting: the planning fallacy, named by Daniel Kahneman and Amos Tversky. Left to our own devices we take the “inside view” — we picture the work going well, imagine the happy path, and quietly assume that this time nothing will go sideways. It always goes sideways.
In Delusions of Success (Harvard Business Review, 2003), Dan Lovallo and Kahneman showed this isn’t a personal failing — it’s systematic. Optimism, anchoring, and plain organizational pressure combine to produce forecasts that are reliably too rosy. Add a client who wanted to hear “three months,” and the anchor is set. The lowball isn’t malice. It’s the default human error, rewarded.
The base rates are brutal
If estimates were usually right, none of this would matter. They aren’t.
The often-cited Standish CHAOS data found that, historically, only about one in six software projects came in on time and on budget; even the friendlier recent numbers hover around a third. Bent Flyvbjerg — Oxford’s megaproject expert — went bigger: in a database of more than 16,000 projects, only 8.5% hit both their cost and schedule estimates, and a vanishing 0.5% also delivered the benefits they promised.
Missing the estimate isn’t the exception. It’s the base rate. Which means any process that grades teams against the estimate is, statistically, a machine for manufacturing “failures” out of ordinary work.
The fix is the outside view
The cure is unglamorous and well-proven. Flyvbjerg calls it reference-class forecasting; Kahneman calls it the outside view. Stop treating your project as a unique snowflake and ask the only question that predicts well: how long did projects like this actually take? Start from that base rate and adjust — instead of starting from a hope and adding nothing for the reality every past project ran into.
For software, in practice:
- Estimate in ranges, not points. “Five to eight months” is honest; “six months” is theater. Narrow the range as the cone narrows.
- Separate the three numbers. The estimate (what it will likely take), the target (what you’d like), and the commitment (what you’ll promise) are three different things. Collapsing them into one optimistic figure is where projects go to die.
- Anchor on history, not hope. What did the last three things like this actually take? Start there.
The part that actually matters
The schedule is recoverable. The morale usually isn’t.
The quiet damage in Team B’s story isn’t the extra three months — it’s that a good team doing good work was made to feel like a failure, for months, against a number that was wrong before they started. That’s how you burn out the people who could have carried the project, and it’s why so many “troubled” projects we’re called into weren’t built badly at all. They were estimated badly — sold on a figure nobody could hit, then thrashed trying to defend it.
A real estimate is a deliverable, not a formality. We’d rather hand you an honest six than a flattering three — because the flattering three doesn’t make the work go faster. It just converts a success into a failure, and a strong team into a demoralized one.
Software that’s too important to get wrong includes the part where you say how long it will take.
Sources & further reading
- D. Lovallo & D. Kahneman, Delusions of Success: How Optimism Undermines Executives’ Decisions, Harvard Business Review (2003) — hbr.org
- D. Kahneman, Thinking, Fast and Slow (2011) — the planning fallacy and the inside/outside view (Kahneman & Tversky, 1979)
- B. Flyvbjerg & D. Gardner, How Big Things Get Done (2023) — reference-class forecasting
- S. McConnell, Software Estimation: Demystifying the Black Art (2006) — the Cone of Uncertainty
- The Standish Group, CHAOS Report (widely cited industry data; treat as directional)
Facing this yourself? See our related service →