Why Everything Takes Longer Than You Think

You estimate two hours. It takes five. You've made this exact error on this exact kind of task before, and it did not help.

This is the planning fallacy, described by Daniel Kahneman and Amos Tversky in 1979: the tendency to underestimate how long a task will take, even when you have direct experience of similar tasks taking longer. The striking part isn't that we're wrong — it's that experience alone doesn't fix it.

Why experience doesn't correct it

Several mechanisms combine, and knowing them helps you work around them.

We plan the ideal run. Asked how long something will take, you imagine it going well: no interruptions, no false starts, no discovering halfway through that you need something you don't have. You're estimating the best case and treating it as the expected case.

We forget the surrounding work. The "one-hour" task has a fifteen-minute setup, a ten-minute interruption, and twenty minutes of finishing that you didn't count. You estimated the core and lived the total.

We remember outcomes, not durations. What sticks is that you finished the report — not that it took from 9pm to 1am. Memory keeps the result and discards the cost, so there's nothing accurate to learn from.

Optimism is rewarded socially. Longer estimates sound less capable. In most environments there's quiet pressure toward the shorter number, and you internalise it until you're doing it to yourself.

Why it matters more for a week than for a task

Being 60% out on one task costs you an evening. Being 60% out on ten tasks costs you the week — and, more corrosively, it costs you trust in your own plans.

That's the real damage. After enough weeks where the plan didn't survive, people conclude that planning doesn't work for them and stop. The plan wasn't the problem; the inputs were.

The fix: your multiplier

There's no way to reason your way out of the planning fallacy. Being aware of it barely helps — studies show people who know about it still commit it.

What does work is reference class forecasting: instead of imagining how this task will go, look at how similar tasks actually went. That requires data, and the only data that will convince you is your own.

Here's how to get it:

1. Before you start, write your estimate. In minutes. Before, not after — a guess recorded afterwards is contaminated by knowing the answer.
2. Record what it actually took. A timer is ideal, because memory rounds down.
3. Divide. Actual ÷ estimate = your multiplier.
4. Do this for two or three weeks, across the kinds of work you plan regularly.

You'll get a number. For most people it lands between 1.4 and 2.2, and the interesting thing is it tends to be stable per category. Writing might run 1.8×; admin 1.5×; coding 2.0×; errands close to 1.0× because they're bounded by the outside world.

Once you know your multipliers, stop estimating and start calculating. Two hours, times 1.8, means schedule three and a half.

Why this feels bad and works anyway

The first reaction to applying a multiplier is usually resistance. Three and a half hours for something that "should" take two feels like defeat.

But the two-hour version was never real. You've never once done it in two hours. Choosing between "an accurate plan that fits less" and "an optimistic plan that fails" is not much of a choice — and the accurate one is the only one that produces a week where things finish.

There's an unexpected benefit too. When a task is given the time it truly needs, it stops running into the next thing, which stops the cascade that turns one overrun into a ruined day.

Break big things down

Multipliers get less reliable as tasks get bigger, because large tasks hide more unknowns. "Redesign the website" could be 20 hours or 200 and no multiplier will rescue that estimate.

The fix is decomposition. Break anything over about four hours into pieces you can picture concretely. A piece you can't describe in a sentence is a piece you can't estimate. As a bonus, decomposition surfaces the steps you'd forgotten — which are usually what made the original estimate wrong.

Add buffer at the week level, not the task level

If you pad every individual task, two things happen: the padding gets absorbed (work expands to fill it), and your estimates never improve because you've hidden the error.

Better: estimate honestly, apply your multiplier, then leave a third of the week unassigned as shared buffer. Tasks that overrun draw from the pool; tasks that finish early return to it. You keep clean data on your estimates and a week that can absorb surprises.

The short version

• You will underestimate. Knowing this doesn't stop it.
• Awareness doesn't fix it; measurement does.
• Record estimate and actual for a few weeks, per category.
• Multiply future estimates by what you find.
• Decompose anything over four hours.
• Buffer at the week level, not the task level.

The goal isn't to become a better guesser. It's to stop guessing — to know, from evidence, that your Tuesday-evening writing sessions run ninety minutes rather than the sixty you keep scheduling, and to plan the week you'll actually have.