โ† Back to Blog
Lost Time7 min read

The Planning Fallacy: Why Tasks Always Take Longer

You knew the last report ran long, yet you still promised this one by Friday. That's the planning fallacy โ€” and the fix isn't a bigger buffer, it's a different question.

By Hilly Shore Labs

TL

Key Takeaways

  • You underestimate even when you know better โ€” the planning fallacy is a forecasting error baked into how you predict, not a discipline problem you can will away.
  • Even worst-case guesses run short โ€” in a classic study, fewer than half of students finished by their own pessimistic thesis estimate; their best guess landed 22 days early.
  • The cause is the 'inside view' โ€” you forecast from the smooth story of this plan, which leaves out the interruptions that always happen but aren't written into it.
  • The fix is the 'outside view' โ€” estimate from how long similar tasks actually took you before, not from how this one should go. Buffers on a biased number stay biased.
The Planning Fallacy: Why Tasks Always Take Longer

Every plan you make is told from the inside. You picture the task going right: you sit down, the words come, nothing interrupts, and you finish by the time you said. The trouble is that this almost never happens โ€” and the strange part is that knowing it almost never happens doesn't help. You can be fully aware your last three projects ran late and still hand in an optimistic estimate for the fourth. 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 past tasks ran long. It was named by Daniel Kahneman and Amos Tversky in 1979, and it's one of the most reliable findings in all of judgment research. This isn't a discipline problem you can will your way out of. It's a forecasting error baked into how you predict โ€” and once you see the mechanism, there's a clean, almost mechanical fix.

The honors-thesis study that nailed it down

The cleanest demonstration comes from Buehler, Griffin & Ross (1994), who asked psychology students to predict when they'd finish their honors theses. The numbers are almost comically lopsided:

The estimate they gaveDays they predictedDays it actually tookFinished by that date
"Best guess"33.955.5about a third
Optimistic ("if all goes well")27.455.5just 10.8%
Pessimistic ("if it goes badly")48.655.5only 48.7%

Read that last row twice. Asked to imagine the project going as badly as it possibly could, fewer than half still finished by that pessimistic date. Their worst case was, on average, optimistic. Their "best guess" of 34 days landed 22 days short. That's not random bad luck โ€” every estimate leaned the same way.

The pattern, not the person: Buehler's team specifically went looking for whether optimists or self-doubters did this more. They didn't find a personality split. The bias shows up in most people, which is the tell that it's structural โ€” a feature of how prediction works, not a flaw in you.

Why knowing better doesn't fix it

Here's the mechanism. When you estimate a task, your mind builds a story โ€” a plausible, step-by-step path from start to finish. Kahneman and Tversky called this the inside view: you reason from the specifics of this plan. And a good plan, by construction, is a smooth story. It doesn't include the email that derails Tuesday, the dependency that isn't ready, the revision you didn't see coming. Those things are real and frequent, but they're not in the plan, so they're not in the estimate.

Meanwhile, your general knowledge โ€” "projects like this always slip" โ€” sits in a separate drawer and rarely gets opened at the moment of prediction. Buehler's think-aloud studies caught people doing exactly this: when predicting, they focused on future scenarios for the current task and reached for past experience only when prompted. You hold a pessimistic theory ("things take longer than I hope") alongside an optimistic forecast for the specific task in front of you, and the two never collide. That's why a bigger rรฉsumรฉ of blown deadlines doesn't sober you up. The past gets explained away as one-offs โ€” "that time the printer broke, the client went quiet" โ€” so it never becomes a base rate.

The fix: switch from the inside view to the outside view

The correction Kahneman and Tversky proposed isn't "be more careful" or "pad your estimate." It's to ask a fundamentally different question. Instead of "How long will this take, given my plan?" (the inside view), ask "How long did tasks like this actually take me last time?" (the outside view). You stop forecasting from the story and start forecasting from the track record.

Worked example. Say you're writing a client proposal and your plan-based estimate is 3 hours.

  • Inside view (what you'd normally do): "Outline 30 min, draft 2 hours, polish 30 min โ€” call it 3 hours." Clean story, smooth path, no friction in it.
  • Outside view (the fix): "The last three proposals took 5, 4, and 7 hours. Median is 5." You write down 5 โ€” and you trust the number over the story, even though the story feels truer.

The outside view will almost always feel too pessimistic. That feeling is the bias talking. Your real history already contains every interruption you're about to forget โ€” it just records them as elapsed time.

The catch: the outside view only works if you actually have a record. Most people don't โ€” they remember the proposal taking "an afternoon" when it ate two days. The single highest-leverage move here is dull: log how long things actually take, even roughly. A task you finished is a data point about the next one.

A three-step outside-view estimate

  1. Name the reference class. Not "this proposal" โ€” the category: "client proposals," "code reviews," "expense reports." You want the bin this task falls into.
  2. Pull 3โ€“5 real past times from that class. From memory if that's all you have, but prefer a log. Take the median, not the fastest one (the fastest is the story you keep telling yourself).
  3. Adjust only for concrete, specific differences. If this proposal is genuinely twice the scope, scale up. But resist the urge to talk yourself down from the base rate โ€” "this one will be easier" is the inside view sneaking back in.

What the research does NOT support

The popular fixes mostly miss. "Just add a buffer" sounds like the answer, but Buehler's data undercuts it: people's deliberate worst-case estimates were still too short more than half the time. A buffer applied to a biased number is just a slightly less biased number โ€” you're padding the wrong baseline. The outside view replaces the baseline; padding only stretches it.

"Try harder / be disciplined" is also off-target. The fallacy isn't laziness about working; it's optimism about predicting. You can be a heroic worker and still chronically over-promise, because the error happens at the estimating step, before any work begins. And "learn from experience" doesn't fix it on its own either โ€” the whole point of the research is that experience alone doesn't transfer, because we file failures as exceptions. Experience only helps when it's converted into a base rate you actually consult.

The honest reframe

"I'm just bad at estimating" is the wrong story. You're not bad at it โ€” you're systematically optimistic at it, in a way that's shared by professional engineers, students, and the people who took 13 years longer than planned to build the Sydney Opera House. The plan in your head is a best-case scenario wearing the clothes of a forecast. The fix isn't to think harder about the plan. It's to stop asking the plan and start asking your own history.

Planning Fallacy FAQ

What is the planning fallacy in simple terms?

It's the tendency to underestimate how long your own tasks will take โ€” and to keep doing it even when you know similar past tasks ran long. Named by Kahneman and Tversky in 1979, it's one of the most consistently replicated biases in judgment research.

Why do I keep underestimating even after being late so many times?

Because you estimate from the "inside view" โ€” the smooth story of this specific plan โ€” which leaves out the interruptions and revisions that always happen but aren't part of the plan. Your general knowledge that "things run long" sits separately and rarely gets consulted at the moment you predict.

Doesn't just adding a buffer fix it?

Not reliably. In Buehler's study, even people's deliberately pessimistic worst-case estimates were too short over half the time. A buffer on a biased number is still biased. The better fix is the outside view: base the estimate on how long similar tasks actually took, then adjust.

What is the "outside view"?

Instead of asking "How long will this take given my plan?", you ask "How long did tasks like this actually take me before?" You forecast from your track record โ€” ideally a real log of past times โ€” rather than from the story of how this one should go.

Sources

r/

What people on Reddit actually say

  • r/productivityโฌ† strong consensus

    A recurring r/productivity theme is that the single thing that fixed people's chronic over-promising wasn't trying harder but logging how long tasks actually took โ€” then quoting the median of past times instead of the hopeful guess, which matches the research that the outside view beats the inside story.

  • r/getdisciplined๐Ÿ’ฌ commonly repeated

    On r/getdisciplined the common take is that 'this time will be different' is the trap โ€” posters describe finally trusting their own track record over the optimistic plan in their head, and report deadlines stop slipping once the estimate comes from history rather than from a best-case scenario.

Paraphrased consensus from public threads โ€” no direct user quotes.

Ready to get unstuck?

The Brain Deck gives you 52 science-backed strategies in your pocket โ€” a physical card deck you keep on your desk, no app required.

See the Cards

Launching soon ยท 54 cards ยท Premium matte finish