The Planning Fallacy Override
Use base rates from similar projects, not your optimistic inside view
The Planning Fallacy Override is Kahneman's practical tool for correcting the systematic tendency to underestimate how long projects will take, how much they will cost, and how likely they are to succeed. The planning fallacy occurs because people focus on the specific plan for their project (the inside view) rather than the base rate of how similar projects have performed (the outside view).
Kahneman describes overconfidence as the most pervasive and damaging of all cognitive biases. Even when people know that similar projects have taken much longer than estimated, they believe their project will be different. They focus on the specific reasons their plan will work rather than the statistical reality that most similar plans have not worked on schedule or budget.
The override is simple but psychologically difficult: before estimating any project, first look at how long similar projects have actually taken. Use that base rate as your starting point, then adjust based on specific factors that make your project different. This 'reference class forecasting' consistently produces more accurate estimates than traditional planning methods.
- People almost always underestimate project timelines because they focus on their specific plan rather than base rates.
- Even knowing similar projects took much longer, people believe their project will be different.
- Overconfidence is the most pervasive and damaging of all cognitive biases.
- Reference class forecasting -- starting with base rates of similar projects -- consistently beats inside-view planning.
- Identify Your Reference ClassBefore making any project estimate, identify 5-10 similar projects that have been completed by you or others. What was their planned timeline versus actual timeline? What was their planned budget versus actual budget? This outside view provides the base rate that your inside view will systematically underestimate. If you cannot find similar projects, that itself is important information -- it means you are in truly novel territory where all estimates should carry very wide uncertainty bands.Pro tipLook for similarity in project type and complexity, not just industry. A software rewrite is similar to other software rewrites regardless of the specific technology.WarningYour inside view will fight the reference class data. You will think 'But our project is different.' This is exactly the bias the method is designed to correct.
- Anchor on the Base RateUse the actual performance of your reference class as your starting estimate, not your optimistic inside-view plan. If similar projects typically took 2x the planned timeline, start with 2x your initial estimate. If similar projects typically exceeded budget by 40%, build that into your forecast. This feels pessimistic, but Kahneman's research shows it is actually more realistic. The inside view systematically ignores unexpected complications, scope changes, and coordination problems that reference class data captures automatically.Pro tipPresent your estimate as a range based on reference class performance: best case, most likely, and worst case. This communicates uncertainty honestly.
- Adjust from the Base Rate with Specific EvidenceAfter anchoring on the base rate, adjust up or down based on specific, concrete factors that make your project genuinely different from the reference class. Perhaps you have a team that has done this exact type of project before (adjust down). Perhaps you are using untested technology (adjust up). The key is that adjustments must be based on specific, verifiable differences, not vague optimism. Keep adjustments small -- most people overestimate how different their project truly is.Pro tipHave someone who is not emotionally invested in the project evaluate whether your adjustments from the base rate are justified.WarningThe total of all your adjustments should rarely move your estimate more than 25% from the base rate. If it does, you are likely falling back into inside-view bias.
Kahneman was part of a curriculum committee at Hebrew University designing a new textbook. When asked for estimates, team members predicted 18-30 months. Kahneman then asked a colleague who had observed many similar curriculum projects how long they typically took. The answer: 7-10 years, with 40% never completing at all. Despite hearing this, the committee proceeded with their original optimistic timeline.
Kahneman first identified the planning fallacy through his collaboration with Amos Tversky in the 1970s. The personal anecdote that crystallized the concept involved a curriculum committee at Hebrew University that Kahneman was part of. Asked to estimate how long it would take to complete a new textbook, team members estimated 18-30 months. When Kahneman asked a colleague who had observed many similar projects how long they typically took, the answer was 7-10 years, with 40% never completing at all. The committee ultimately took 8 years. Reference class forecasting was later developed by Bent Flyvbjerg at Oxford University as a systematic method for overcoming the planning fallacy in large infrastructure projects.