The Planning Fallacy

Almost every project runs late. Almost every budget overruns. Almost every renovation takes longer than the contractor promised. This isn't random variation — it's a systematic bias with a name.

The planning fallacy, first identified by Daniel Kahneman and Amos Tversky in 1979, describes the universal tendency to underestimate how long tasks will take, how much they will cost, and how many obstacles will arise — while overestimating the benefits when complete.

## The Inside View Problem

The core mechanism is what Kahneman calls inside view thinking. When we plan a project, we focus on the specifics: what steps are involved, what could go wrong in each step, how we'll handle those problems. This feels thorough. But it's actually a trap.

The inside view creates optimism because it forces you to imagine a plausible path to success. You imagine the steps going well. You think of some problems but not all problems. You generate a picture of a project going reasonably smoothly, and that picture becomes your estimate.

The outside view looks different. Instead of asking "how will this specific project go?" you ask "how do similar projects usually go?" The reference class of comparable past projects — software launches, construction timelines, research programs — gives you an empirically grounded baseline.

When Kahneman tracked a curriculum design project in Israel, the team estimated 2-3 years to completion. When asked how long similar projects had typically taken, even the team's own expert acknowledged: 7-10 years, if they're ever finished at all. The project took 8 years.

## Why We Don't Learn

If the planning fallacy were just optimistic thinking, we'd learn from experience. But the evidence suggests we don't — not reliably. People who have run over budget and time on multiple projects continue to underestimate on the next one.

Several mechanisms reinforce this. Motivated reasoning: we want to believe the project will succeed, and pessimistic estimates feel defeatist. Scope creep: projects aren't static; new requirements get added, which moves the goalposts. Sunk cost: as projects drag on, quitting feels worse than continuing even when the evidence is bad.

There's also a competitive dynamic in organizations. Pessimistic estimates lose bids and resources. The person who promises the project in six months gets the work; the person who says eighteen months doesn't. The incentive structure rewards optimistic forecasting.

## Reference Class Forecasting

The practical fix is reference class forecasting, developed largely from Kahneman's work. Steps:

1. Identify a reference class of similar past projects.
2. Determine the distribution of outcomes for that reference class.
3. Use your specific project's features to adjust the baseline estimate (inside view inputs as adjustments, not starting points).

This sounds mechanical, but the discipline of finding the reference class is most of the work. "Building a software product" is too broad. "Startup building a B2B SaaS product with 3 engineers, initial MVP target, no prior product experience" is specific enough to find genuine comparable outcomes.

The painful insight from forecasting research: for the majority of novel projects, the most likely outcome is somewhere between "significantly late and over budget" and "never finished." The optimistic outcome — on time, on budget, as specified — is the tail of the distribution, not the center.

Knowing this doesn't make planning easy. But it does make honest estimation more defensible when the realistic estimate gets rejected for being too pessimistic. The reply is: this is what comparable projects actually look like. What's your evidence for believing this one will be different?

The Planning Fallacy

// COMMENTS

ON THIS PAGE