planning fallacy
The habit of underestimating how long your own work will take, even when similar work has run late before. Asking how long such projects really took is the usual correction.
The planning fallacy is the habit of underestimating how long your own work will take, even when you know that similar work ran late before. It is one of the best-documented findings in research on forecasting: people predict their own tasks more optimistically than the record of comparable tasks supports, and knowing about earlier overruns rarely changes the next estimate.
The cause is the way a plan gets built. You picture your own task step by step, the details feel convincing, and the surprises that will hit it have not happened yet, so they are missing from the picture. Pressure adds to it: an estimate is often cut in a meeting, and nobody wants to be the one who named a late date.
Padding every task is a poor fix. It makes the plan look absurd and still finishes late, because time set aside inside a task tends to get used. More detail is not a fix either: a longer task list is still built from the inside. The correction that works is to start from the outside view: how long did similar projects actually take, against what they were estimated at? Adjust only for differences you can name. "This time it will go better" is not a difference; "the reviewer has already read half the draft" is.
To make the outside view possible, keep a simple record of estimate and actual for each task, and note in the retrospective whether an estimate already held a private margin.
Example
Klasna's three earlier launches (exam math, February 2025; programming for teens, September 2025; the math exam simulator, January 2026) logged 17 tasks:
Every launch ran over. The padded tasks still came in 9 % late: the hidden margin got used. For the physics launch the same pattern showed up on 30 November: the owners' padded estimates for the chain to opening added up to 54 working days against the 43 available, 11 days late on paper. Their most likely values added up to 32. Corrected by the overrun of unpadded tasks in the two subject launches (67 actual ÷ 50 estimated = 1.34), the chain becomes 32 × 1.34 = 42.88 days: almost the whole 43-day window, which the inside view alone did not show.
Common mistakes
- Fixing it with padding. Hidden margins make the plan look absurd and still get used up.
- Trying to think harder about the tasks. More detail is still the inside view; start from how similar projects actually went.
- Calling hope a difference. Adjust the outside view only for differences you can name and check.
- Keeping no record of estimate and actual. Without it, every new plan starts from optimism again.
- Blaming people for overruns. The pattern is systematic; a blameless review that updates the next estimate helps more.
Learn it in the course
- Past projects as a reference, and one shared buffer · Why padding every task makes the date absurd and still finishes late, how earlier launches correct your optimism, and how one buffer under the lead replaces hidden margins.