You have built this kind of report a dozen times, and it has never taken less than a week. Yet when someone asks how long the next one will take, “three days” comes out of your mouth. That gap has a name. The planning fallacy is the tendency to underestimate how long your own task will take, even when you know that similar tasks in the past ran late. Daniel Kahneman and Amos Tversky named it in 1979, and later experiments showed how stubborn it is: in one study, students expected to finish their theses in about 34 days and took about 56.
The fallacy is not a lack of information. It comes from how we build forecasts: we picture the plan going right and set aside what happened last time. The fixes with the best evidence behind them bring that outside evidence back into the estimate. Below you will find the original research, real examples, why it happens, how it differs from optimism bias, and six ways to correct for it.
What is the planning fallacy?
The planning fallacy is a prediction bias: people expect their own tasks and projects to finish sooner (and often cheaper) than they do, while knowing that most comparable efforts overran. Two features set it apart from plain bad estimating:
- it concerns your own work, since people asked to predict someone else’s completion time are not optimistic in the same way;
- it persists even though you have the evidence, so the problem is how you use your track record, not whether you have one.
The term comes from Daniel Kahneman and Amos Tversky’s paper “Intuitive prediction: Biases and corrective procedures”, published in TIMS Studies in Management Science (vol. 12, pp. 313 to 327) in 1979. An earlier version circulated as a 1977 Decision Research technical report and was reprinted in the 1982 book Judgment Under Uncertainty, which is why you will see both dates cited. In 2003, Dan Lovallo and Kahneman widened the idea in Harvard Business Review to cover cost overruns and benefit shortfalls, not only time.
So, according to Kahneman, the planning fallacy describes forecasts that are close to best case scenarios and that ignore the actual outcomes of similar projects.
What the research shows
The thesis study (Buehler, Griffin and Ross, 1994)
The best known experiment comes from Roger Buehler, Dale Griffin and Michael Ross, published in the Journal of Personality and Social Psychology (vol. 67, no. 3, pp. 366 to 381). They phoned 37 psychology students in the final semester of their honors thesis course at the University of Waterloo and asked when they would submit the thesis. Each student gave a best estimate, an estimate “if everything went as well as it possibly could” and one “if everything went as poorly as it possibly could”. The course coordinator recorded the real submission dates. Four students had still not finished when records stopped, so the comparison covers the rest.
| Prediction | Predicted days | Actual days | Finished by the predicted date |
|---|---|---|---|
| Best estimate | 33.9 | 55.5 | 29.7% |
| If everything goes well | 27.4 | 55.5 | 10.8% |
| If everything goes poorly | 48.6 | 55.5 | 48.7% |
The striking row is the last one. Even when students imagined everything going wrong, fewer than half finished by that date. The estimates were not random, though: predicted and actual times were strongly correlated (r = .77). People knew which theses were bigger. They just shifted the whole scale toward optimism.
The same paper tested a fix. In Study 4, 123 students predicted when they would finish a computer assignment of about one hour. A control group simply predicted. A second group first recalled similar past assignments. A third group recalled them and then answered questions linking those experiences to the current task. Only that third group got it right: it predicted 7.0 days and took 7.0 days, and 60% finished by their prediction, compared with 29.3% in the control group. Remembering the past was not enough. Connecting it to the task at hand was what helped.
Kahneman’s own curriculum project
In Thinking, Fast and Slow (2011, chapter 23), Kahneman describes a team he led that was writing a high school curriculum in Israel. Asked how long it would take, team members estimated between one and a half and two and a half years. Kahneman then asked the curriculum expert on the team, Seymour Fox, how long similar teams had taken. Fox’s answer: many teams never finished, and those that did took about seven to ten years. The team carried on anyway. The book took eight years, and by the time it was done the ministry had lost interest, so the curriculum was never used.
Planning fallacy examples
In a project
Say your company built a three story house last year. Each floor took two months, and heavy snow added a week, so the whole job took six months and a week. Now you are planning an identical house. It is summer, so no snow is expected, and the crew knows the design, so you set a five month deadline. Each argument sounds reasonable, but together they throw out the only hard data you have. The previous job also had problems nobody predicted; next time the surprise will simply be different, such as a late delivery or a sick foreman.
In public megaprojects
Buehler and his colleagues opened their 1994 paper with two famous cases. The Sydney Opera House was estimated in 1957 to be finished early in 1963 for $7 million; a scaled down version opened in 1973 at a cost of $102 million. In Montreal, the stadium for the 1976 Olympics was meant to have a retractable roof; the roof was not in place until 1989, 13 years late, and cost $120 million on its own. Large projects add a second force on top of the bias: planners may present optimistic numbers on purpose to win approval, which Bent Flyvbjerg calls strategic misrepresentation.
In everyday work
It shows up at smaller scale every day: the “quick” email that takes an hour, the bug fix that touches four modules, the report that needs one more round of review. Each time, the estimate described the plan, and the actual time described what happened.
Why the planning fallacy happens
Research points to a few mechanisms that work together.
- We take the inside view. When we forecast, we build a story of how this specific task will unfold, step by step. Buehler’s think aloud studies found that people focused mainly on future scenarios and rarely mentioned past experiences. Kahneman calls this the inside view; the outside view asks how long tasks of this kind usually take.
- We explain away past delays. In the same studies, participants attributed earlier overruns to causes that were external, temporary and specific (“the printer broke”, “I got sick”). Each excuse makes the past look irrelevant to the next task.
- We want to finish early. The more we care about a quick result, the easier it is to believe in one.
- Others want a low number. Clients, sponsors and managers reward short estimates. Sometimes that pressure leads to deliberately low bids, and sometimes it works more quietly, with people persuading themselves before they persuade anyone else.
None of this means the planner lacks skill. Experienced people fall into it too, because the bias sits in how forecasts are produced, not in what the forecaster knows.
Planning fallacy vs optimism bias and other biases
Optimism bias is the broader tendency to expect good outcomes for yourself, from health to career to investments. The planning fallacy is a specific form of it that concerns time, cost and benefit forecasts for tasks and projects. Several other biases make project estimates worse:
- Anchoring bias is giving too much weight to the first number you hear. If a client mentions “about two weeks” before you have looked at the scope, your estimate tends to land near two weeks.
- Availability heuristic is judging by the examples that come to mind fastest. One project that went smoothly is easy to recall; the five that ran late blur together.
- Attentional bias is focusing on some factors and ignoring others, for example estimating the volume of work and overlooking how complex it is.
- Confirmation bias is noticing evidence that supports the estimate you already like and discounting evidence against it.
These shortcuts exist because they save effort on everyday decisions. The trouble starts when we use them for decisions that need slow, deliberate thinking, and a project estimate is one of those.
What the planning fallacy costs a project
An unrealistic deadline leaves two options: the team works overtime to hit it, or the project slips. Overtime has a direct cost, and long stretches of it tire people out. Slipping brings cost overruns, unhappy clients and lost trust, and on fixed price work it eats the margin directly. Underestimation is also one of the usual suspects when you look at why projects fail. If your projects overrun again and again, the issue is probably in how the estimates are made rather than in how the work is done.
How to avoid the planning fallacy
Knowing about the bias does not switch it off. What helps is changing the process so that outside evidence enters the estimate before you commit to a number.
-
Take the outside view first.
Before you think about this project’s details, ask how long similar projects actually took. Kahneman and Tversky’s corrective procedure starts by choosing a reference class of comparable cases, and Bent Flyvbjerg turned it into reference class forecasting for large projects. Start from the typical result of the reference class, then adjust for what makes this project different.
-
Connect past projects to the current one.
In Buehler’s Study 4, recalling past tasks did not help on its own. What removed the bias was asking how those experiences applied to the task at hand. In a planning meeting, ask: “Last time this took twice as long. What is different now, and why?”
-
Get an estimate from someone who will not do the work.
In Buehler’s Study 5, observers predicting other people’s completion times were not optimistic; they overestimated and used past experience more. A colleague’s estimate is a useful check on yours. Estimating as a team, with techniques such as planning poker, works on the same principle, as long as people do not simply agree with the most senior person.
-
Break the work into smaller tasks.
A detailed work breakdown structure surfaces steps that a single big estimate hides, such as reviews, handoffs and testing. It does not remove optimism from each small estimate, so combine it with the outside view.
-
Add buffers based on your own overrun rate.
If your last ten projects ran 30% over on average, a 10% buffer is still optimism. Size contingency from your own history, and keep it visible in the plan rather than hidden in task estimates.
-
Track actual time and compare it with the estimate.
The outside view needs data. If nobody records how long tasks really took, every new estimate starts from memory, and memory flatters. Tracking time against task estimates gives you a reference class built from your own team’s work.
The last step is where a time tracker earns its keep. In actiTIME you set an estimate in hours for each task, your team logs time in timesheets or the mobile app, and the Estimated vs. Actual Time Report shows the variance by task, project or person. After a few projects, you know your real overrun rate instead of guessing it. For the full estimating process, see our guides on time estimation in project management and on making project time estimates more accurate.
FAQ
What is the planning fallacy according to Kahneman?
Kahneman and Tversky described it in 1979 as the tendency to make forecasts that are close to best case scenarios while ignoring the actual outcomes of similar past projects. Kahneman later explained it as relying on the “inside view” of a project’s plan instead of the “outside view” of how comparable projects turned out.
Who coined the term planning fallacy?
Daniel Kahneman and Amos Tversky, in “Intuitive prediction: Biases and corrective procedures” (TIMS Studies in Management Science, 1979). An earlier version appeared as a 1977 technical report, so some sources date the term to 1977.
What is a real example of the planning fallacy?
The Sydney Opera House was estimated in 1957 to be completed early in 1963 for $7 million. A scaled down version opened in 1973 and cost $102 million. In a controlled study, students predicted they would finish their theses in 33.9 days on average and took 55.5 days.
What is the difference between the planning fallacy and optimism bias?
Optimism bias is the general expectation that good things are more likely to happen to you than to others. The planning fallacy is a narrower form that applies to forecasts of how long a task or project will take and what it will cost.
Is the planning fallacy a cognitive bias?
Yes. It is a systematic error in judgment that shows up across people, tasks and settings, from student assignments to infrastructure projects. Other cognitive biases that affect estimates include anchoring, the availability heuristic and confirmation bias.
What are the main causes of the planning fallacy?
Research by Buehler and colleagues points to two main causes: people build forecasts from a plan of how the task will go instead of from past experience, and they explain earlier delays as one off events that do not apply to the next task. Motivation to finish early and social pressure for low estimates make both worse.
How can you avoid the planning fallacy?
Start from how long similar projects actually took (the outside view), connect those cases explicitly to the current one, ask someone not doing the work for an estimate, break the work down, size buffers from your own overrun history and track actual time so you have that history.
Did Alexander Graham Bell say “Before anything else, preparation is the key to success”?
The line is widely credited to Bell, but its source is unclear. Wikiquote cites only a 2005 book, Sophia’s Fire, published more than 80 years after Bell died in 1922, and we could not find the quote in any source from Bell’s lifetime. Treat the attribution as unconfirmed.
Conclusion
The planning fallacy is not cured by trying harder to be realistic. It is corrected by starting from what similar work actually took and by keeping the records that make that possible.
actiTIME lets you set task estimates, track time against them and see the variance in one report, so your next estimate starts from your own data. Start a free 30-day trial, or book a demo if you want a walkthrough.
