The planning fallacy is the systematic tendency to underestimate the time, cost, and risk of completing a future project while overestimating its benefits. It is not caused by individual optimism. It is caused by focusing on the specific scenario you have imagined rather than on the historical distribution of outcomes for comparable projects. The correction is reference class forecasting: ask what similar projects actually took, and start from that number.
Where this came from
Daniel Kahneman and Amos Tversky named the planning fallacy in a 1979 paper. Their insight was that the error is not random and not a product of personality. It is a structural feature of how humans plan. When asked to estimate a project, people generate a mental scenario of the project going well, with minor obstacles, and produce an estimate based on that scenario. They do not ask: what is the distribution of outcomes for projects like this one?
Kahneman later described the Sydney Opera House as the canonical example. The project was projected to cost $7 million and be completed in 1963. The building opened in 1973 at a cost of $102 million. The original architect, Jorn Utzon, resigned in 1966 under pressure from the government client. This pattern, large overruns in both time and cost, is not exceptional in large infrastructure projects. Bent Flyvbjerg's research on 258 transport infrastructure projects found that 86% exceeded their budgets, with an average cost overrun of 28%. For tunnels and bridges, the overrun was higher still.
The fallacy is not limited to large public projects. Kahneman documented it in students estimating how long their theses would take, in software teams estimating development cycles, and in individuals planning home renovations. The pattern is consistent across domains and cultures.
How it works
Kahneman identified two perspectives on planning: the inside view and the outside view. The inside view is what planners naturally adopt. It involves constructing a detailed scenario of the specific project, identifying the steps involved, and estimating the time and cost for each. The estimate feels grounded because it is built from detail. It is also structurally biased, because it is built from the optimistic scenario rather than from the distribution of possible outcomes.
The outside view asks a different question: what is the track record for this class of project? Not "how long will my software project take?" but "what is the distribution of completion times for comparable software projects?" The outside view feels less precise because it does not reference the specific project. But it is more accurate because it is based on empirical data rather than on scenario construction.
The reason the inside view dominates is motivational as well as cognitive. People planning a project have a stake in it. They want it to succeed. An honest application of outside-view base rates to a project you care about often produces an estimate that is discouraging or that challenges the business case for the project. There is social and emotional pressure to reject the outside view in favour of the more favourable inside view.
This is why the planning fallacy persists even among people who know about it. Kahneman himself recounted planning a textbook with colleagues, and despite being the person who named the planning fallacy, producing an optimistic estimate that turned out to be wrong by years.
When to use it and when not to
Reference class forecasting is most valuable for projects that are significant, hard to reverse, and involve genuine uncertainty about time or cost. Building a product, launching a business, completing a major qualification, undertaking a renovation. These are the domains where the planning fallacy has the most financial and personal consequence.
For very short or highly repetitive tasks, base rates are easily available from your own experience and the correction is automatic. The fallacy bites hardest on novel or complex projects where the planner has limited personal experience and is constructing an estimate from first principles.
One important nuance: reference class forecasting provides a floor, not a ceiling. If your project has unusual complexity or is being attempted for the first time in your organisation, adjusting upward from the base rate is appropriate. The point is not to apply the average mechanically but to start from empirical data rather than from a hand-constructed scenario.
Inside View
The inside view is the default mode of planning: you construct a detailed scenario of your specific project and derive your estimate from that scenario. It feels rigorous because it is detailed. But it is built on the optimistic pathway through the problem rather than on the full distribution of how similar problems have resolved. The inside view systematically ignores the obstacles, delays, and costs that are common in the relevant reference class but that do not appear in your scenario because you have not imagined them. Switching to the outside view requires a deliberate act of discipline against the natural pull of the inside view.
Run this framework on your actual decision.
DecisionsMatter.ai walks you through a structured 5-step analysis. Your first analysis is free.
How to apply it in practice
For any project where time or cost matters, start by identifying the reference class: the category of comparable projects for which data exists. If you are building a mobile app, the reference class is mobile app development projects of similar scope, not your specific app. If you are writing a book, the reference class is comparable nonfiction books, not this book.
Gather what data you can on how long or how much comparable projects took. Your own past experience is the most relevant source. Published research, industry reports, or conversations with people who have done comparable work are also useful. The goal is a realistic distribution, not a single number.
Take the median or average of comparable projects as your starting estimate. Adjust upward for genuine factors that make your project harder than average. Resist the urge to adjust downward because your project is special, unless you can identify a specific, documented reason why your project is measurably less complex than the reference class.
Finally, build the reference class estimate into your decision. If the outside view says a project like yours typically takes 18 months and costs twice the initial estimate, and the business case only works if the project takes 9 months at the initial cost, that gap is decision-relevant information. It should change either the decision or the business case, not be absorbed and ignored in favour of the inside-view scenario.
This is one model from the upcoming Decisions Matter book.
30 mental models. 40 cognitive biases. A 5-step decision system. Get the relevant chapter in your inbox when it publishes.
Frequently asked questions
What is the planning fallacy?
The planning fallacy, named by Daniel Kahneman and Amos Tversky in 1979, is the systematic tendency to underestimate the time, cost, and risk of completing a future project while simultaneously overestimating its benefits. It is not a matter of individual pessimism or optimism. It is a structural error in how people plan: they focus on their specific scenario and generate an estimate from the inside, rather than asking what the distribution of outcomes looks like for comparable past projects.
How does reference class forecasting fix the planning fallacy?
Reference class forecasting, developed by psychologist Roger Buehler and later formalised by Bent Flyvbjerg, involves identifying a class of past projects similar to yours and using the distribution of their actual outcomes as your baseline estimate. Instead of asking "how long will my project take?", you ask "what is the average completion time for projects of this type, and what was the range?" Your estimate is then anchored to that distribution rather than to your inside-view scenario. Research consistently shows this produces more accurate forecasts than detailed internal planning.
Are there examples of the planning fallacy beyond construction projects?
The planning fallacy appears across domains. Software development projects routinely take two to three times as long as estimated, a pattern so consistent it has its own nickname (Hofstadter's Law). Tax returns, home renovations, academic papers, and business plans all show the same pattern. In personal life, gym regimens, learning projects, and career transitions are routinely underestimated in effort and overestimated in benefit. The bias is domain-general because its cause, the inside view, is a default mode of human planning rather than a specific situational error.
How do you apply reference class forecasting to a personal project?
First, identify the category your project belongs to: software launch, home renovation, career transition, learning a new skill. Second, gather data on how long comparable projects actually took, either from your own past experience or from publicly available records. Third, take the average (or median) as your baseline estimate. Fourth, if your project has features that make it genuinely harder than the average, adjust upward. The key discipline is that you start from the outside view and adjust in, rather than starting from your inside-view scenario and adjusting out. Most people do the opposite.