Planning Fallacy: Why Everything Takes Longer Than You Think

What is the planning fallacy?

The planning fallacy is the habit of underestimating how long your own tasks will take and how much they will cost, even though you have seen similar tasks run over many times. It is why projects run late, renovations go over budget and “a quick weekend job” eats a month.

What makes it a fallacy, not just bad luck, is that the information to estimate better is usually available. You know your last three projects ran late. You plan the fourth one the same way anyway.

The reason is the way you build an estimate. You picture the steps of this specific project, one after another, assuming each goes roughly to plan. Kahneman called this the inside view. It leaves out the things you cannot picture yet: the illness, the dependency that slips, the requirement nobody mentioned, the review that sends you back a week. Any one of them is unlikely. Some of them, together, are close to certain.

Where does the planning fallacy come from?

Daniel Kahneman and Amos Tversky introduced the term in 1979, in a paper on intuitive prediction and the procedures that can correct its biases. Their point was that forecasters focus on the specifics of the case in front of them (singular information) and neglect what is known about the class of similar cases (distributional information).

Kahneman later told a story about himself in Thinking, Fast and Slow (2011). He was on a team writing a school curriculum. When the team estimated how long it would take, the answers clustered around two years. He then asked a member with experience of similar projects how long other teams had taken. The answer was that many never finished, and those that did took far longer than two years. The team carried on with its plan anyway, and the project took around eight years. Kahneman uses the story to show that even people who study the bias fall for it.

Later research confirmed the pattern:

• Roger Buehler, Dale Griffin and Michael Ross (1994) asked students to predict when they would finish their thesis and other assignments, including a “worst case” estimate. Most students took longer than they predicted, and many took longer than their own worst case.
• Bent Flyvbjerg, a planning researcher at Oxford, has documented cost and schedule overruns across large infrastructure projects and developed reference class forecasting as a practical correction, building on Kahneman and Tversky’s work.

The Sydney Opera House is a classic example often used in this literature: it opened about a decade later than planned and at many times its original budget.

How to beat the planning fallacy

The fix is to start from the outside view (what usually happens) and only then adjust for your specifics.

1. Pick a reference class. Find a group of past projects similar to yours: your own last five launches, other teams’ migrations, renovations of similar houses. Your own history counts and is often the most useful.
2. Get the real numbers. For that class, how long did they actually take and what did they actually cost, compared with plan? This is the base rate, and it is the anchor for your estimate.
3. Start your estimate there. If similar projects usually ran 50% over, your starting estimate is plan plus 50%, not plan.
4. Adjust a little, with reasons. Only then consider what makes your project different. Be strict: “this time we are more motivated” is not a reason. “This time the design is already done” might be.
5. Run a pre-mortem. Imagine the project is late and over budget, and write down why. A pre-mortem surfaces the specific risks your inside view skipped.
6. Add a buffer and protect it. Add a margin of safety to time and money, and do not let it get spent on scope creep.
7. Record the estimate and the result. Write down your estimate before you start and compare it with the actual at the end. In a year, you will have your own reference class.

3 real-world examples

Business

Say a software team plans a database migration for six weeks. Each engineer can see exactly what they need to do. Nobody adds time for the vendor’s slow support responses, the data quality issues, the security review or the two people who go on holiday. The migration takes fourteen weeks. A reference class check would have asked: how long did our last three migrations take compared with plan? The planning fallacy is on the Mentarium Bias Radar for business decisions, next to overconfidence and the sunk cost fallacy, because the three often travel together on late projects.

Personal life

You decide to renovate a kitchen. The contractor says eight weeks, and you plan your life around ten to be safe. But ask friends who have renovated kitchens how long theirs took versus the quote, and you will likely hear numbers well above the plan. The honest estimate starts from what happened to them, not from the contractor’s schedule.

Tech

A developer estimates a feature at “two days.” It needs a new API endpoint, a UI change and tests. The coding takes two days. The code review, a broken test in an unrelated module, a design change after a demo and a deploy issue take five more. Experienced engineers often multiply their gut estimate by a fixed factor learned from their own history. That is reference class forecasting in its simplest form.

Common mistakes

• Thinking a more detailed plan fixes it. More detail means more inside view. A thicker plan often feels more certain while being just as optimistic.
• Using best case as the estimate. If everything going right is the only path to the deadline, the deadline is a wish.
• Ignoring your own history. Your record is the best reference class you have. Most people never write it down.
• Letting the buffer fill. Work expands to fill the time available, as Parkinson’s law says. A buffer that gets spent on extra scope is not a buffer.
• Confusing ambition with forecasting. An aggressive target can be useful for motivation. Just do not plan budgets, launches or promises to customers around it.

Planning fallacy vs overconfidence bias

The planning fallacy is often described as a special case of overconfidence. The difference is in focus.

Both are corrected the same way at root: write predictions down and compare them with outcomes.

The Mentarium take

The planning fallacy is the most forgivable bias on our list and one of the most expensive. Forgivable, because optimism is part of what gets people to start hard projects at all. Expensive, because every promise, budget and hire downstream is built on the estimate.

Our view is that the fix is not “be more pessimistic.” Pessimism is just a different guess. The fix is to start from data: what happened to projects like this one. In the Mentarium Decision Loop, this is a Stress-test step: before you commit to a timeline, check it against a reference class and run a pre-mortem.

This is also a place where an AI assistant is a good partner, because it will not share your attachment to your own plan. Mentarium Thinking Skills includes reference class forecasting and the pre-mortem as skills for Claude and ChatGPT, so you can hand it your plan and ask for the outside view before you promise a date.