🧠 Thinking, Fast and Slow · ch.9 · the planning fallacy
🧠 Chapter 9 · Part III — Overconfidence

Everything takes
longer

You have never once finished the thing in the time you wrote down, and your next estimate is due Thursday. The bug is that a plan is a story about the best case — and the fix is one query you keep refusing to run: what happened to everyone else who tried this?

1The textbook that took eight years

Kahneman once assembled a team to write a textbook — on judgment and decision making, of all subjects. A year in, with real progress made, he asked everyone to privately write down how long the rest would take.

The estimates clustered tightly: about two more years, everyone said. Then Kahneman turned to Seymour, the team's curriculum expert — a man who had watched many such teams — and asked a differently shaped question: think of teams like ours. How did they do? Seymour went quiet, then reported the numbers he'd been carrying around all along: roughly 40% of those teams never finished at all. The ones that did took seven to ten years. And, he added, our team was if anything slightly below that group's average.

Here's the detail that makes the story a chapter instead of an anecdote: Seymour had just written "two years" on his own slip of paper. His estimate matched the room's. The statistics sat in his head — complete, damning, and instantly retrievable — and they had exactly zero influence on his forecast until someone asked him for the statistics instead of the forecast. The case and the class lived in separate tables, and nobody had ever written the join.

They finished in eight years. By then the ministry that commissioned the book had lost interest. And — the human part — nobody quit that day. Two minutes after hearing that their project was, statistically, a coin flip stapled to a decade, they went back to work on the two-year plan. The lesson took Kahneman decades to write down.

2Inside view, outside view

What the room did that day has a name: the inside view. You forecast by building a story out of this project's particulars — the plan, the team, the tasks you can name — and you extrapolate the story forward. It feels like diligence. It's every sprint estimate you have ever produced: decompose the ticket into steps you can imagine, size the steps, sum them. The problem is the steps you can't imagine. A story runs on what's visible — WYSIATI, chapter 3's law, applied to your own roadmap. The plan document is the evidence in view; the flu, the reorg, the dependency that turns out to be load-bearing and undocumented — those are by definition not in the story, so the story prices them at exactly zero. Nobody plans the part where the schema migration meets the one table with a decade of soft-deleted rows. That's rather the point of it being the part nobody plans.

The alternative is the outside view: stop asking "how will this project go?" and ask "how do projects like this go?" Find the cases that resemble yours, look at their outcomes as a distribution, and start your forecast from there — treating yourself as one more member of the class, not a special guest. If that sounds familiar, it should: it's chapter 6's base rate, aimed at your own plans. The outside view is nothing more exotic than taking the base rate seriously about yourself — which turns out to be the single hardest audience for it.

Now the formal name for the bug. The planning fallacy: forecasts that hug the best-case scenario, built from an inside story, when consulting the statistics of similar cases would have improved them. Not "plans are bad." Not "padding fixes it" — the textbook team could have padded 50% and still missed by years. The fallacy is specifically the refusal to let the reference class vote.

How long will this migration take? Six weeks — eight with slack. I can see the whole plan from here: schema first, then dual-write, then cutover. Each step is clear, the team knows the codebase, and nothing on the list looks scary. It's a coherent story built from everything visible — and the unknown unknowns are, by definition, not in it. The story has no line item for the surprise, so the surprise costs nothing.

Query the class before trusting the case: the last three migrations here each took a quarter, and not one hit its plan. You are not the exception; you are the reference class. Those teams also saw their whole plan from where they stood.

The transferable habit: estimate = class median × distinctiveness discount — and the discount for "but we're different" is smaller than it feels. It always feels large; that feeling is the inside view talking.

3The dossier of overruns

If the planning fallacy were a quirk of one Israeli textbook committee, it wouldn't rate a chapter. Instead, the case file:

  • The Scottish Parliament building. Estimated in 1997 at up to £40 million. Opened in 2004 at roughly £431 million — about ten times the number the plan believed.
  • Rail projects, worldwide. Bent Flyvbjerg's surveys found that for decades, over 90% of rail proposals overestimated ridership — by more than double, on average — while underestimating cost. The forecasts didn't drift; they leaned, all in the flattering direction, for thirty years.
  • Kitchen renovations. American homeowners expected their remodels to cost about $18,658. They paid about $38,769. No megaproject politics, no rail lobby — just a household, a plan, and a factor of two.
  • And for you: every software migration ever. "Two sprints" is a genre of fiction with a devoted readership. The ticket history that would falsify it sits in the same tracker as the estimate — one saved query away, never queried.

Flyvbjerg's megaproject data is the heavy artillery: across countries, decades, and project types, cost overruns aren't the scandal — they're the norm. The distribution of "similar projects" is sitting right there, published, and each new project's planners look at it the way Seymour looked at his statistics: with full knowledge and no update.

2026 check Plenty of this book's neighborhood took replication damage; this chapter did not. Flyvbjerg's database has since grown past 16,000 projects across 20+ types, and the picture got worse, not better — overruns are fat-tailed, with IT projects among the worst offenders (a meaningful fraction blow their budgets by multiples, not percentages). The planning fallacy is one of the field's sturdiest findings. It replicated embarrassingly well — embarrassing because every replication was itself a funded project that presumably had a plan.

4Reference-class forecasting

The fix is almost insultingly simple, which is why nobody does it. Three moves:

  • 1 · Find the reference class. Projects like yours — not in spirit, in structure. Other kitchen renos. Other 5-person replatforms. Other second novels.
  • 2 · Get its distribution. Average overrun, and the spread around it. Not "did they finish" — how did finishing go, across all of them?
  • 3 · Place your project inside it. Start from the class statistics, then adjust for genuinely distinctive information about your case — and adjust less than you want to. Everyone in the reference class also had distinctive information. It's what made them so confident.

This is now called reference-class forecasting, and it's respectable enough that the UK Treasury and the Danish government mandate versions of it for large infrastructure. For you it's cheaper than that: your last 20 tickets' estimate-vs-actual ratio is a reference class, and you already own it. One query — actual / estimated, averaged — and you have your personal multiplier. If it's 1.8, then "two sprints" is how you pronounce "not quite four." You don't have to feel the correction. That's the entire trick: the outside view works precisely because it doesn't consult your feelings about this particular, obviously-different, definitely-smoother project.

Interactive · plan vs. reference class pick a project · enter the inside-view estimate
weeks
Distributions are illustrative — stylized from published overrun studies, not a live dataset. The shape, alas, is realistic: the mass sits to the right of your plan, and the tail only goes one way.

5Optimism, the engine

Why does a bug this well-documented survive contact with decades of evidence? Because it's load-bearing. Optimistic people found companies, chase grants, start books, volunteer for the migration. The planning fallacy isn't a glitch in the machinery of ambition — it is the machinery, running as designed.

The evidence that optimism ignores verdicts, not just estimates: Canada's Inventors Assistance Program graded inventions on commercial prospects, and its bottom grade — an unambiguous this will fail, stop — was right almost every time. Of the inventors who received it, about half continued anyway, and roughly doubled their losses before giving up. Meanwhile about a third of American small businesses survive five years; founders asked about their own odds say 60% or better — and a third put their risk of failure at exactly zero. Not low. Zero. The base rate was available, personally applicable, and personally inapplicable-feeling.

Part of the mechanism is competition neglect. Ask a founder "will people want my product?" and you'll get a considered answer — they've thought about little else. Ask "what will the thirty other teams building this ship next quarter?" and you'll get a pause, because the question has never been loaded. It's chapter 3's substitution again: a hard question about a market full of rivals gets quietly swapped for an easy one about your own competence. The outcome depends on everyone; the forecast consulted one person.

And the same overconfidence shows up when you ask people not for a number but for a range they're sure about — which you're about to demonstrate on yourself.

But here Kahneman refuses to sneer, and so should we. Optimists persist through rejections, recover from failures, take the uncompensated risks that occasionally build something enormous. Miscalibrated confidence built most of what you're using to read this sentence. The goal was never to cure optimism — you'd be curing the engine. The goal is a seatbelt.

Interactive · the 80% interval game — / 6

Set a low and a high bound for each quantity so you're 80% sure the truth falls between them. A calibrated player misses about 1 in 5. Wide-but-right should beat narrow-but-confident. Should.

6The premortem

The chapter's closing gift comes from Gary Klein — and Kahneman, who spent years as Klein's professional adversary, endorses it as his favorite debiasing move. It costs one meeting. When a decision is nearly final — plan written, momentum built, dissent starting to sound like disloyalty — you gather the people who know the plan and say:

"It's one year from now. We implemented the plan exactly as it stands. The outcome was a disaster. Take five minutes and write the history of that disaster."

That's the whole technique — the premortem — and every clause is doing work. One year from now moves you past the launch glow, into consequences. It failed isn't a question; doubt stops being a personality trait and becomes the assignment. That flip matters most exactly when a team has converged, because convergence is when private worries go quiet — everyone has a list of things that could sink the plan, and the kickoff is the one meeting where producing that list feels like sabotage. The premortem legitimizes the doubt at the moment momentum has outlawed it, and mines knowledge the room already had. The failure modes it surfaces were sitting in people's heads all along — like Seymour's statistics, present, relevant, and unqueried until someone asked a question shaped to retrieve them.

It won't make you calibrated. Nothing makes you calibrated; overconfidence is never cured, only ambushed. The premortem is the ambush — scheduled, catered, and forty-five minutes long.

Interactive · the premortem dealer choose a plan · keep every card that stings

kept: 0