In the classic study of the planning fallacy, psychology students were asked when they'd hand in their honors thesis. They were also asked when they'd hand it in "if everything went as poorly as it possibly could." About half missed even that worst-case date.
A worst case you imagine isn't a safe date.
Short answer: the planning fallacy is the tendency to underestimate how long your own tasks will take, even when you know similar tasks ran late before. Daniel Kahneman and Amos Tversky named it in 1979. It comes from forecasting off the plan in your head instead of off how long such tasks really took, and from a memory that shortens the past. Corrections built on recorded actuals have research support, and the recipe here assembles them: log ten tasks, take the median ratio of actual to estimate, and multiply your next gut estimate by it.
What is the planning fallacy?
It's an optimistic bias in forecasts about your own work. You expect the next task to go faster than the last few, while knowing the last few ran late. Kahneman and Tversky coined the term in 1979, and Roger Buehler (2019), lead author of the classic 1994 study, defines it as underestimating a task "despite knowing that similar tasks have typically taken them much longer in the past."
Two details sharpen the planning fallacy definition. First, it's about your own tasks: in Buehler, Griffin and Ross (1994), observers predicting someone else's completion time overestimated it. Second, it isn't a megaproject curiosity. Buehler's summary finds it in household chores and subway construction alike, across personality types and cultures.
A planning fallacy example: what the classic study found
On average, students took about 64% longer than their best guess, and about half missed even their worst case.
Buehler, Griffin and Ross (1994) phoned 37 students in the final semester of an honors-thesis course. Among the 33 who submitted while the researchers were still keeping records, the average best guess was 33.9 days. The average actual was 55.5. Their best-case guess averaged 27.4 days. Their worst case averaged 48.6, about a week early, though that gap wasn't statistically significant. Only 29.7% finished by their own best estimate.
Two other results in that paper matter more for fixing the problem than the headline does.
The estimates weren't noise. Predicted and actual times correlated at r = .77. Students who expected to take longer did take longer. The guesses carried real information — they were shifted, not random — and that is what makes a correction factor possible.
Remembering the past wasn't enough. In Study 4, 123 students predicted when they'd finish a computer assignment of about an hour. Recalling earlier assignments first made no significant difference: 38.1% finished by their prediction, against 29.3% in the control group.
Students who were walked through connecting those memories to the new task — when would this one land if it went like your usual assignments? — reached 60.0%, and their average prediction (7.0 days) matched their average finish (7.0). The authors still call those predictions "no more accurate" in absolute terms. The average moved. The scatter didn't.
Kahneman tells a version from his own career in Kahneman and Lovallo (1993). His team was writing a decision-making curriculum for Israeli high schools. On slips of paper, members estimated 18 to 30 months to a finished draft. Then he asked the team's curriculum expert how comparable teams had fared: about 40% never finished, and none of the rest took less than seven years. The team finished about eight years later.
Hofstadter's law: the planning fallacy, recursively
Hofstadter's law comes from Douglas Hofstadter's Gödel, Escher, Bach (1979), in the chapter on recursive structures and processes: "It always takes longer than you expect, even when you take into account Hofstadter's Law." The occasion was computer chess. People had put a computer world champion ten years away, and ten years later it still looked more than ten years away.
It reads like a joke about recursion, and the thesis data fits it: students told to imagine everything going wrong still missed that date about half the time. Padding by feel is a weak escape, because the padding comes from the same inside view that produced the estimate. You can't out-think Hofstadter's law. You can stop guessing the correction and measure it instead.
Why it happens
Mostly because you forecast from the plan rather than from history, and the history you remember is too short anyway.
You plan from the inside. Kahneman and Lovallo (1993) separate two ways to forecast. The inside view builds a scenario from the plan in front of you. The outside view ignores the details and asks how cases like this one turned out. People default to the first: in Buehler's think-aloud study, 74% of what students said while predicting was about how the task would unfold, and 7% was about relevant past experience.
You explain the past away. The same students put their own past misses down to "relatively external, transient, and specific factors." Last time there was a flu. This time there won't be.
Your memory shortens the past. Roy, Christenfeld and McKenzie (2005) reviewed the duration research and proposed a memory explanation: "People appear to underestimate future event duration because they underestimate past event duration." If they're right, that's uncomfortable, because even a dutiful outside view built from memory inherits the bias. I saw it in my own 30-day time audit, where meetings I remembered as 15 minutes kept turning out to be 40.
You start the projects that look easy. Halkjelsvik and Jørgensen (2018) note that an optimistic estimate makes you likelier to start a task, and you only learn how wrong you were on tasks you started. Durations are right-skewed, too: a 2-hour task can run six hours over, never six under. Overruns dominate what you remember.
It isn't universal. Short tasks often go the other way. Roy's review found tasks under about 5 minutes more likely to be overestimated. Halkjelsvik and Jørgensen's review found small software tasks unbiased or even pessimistic, while projects of at least 100 work hours showed a median overrun of about 20%. The fallacy lives in work long enough to collect interruptions.
What reduces the planning fallacy
In the studies below, the fixes that brought real past durations into the estimate reduced bias or improved accuracy. Unpacking, which only asks you to think harder about the plan, had mixed results.
| Method | What you do | Evidence | The catch |
|---|---|---|---|
| Reference-class forecasting | Forecast from the spread of similar past outcomes | Improves accuracy on large construction projects; for personal ones it "may have similar benefits" (Buehler 2019) | Needs data on comparable tasks |
| Connect past to present | Ask when you'd finish if this goes like your usual tasks | On-time share rose from 29% to 60% (Buehler 1994, Study 4) | Bias fell; absolute error didn't |
| Unpacking | List the subtasks, then give one total | Longer estimates, less biased in Experiments 3–4 (Kruger and Evans 2004); projects that used checklists estimated 10% too low on average, against 38% too low without (Halkjelsvik and Jørgensen 2018) | Listing unusually short or late steps can lower the estimate (Hadjichristidis et al. 2014) |
| Correct memory with measured durations | Look up how long similar tasks took before estimating | Feedback raised accuracy in all three experiments (Roy, Mitten and Christenfeld 2008) | Needs a record you trust |
Buehler is candid about the first row's cost for individuals: the full procedure may be "more useful to subway builders than to subway sandwich makers." The next section is the sandwich-maker version.
Estimate vs actual: personal reference class forecasting in 10 tasks
Flyvbjerg (2006) lays out reference-class forecasting in three steps. They shrink to one person and a spreadsheet:
- Pick the class. Tasks of one kind and rough size, say development tasks you estimated at 1 to 8 hours. Flyvbjerg's test: "broad enough to be statistically meaningful but narrow enough to be truly comparable."
- Build the distribution. For each finished task, divide the actual by the estimate. Kahneman and Lovallo (1993) recommend this kind of actual-to-planned ratio because it "permits meaningful comparisons across diverse projects."
- Place the new task. Multiply your gut estimate by the ratio at the confidence you need.
Here's the arithmetic on the ten demo tasks built into the free estimate vs actual tool. Click "or load 10 demo tasks" to reproduce it. They're invented developer tasks, not anyone's real log.
| Task | Estimate (h) | Actual (h) | Actual ÷ estimate |
|---|---|---|---|
| Refactor auth middleware | 4 | 11 | 2.75 |
| Fix flaky test in checkout | 1 | 3.5 | 3.50 |
| Bump Postgres minor version | 2 | 1.5 | 0.75 |
| Onboarding doc rewrite | 6 | 9 | 1.50 |
| Migrate to Tailwind 4 | 8 | 18 | 2.25 |
| Add dark mode to admin | 3 | 5 | 1.67 |
| Localize error messages | 4 | 4.5 | 1.13 |
| Investigate prod 500 | 1 | 6 | 6.00 |
| Q3 metrics dashboard | 5 | 7.5 | 1.50 |
| Standup notes refactor | 1 | 0.5 | 0.50 |
Sorted, the ratios run 0.50, 0.75, 1.13, 1.50, 1.50, 1.67, 2.25, 2.75, 3.50, 6.00. Three numbers come out of that list, each for a different job.
- The median, for planning one task: (1.50 + 1.67) ÷ 2 = 1.58. A task your gut calls 3 hours goes into the plan as 3 × 1.58 ≈ 4.75 hours, about 4 h 45 m. That's a coin flip: half your tasks should finish inside it. The tool shows this as ×1.58.
- The 80th percentile, for promises: the 8th of 10 sorted ratios, 2.75. The same task becomes 3 × 2.75 = 8.25 hours when someone else depends on the date. It's the level Flyvbjerg reports the UK Department for Transport using: a 20% risk of overrun accepted on large local transport investments.
- The ratio of totals, for a week: 66.5 actual hours ÷ 35 estimated = 1.90. Twenty hours of estimated tasks means about 38 hours of work. The median is the wrong tool here. Halkjelsvik and Jørgensen (2018) show that medians and most-likely values don't add up to a realistic total, and that only predicted means do. The ratio of totals is the estimate-weighted mean. The tool shows both totals.
Only 2 of the 10 landed within ±25% of the estimate, so the tool's "on the nose" share reads 20%.
One decision before you log anything: are you estimating effort or the calendar? Buehler's students predicted finish dates. A time tracker measures hours of work. A 3-hour task can take 4.75 hours of effort and three days of calendar, so keep the two in separate classes.
Where the actuals should come from
If you type the actual from memory, the bias you're trying to correct goes straight back into the correction. Roy, Christenfeld and McKenzie (2005) suggest that for important tasks "it may prove useful to keep records of beginning and ending times for the task." Roy's 2008 experiments found people predicted well when they relied "not on memory of past task duration but instead on measures of actual duration."
Any honest record works. A start/stop timer is fine if you reliably start it. Your calendar and sent mail are enough for finish dates.
I build Timex, an automatic time tracker for Mac, and it covers the effort side without a start button. It records the frontmost app, the window title and the active browser tab's URL every second, into one local SQLite file. To pull out one task's actual:
- In the app: expand the app in the drill-down to see its top window titles with time, or drag across the Today timeline over the stretch you worked on it and read the filtered totals.
- With SQL: open the file in the free SQLite viewer and sum by something that shows up in titles or URLs, such as a ticket ID:
SELECT ROUND(SUM(duration) / 3600.0, 2) AS hours
FROM activity
WHERE title LIKE '%ACME-142%' OR url LIKE '%ACME-142%';
Paste the result into the estimate-vs-actual tool as the actual. Timex doesn't estimate, plan or schedule anything. It supplies actuals, and the estimating stays with you. It also sees only your Mac. A phone call or a whiteboard session needs a manual entry, which Timex offers once you've been away 5 minutes.
The honest limits
A multiplier fixes the average, not the spread. Buehler's Study 4 showed that already. Feedback makes your sense of the spread more realistic, but slowly.
In one study Halkjelsvik and Jørgensen (2018) describe, software professionals gave 90% ranges for 30 tasks, with the real time revealed after each. Those ranges caught the actual time 64% of the time on the first 10 tasks, 70% on the next 10 and 81% on the last 10. That's more realistic, and still short of 90%. It's why the number you promise is the 80th percentile, not the median.
Ten tasks is a small sample, and the class drifts. The 80th percentile of ten points moves if one task changes, so keep logging and recompute. Don't mix a 1-hour bug fix with a three-week migration; very short tasks may be overestimated anyway. And once you start correcting, your gut may start padding on its own. Recomputing catches that too.
Parkinson's law pushes the other way. Work expands to fill the time available, and Halkjelsvik and Jørgensen extend it to "plus a little more." Hand yourself the 80th-percentile number as a target and the slack tends to vanish. Plan your day at the median, promise at the 80th percentile, and keep the difference as a visible buffer outside the task.
This recipe is assembled from parts. Each part has evidence behind it: the outside view, connecting past to present, measured durations. I haven't found a study that tests "median of your last ten tasks" on individual knowledge workers. Treat your multiplier as your best current estimate of yourself, not a law.
Start with the next ten
Write the estimate down before you start. Take the actual from a record, not from memory. After ten tasks, sort the ratios and take the middle one. A stopwatch and a spreadsheet are enough to do it.
If you'd rather not run the stopwatch, download Timex and log your next ten tasks against it; the trial is 100 hours of tracked activity, no credit card.
— DK