tick-tock-done Open the app

Articles

Getting things done

The planning fallacy: why every task takes longer than you think, and how to estimate better

Clipart of an hourglass and a calendar with days crossed off, on a warm cream background

You said the quote would go out on Tuesday. The bathroom refit was a ten-day job. The new menu would be costed over the weekend. None of these were lies; each was an honest picture of the work going well. And each ran over, the way the last one did.

Psychologists have a name for this: the planning fallacy. Daniel Kahneman and Amos Tversky coined it in 1979 for a specific puzzle: people underestimate how long their own task will take, even when they know that similar tasks have run late before. It is not the same as putting things off. You can start on time, work steadily and still be late, because the estimate was wrong on the day you made it.

The thesis study

The best-known test is by Roger Buehler, Dale Griffin and Michael Ross (1994). They asked 37 psychology students who were writing an honours thesis to predict when they would hand it in. They asked for three numbers: a realistic guess, a guess "if everything went as well as it possibly could", and one "if everything went as poorly as it possibly could".

Realistic guess: 33.9 days on average.
Best case: 27.4 days.
Worst case: 48.6 days.
What happened: 55.5 days.

About 30% of the students finished by the date they had called realistic. The average student took longer than the average worst case. Their idea of everything going wrong was still more cheerful than an ordinary term.

In a later round, the same group asked students for a date they were 99% sure of. Under half (45%) made it. Being very sure did not make people right.

Why it happens: the inside view

In the 1994 paper the researchers also asked students to think aloud while they made a prediction. Most of what they said was about the future: the steps they would take, in order. Very little was about how past assignments had gone, and when the past did come up it was often explained away ("that time I was ill").

Kahneman called this the inside view: building the estimate from the plan in your head. A plan is a story of the job going the way you picture it. It has no room for the supplier who sends the wrong tile, the cook who calls in sick, the client who takes four days to answer one email. No single one of those is likely. That one of them happens is close to certain.

The outside view ignores the plan and asks one question: how long did jobs like this take before? Kahneman tells a story against himself. In the 1970s he led a team writing a school textbook. After a year, he asked everyone to write down how long the rest would take; the guesses were around two years. He then asked a curriculum expert on the team how other teams at the same stage had done. The answer: about 40% never finished, and the rest took seven to ten years. The team carried on with its own two-year plan anyway. The book took eight more years.

The question that fixes an estimate is not "what are the steps?" It is "how long did the last three take?"

One more finding is useful for anyone who runs a crew. People are too hopeful about their own work, but not about other people's. When observers were asked to predict someone else's finish date, they leaned the other way and guessed late. Your estimate of your own job is the one to distrust.

Four habits that make estimates hold

1. Keep your own record, and use the ratio

The method that came out of this research is called reference-class forecasting. Bent Flyvbjerg, who applied it to roads, bridges and rail lines, sets it out in three steps: pick a group of similar past projects, look at how they turned out, and place your project in that spread. You don't need a database for this. You need your own last few jobs.

For each finished job, write down two numbers: what you said and what it took. Divide the second by the first. If your last five quotes were out by 1.3, 1.6, 1.2, 1.8 and 1.5, your next gut feeling should be multiplied by about 1.5 before anyone hears it. The students above would have needed 1.6. The number is personal and it changes with the kind of work, so keep one for each kind: a bathroom, a kitchen install, a catering order for forty.

To work out your ratio, use the estimate ratio calculator: put in three to ten finished jobs with what you said and what they took, and it gives your typical ratio, how often your estimate held, and a likely and a safer number for the next job. It runs in your browser.

There is a second reason to write the real times down. Michael Roy, Nicholas Christenfeld and Craig McKenzie (2005) argued that part of the problem is memory: we remember past jobs as shorter than they were, so even a person who does look back starts from a number that is too small. A note made on the day a job closed doesn't shrink.

2. Unpack the job before you put a number on it

Justin Kruger and Matt Evans (2004) asked people to estimate tasks either as one lump or after listing the parts. Listing the parts first gave longer estimates, and the gap to reality got smaller. Their paper's title is the advice: "If you don't want to be late, enumerate."

"Repaint the dining room" is one line and feels like a day. Unpacked, it is: move and cover furniture, fill and sand, wait for the filler, cut in, first coat, wait, second coat, clean up, put the room back. The waiting and the tidying are the parts a lump estimate leaves out. Put the parts on the list as sub-tasks with their own times and add them up.

Unpacking is not magic. A 2021 test on online workers' to-do lists did not find the effect, and Kruger and Evans themselves found it weaker when the listed parts were small ones. Use it together with the record in habit 1, not in place of it.

3. Name what could stop the job

A plan is a best case by default. Before you give a date, write three things that have gone wrong on jobs like this, and what each cost in time. Deliveries, weather, other people's sign-off, a second job that overlaps. You are not predicting which will happen. You are making the estimate include the fact that something will.

4. Give a range and say what the early date depends on

A single date sounds like a promise. A range with a condition is more honest and easier to keep: "Eight to eleven working days. Eight if the tiles arrive by Monday." The client hears the risk at the start, when it is news, and not at the end, when it is an excuse.

For a crew: plan the week at what you really finish

The same bias shows up when a lead fills a week. Every slot gets a job, every job gets its best-case time, and by Wednesday the plan is fiction. Three things help.

Count what the crew closed in each of the last four weeks. Plan next week at the average, not at the best week.
Leave room on purpose. If one day in five has gone to call-backs, breakages and cover for absences, plan four days of work and hold the fifth.
Let someone else estimate. The person who won't be doing the job tends to guess longer and closer. Ask a second lead for a number before you look at your own.
Record the real finish. Tick the job when it is done, not at the end of the week, so the date on it is true. That date is next month's reference class.

For a freelancer: the quote

Unpack the job into parts and time each one. Add the parts that are not the work itself: the brief, the questions, the revisions, the hand-over, the invoice. Multiply the total by your own ratio. Then quote the range. If the result looks too high to win the job, that is worth knowing before you take it, not after.

What the research does not show

It doesn't give a universal multiplier. The 1.6 above belongs to 37 students and one kind of task. Rules like "double it" are folklore. Your own record is the only number that fits you.
It is mostly about students and big public projects. Small trades, kitchens and freelance work have been studied far less. The mechanism is plausible there; the figures are not measured.
Not every task is underestimated. Very short and unfamiliar tasks are sometimes guessed too long. The bias is strongest for long jobs with many steps and other people in them.
Knowing about it is not a cure. People who can describe the planning fallacy still commit it. What helps is a written record and a routine, not good intentions.

Putting it on your list

Write the job as a task, the parts as its checklist, and your estimate in the note on the day you make it. When you tick it, add what it took. After five jobs you have your ratio. The weekly review is a good moment to compare the two numbers. And if the trouble is starting, not estimating, that is a different problem with a different fix: see why you put things off.

Put your next job on a list with its parts, your estimate in the note, and the real time when you tick it.

Open tick-tock-done

Sources

Buehler, R., Griffin, D. & Ross, M. (1994). Exploring the "planning fallacy": why people underestimate their task completion times. Journal of Personality and Social Psychology 67(3), 366-381. Paper (PDF)
Buehler, R., Griffin, D. & Ross, M. (1995). It's about time: optimistic predictions in work and love. European Review of Social Psychology 6, 1-32 (the 50%, 75% and 99% sure dates).
Buehler, R. (2019). The planning fallacy: an inside view. Society for Personality and Social Psychology
Kahneman, D. (2011). Thinking, Fast and Slow, chapter 23, "The outside view". Excerpt: Beware the inside view, McKinsey Quarterly
Flyvbjerg, B. (2006). From Nobel Prize to project management: getting risks right. Project Management Journal 37(3), 5-15. arXiv 1302.3642
Kruger, J. & Evans, M. (2004). If you don't want to be late, enumerate: unpacking reduces the planning fallacy. Journal of Experimental Social Psychology 40(5), 586-598. doi:10.1016/j.jesp.2003.11.001
Roy, M., Christenfeld, N. & McKenzie, C. (2005). Underestimating the duration of future events: memory incorrectly used or memory bias? Psychological Bulletin 131(5), 738-756.
Huang, C. (2021). Does unpacking a to-do list reduce the planning fallacy? International Journal of Psychological Studies 13(2), 84. RePEc
Cover: clipart from Openclipart, released under CC0 (public domain).