Planning Fallacy: Ask What Happened to Everyone Else

The first brand identity I ever quoted, I promised in six weeks. It took four months. The second one I promised in eight weeks, having learned my lesson. It also took four months. What puzzled me was not the delay. It was that both estimates had been sincere. I had listed every task, added them up, allowed a little slack, and believed the total.

Daniel Kahneman tells a story about this in Thinking, Fast and Slow. He once led a team writing a school curriculum and asked everyone how long it would take. The answers clustered around two years. Then he asked the one member who had watched similar teams how long they had taken. Seven to ten years, the man said, and around four in ten never finished at all. The team carried on regardless. The curriculum took eight years. Kahneman and Daniel Lovallo later gave the two ways of thinking names: the inside view, which reasons from the details of this case, and the outside view, which reasons from the record of cases like it.

The evidence is almost embarrassing. In 1994 Roger Buehler, Dale Griffin, and Michael Ross published "Exploring the 'Planning Fallacy': Why People Underestimate Their Task Completion Times". They asked students finishing an honours thesis to predict their completion date. The average prediction was about 34 days. The average reality was 55. Even their worst-case estimates, assuming everything went as badly as it could, averaged 49 days, still short of reality. Fewer than a third finished by the date they had named. The remarkable part is not the optimism. A separate survey in the same paper found most respondents admitted their earlier projects had run late too. The memory exists. It is simply never consulted.

You may ask: why does knowing about the pattern not cure it? Because a plan is a story about one project. It has characters, a sequence, a happy ending, and no base rate. The record of every other project like it is a different kind of knowledge, and the inside view never consults it.

That is where reference class forecasting comes in, and its proving ground was large and expensive. In his account of putting the method into practice, Bent Flyvbjerg describes forecasting the cost of transport projects not from their own budgets but from the recorded overruns of hundreds of comparable projects, a record in which rail projects had run, on average, about 45 percent over budget for decades. The method became official guidance for British transport planning. I would be careful with that evidence, though. It shows the method is sound, not that your kitchen renovation behaves like a tram line. You have to build your own reference class.

This is not anchoring either. Anchoring is a number that arrived first and pulled your estimate toward it. The planning fallacy needs no outside number at all. You generate the hopeful figure yourself, from the inside.

Here is the worksheet I use now. It does not make me a better estimator. It makes me consult a record I would otherwise ignore.

1. State the forecast as a number with a unit. Weeks, dollars, hours. A vague plan cannot be wrong, which is exactly why it is dangerous.
2. Choose a reference class you can actually count. Not projects like yours in spirit, but a category with members: your last five client projects, the launches your team has shipped.
3. Write down what actually happened. For each case, the real duration, cost, or outcome, not what it was supposed to be. Five honest cases beat fifty imagined ones.
4. Read the distribution, not the best case. Where does the typical case land? Where does the worst quarter land? Put your inside-view number on that line.
5. List why this case is different, then test each reason. Would the people in your reference class have said the same thing about theirs? Most of them did.
6. Set a range and a trigger. A forecast is a range with a date attached. If by the midpoint you are behind the class's usual pace, you re-plan then, not at the deadline.
7. Record it before the outcome. Put the range, the class, and your reasons in a decision journal. The planning fallacy's last trick is to make the overrun look like bad luck afterwards.

Run my third identity project through it. Inside view: six weeks, again. Reference class: my own last five identity projects, which took 11, 14, 17, 9, and 16 weeks. Typical case, 14. Fastest ever, 9. My reason this one was different: a smaller client with fewer people to sign things off. The 9-week project had that too, and it still took 9. So the range became 10 to 16 weeks, with a trigger at week five: if the brief was not signed off by then, we were on the 16-week path. It took 13. For the first time, the delay sat inside my plan instead of outside it.

The outside view pairs naturally with a premortem. A premortem analysis asks how this project failed. The outside view asks how long it took everyone else. One finds the risks. The other sizes the time. And when there is no reference class at all, no comparable case anywhere, you are not estimating anymore. You are deciding without enough information, which is a different problem.

This is where ClearMind fits, quietly. It will not hand you a deadline, because it does not know your reference class. It works as a mirror: it puts your inside-view story next to the record you gathered, asks which of your exceptions would survive the class, and keeps the forecast where hindsight cannot reach it. The commitment stays yours.

A farmer does not forecast the harvest from the seed in his hand. He asks what the field gave last year, and the year before that.

Your plan is a story about one project. The outside view is the record of all the others.