The planning fallacy
Your estimate is a best case, so check how long the last similar tasks really took before you promise a date.
- work
- autopilot
- hermes
Kavya tells her manager in Hyderabad that the vendor report will be ready in two days. She means it. She has done reports like this before, the data sits in one folder, and she can see the whole job in her head.
On the fifth day she is still on it. Two meetings moved, the data had gaps, and a colleague needed a quick review. None of it was unusual.
That is the planning fallacy. When you estimate a task, you picture it going smoothly, so your estimate becomes a best case instead of a plan. The term comes from Daniel Kahneman and Amos Tversky, who named it in the late 1970s.
The decision, worked through
Kavya's mistake is not laziness. She estimated from the story in her head, and that story has no gaps in it.
Next time, she tries a different question. Instead of "how long will this take?", she asks "how long did my last three reports actually take?" She looks back: five days, four days and six days. Her estimate of two days was never close to any of them.
So she gives her manager two numbers. The best case is two days, if nothing goes wrong. The realistic case, based on the last three, is five days. She says: "It can be done in two if everything goes smoothly. I am planning for five, and I will tell you on day two where it stands." Her manager now has a date he can plan around, and she has room to do the work properly.
Where it goes wrong
The fix is not to double every estimate and stop thinking. A vague "add some buffer" is just another guess. The past numbers are what help, because they carry the meetings, the delays and the favours that your picture left out.
It is also harder when you have no past numbers. In that case, ask someone who has done a similar task, and note how long it really took them, not how long they thought it would.
And an estimate is not an excuse. If you can see a task running long, say so early, not on the evening it was due.
One thing to try today
Pick one task you have promised for this week. Write your first estimate. Next to it, write how long the last two similar tasks actually took. Then tell whoever is waiting for it the longer of the two numbers, and the day you will update them. The first time may feel like you are admitting something, and it is only a number.
Each Sunday: one mental model and one real decision to try it on. Browse the model library.
What it is
Your estimate describes the smooth version of the job.
- The best-case picture
- When you imagine a task, you see it going well, with no meetings, gaps or favours in the way.
- The fallacy
- An estimate made from that picture is a best case, not a plan.
How long did the last ones actually take?
When to reach for it
Before you promise a date.
- A deadline at work
- A report, a deck, a handover.
- A personal project
- A move, a course, a house clean before a function.
- A team estimate
- When someone says 'two days' and you can feel it is more.
An everyday example
A vendor report in a Hyderabad office.
- The promise
- Kavya pictures the job going smoothly. It takes five.
- The better question
- Five days, four days and six days. Two was never close.
- What changes
- She gives two numbers: two days at best, five to plan for, and a check-in on day two.
It will be ready in two days.
How long did my last three reports take?
The trap
The past numbers do the work, not a vague buffer.
- Doubling by habit
- 'Add some buffer' is another guess. Use what the last tasks actually took.
- No past numbers
- Ask someone who has done it and note how long it really took them.
- Using it as an excuse
- If a task is running long, say so early.
Try this today
One promised task, two past numbers and a pen.
- Check the last two
- Write your estimate, then the actual times. Give the longer number to whoever is waiting, with a day to update them.
What did the last two like this really take?