Planning Fallacy
🇳🇴PlanleggingsfeilslutningDefinition
The planning fallacy is the systematic tendency to underestimate the time, costs, and risks required to complete a task or project – even when we have direct experience with similar tasks that took longer than expected. First identified by Daniel Kahneman and Amos Tversky in 1979, the fallacy occurs because we plan based on an idealized 'inside view' of the specific project (imagining the best-case scenario) rather than the 'outside view' of how similar projects have actually performed. The result is chronic optimism that persists despite repeated evidence to the contrary.
Real-world example
The Sydney Opera House was originally estimated to be completed in 1963 at a cost of $7 million. It was finished in 1973 at a cost of $102 million – a tenfold cost overrun and a decade late. This is not an anomaly: a study by Bent Flyvbjerg of over 250 major infrastructure projects found that 90% exceeded their budgets, with an average overrun of 28%.
In software development, the planning fallacy is endemic: a study by the Standish Group found that the average software project takes 222% of the originally estimated time. Developers focus on the coding itself (the 'inside view') while underestimating debugging, integration, testing, documentation, and unexpected requirements changes.
Even in daily life, the fallacy persists. When students are asked to predict when they will finish their thesis, their 'realistic' estimates are almost as optimistic as their 'best-case' estimates – and both dramatically underestimate actual completion time. The median student finished weeks after their 'worst-case' prediction.
Supplementary perspective
The planning fallacy is powered by several interacting biases: optimism bias (expecting things to go well), overconfidence (believing we can execute better than average), and anchoring on the initial plan. Kahneman's key insight was the distinction between the 'inside view' (focusing on the specifics of your project) and the 'outside view' (looking at base rates for similar projects). The cure he proposed – reference class forecasting – means asking: 'How long did projects like this actually take?' rather than 'How long will my project take?' This approach has been adopted by the UK Treasury and the Danish government for major infrastructure projects, significantly improving accuracy.
Practical advice
Recognize
- —When your plan assumes everything goes smoothly – no delays, no surprises, no scope changes – recognize that this is the planning fallacy at work.
- —Compare your estimate to how long similar past tasks actually took, not how long you planned for them to take.
- —Notice whether your 'realistic' estimate feels suspiciously close to your 'best case' estimate.
Counteract
- —Use reference class forecasting: find 5–10 comparable completed projects and use their actual durations as your baseline.
- —Apply the 'multiply by pi' heuristic: take your initial estimate and multiply by approximately 3 – this rough rule often produces more accurate forecasts than unaided intuition.
- —Build explicit contingency buffers (typically 20–50% of estimated time) and treat them as part of the plan, not as optional padding.
- —Break projects into smaller milestones with independent deadlines – large, monolithic deadlines hide accumulating delays.
Ethical use
- —Present honest timelines and cost estimates even when optimistic ones would be more appealing – trust is built on accuracy, not wishful thinking.
- —In leadership, reward realistic planning rather than punishing 'conservative' estimates, which incentivizes the planning fallacy.
- —When communicating plans to stakeholders, include explicit ranges (best case, likely case, worst case) rather than single-point estimates.