Why Tasks Take Three Times Longer Than You Think

You sit down to answer a couple of emails. Fifteen minutes, twenty tops. You look up and ninety minutes are gone, half the inbox still untouched. Sound familiar? This isn't about being lazy or slow. It's how everyone's brain works: we almost always believe a task will take less time than it actually does.

The frustrating part is that the error repeats. You underestimated yesterday, you underestimated last week, and today you confidently write "report – one hour" in your plan. And you sit there until evening again. This glitch has a name. Back in the late seventies, Daniel Kahneman and Amos Tversky called it the planning fallacy: we reliably bet on the best-case scenario even when past experience is screaming otherwise.

The good news is you can work with this. Not through willpower, through method. Let's unpack why the gap is roughly triple, and how to count so you actually land close.

Where the triple gap comes from

The gap isn't random. It's built from a few predictable pieces, and each one adds its share.

First, we count pure working time, not start-to-finish time. Writing the text is twenty minutes. But before that you have to open the right files, remember where you left off, find an example, and afterward reread and fix it. The pure work stays twenty minutes, but a chunk of your day is gone.

Second, we forget the world around us. While you work, a message arrives, someone calls, someone needs you "for a second." Every interruption costs not only its own minutes but the time it takes to climb back into the task.

Third, subtasks surface that weren't in your head at the start. "Upload the report" becomes "why won't the file open," "I need to re-export it," "wrong format." You planned none of these steps, yet every one is real.

Add it all up and you get that famous triple. Below we'll take each source apart, because you fight them in different ways.

We estimate the clean run, then run through mud

When you guess at time, your head plays the best version. You picture yourself sitting down and doing it: focused, no friction, right the first time. Your brain paints a smooth track because recalling every possible pothole is slow and unpleasant.

The trouble is the clean run rarely happens. Almost always something gets in the way: you drift off, get tired, snag on a small thing, have to redo it. But we don't count those obstacles, because we can't know in advance which one will fire today.

So the takeaway is simple: estimate the ordinary run, not the ideal one. Not "how it'll go if everything lines up," but "how it usually goes." Usually means with friction.

The invisible subtasks that surface along the way

Anything bigger than a couple of minutes breaks into steps inside. Some are obvious, some hide. The hidden ones are what wreck your estimate.

Take "prepare the presentation." Feels like one task. In reality: gather the data, pick a structure, draft it, find images, format it, proofread, fix it after rereading with fresh eyes. Seven steps instead of one. If you estimate the presentation as a whole, you'll intuitively name the time for one or two steps, not all seven.

The bigger and less familiar the job, the more hidden steps it holds and the harder you miss. A familiar task you've walked before, so you at least sense its underside. A new one you only see from the front.

Context switches steal more than they seem to

Every time you pull away from a task and come back, your attention doesn't snap on instantly. You have to remember where you stopped, reload the context, catch the thread again. Those seconds and minutes are invisible in the moment, but they pile up over a day.

Short switches are especially sneaky. Glancing at a notification feels like three seconds. But getting back into a hard task at the same depth afterward takes far more. It's as if you have to accelerate from a standstill every time.

That's why a job you do in scraps, between chats and calls, will take noticeably longer than the same job in one sitting. Identical work, different cost, purely because you did it in pieces instead of whole.

Memory lies: we forget how last time went

You'd think there's a simple cure: remember how long a similar task took before and budget the same. But memory plays along with the optimism. We remember the outcome, not the road to it. We remember that the report got submitted, not that we sat over it till midnight and redid it twice.

Because of that, past experience barely corrects the next estimate. You step on the same rake again and again, because the whack didn't stick, while the fact that "I pulled it off in the end" did.

So the key practical move: don't lean on the feeling from the past, lean on the record. More on that below.

How to estimate closer to the truth

A good estimate isn't guessing, it's a small procedure. It takes a minute and saves hours. Here are four steps that work together.

Break the task into steps

Don't estimate the job whole. Split it into concrete actions and price each one. "Write the article" is hard to estimate, but "gather facts – outline – draft – proofread" you can see in parts. The sum of the pieces is almost always more honest than one number for everything, because it forces you to see the hidden steps.

There's a nice side effect too: a broken-down task stops being scary. Starting "write the article" is heavy; "gather facts" is easy.

Look at similar tasks from your past

Before you name a time, ask: "when I did something like this, how long did it actually take?" Not how long it should have taken, how long it took. This is the strongest move of all, because it leans on a fact instead of a fantasy about the best case.

No measurements yet? Start collecting them. Logging a couple of tasks a day is enough, and within a week you'll have your own personal table of real time. It beats any advice from the internet, because it's about you.

Estimate a range, not a single number

A single number always lies: it's either too small or too big. A range is more honest. Say "from forty minutes to an hour and a half" and you're already budgeting for what might go sideways. Put the upper bound in your plan: if you finish sooner, that's a pleasant bonus, not a wrecked day.

Add a buffer on purpose

Once you've counted by steps and recalled the past, add slack for the unexpected. Not because you're slow, but because the unexpected always happens, you just don't know in advance which flavor. Empty space in your schedule isn't idleness, it's insurance against one task dragging the whole day behind it.

The multiplier rule: crude but honest

When there's no time to count by steps, a simple rule works. Estimated an honest time? Multiply it. For a familiar job, by two; for an unfamiliar one, by three. It sounds crude, yet it lands closer than your first guess almost every time.

This isn't pessimism. It's a correction for the fact that your intuition systematically looks at the best case. You're not stretching the task, you're putting back what intuition threw out: the switches, the subtasks, the revisions.

Over time you can tune the coefficient to yourself. For some people the real multiplier is one and a half, for others closer to three. There's only one way to learn yours: measure and compare against the estimate.

Who this hits hardest

The planning fallacy is universal, but it lands differently.

For a freelancer or anyone quoting jobs, the miss costs money directly. Name a deadline and price from an optimistic estimate and you work unpaid hours on top. Here, measuring past time by task type turns straight into your pricing.

For anyone working in a stream of incoming requests – support, sales, management – it's not so much subtasks as the endless switching that hurts. Their main cure isn't a precise estimate but protecting whole blocks of time when nobody pulls at them.

For a parent, real time gets chopped into pieces by someone else's schedule. Range and buffer matter most here: plan not "an hour on the task" but "the task in whatever windows are left."

For someone with ADHD or anyone who slips easily into flow, the hardest part is the sense of time itself. An external counter helps them especially: not "feels like twenty minutes passed" but a timer showing the truth.

On a team, the error compounds. Everyone underestimated their piece by a third, and at the handoffs they also wait on each other, so the project slips not by a third but by half. That's why on a team you budget slack not only for tasks but for the passes between people.

How this ties to your daily plan and deadlines

A precise estimate isn't an end in itself. It fixes two things that break most often.

The first is the daily plan. If you pack a morning list of ten items, each underestimated by half, you're in debt by lunch and in guilt by evening. A realistic estimate shows immediately: a day fits three or four items, not ten. That's not defeat, it's a truth you can live with.

The second is deadlines and promises. A date named from optimism you'll almost certainly blow. A date named from a range with a buffer you'll keep, and sometimes pleasantly surprise. People remember not that you're fast but that you can be trusted.

Common estimating mistakes

Counting pure work instead of the whole road. "Write" is twenty minutes, but open, remember, find, proofread add forty more. Estimate from "sat down" to "done and not coming back."

Estimating in a good mood. Full of energy, you'll name a chipper time you won't repeat tired on a Thursday night. Count for average you, not best you.

Trusting round numbers. "An hour" and "half a day" are labels more often than calculations. A real estimate is rarely that neat. A round number is a signal you waved your hand instead of counting.

Not counting rework. The first version is almost never the final one. If the work is meant to be seen by others, budget a round of edits, it will come.

Forgetting the warm-up. Between "I should start" and "started" sits a gap, sometimes a big one. It's part of the task's time too, even though it doesn't look like work.

When estimating isn't needed and doesn't work

An honest section: a precise estimate is a tool, not a religion. There are cases where it's pointless or useless.

For tiny jobs, don't count. The guess takes longer than the job. A different rule works here: if it takes a couple of minutes, just do it now, don't log it and don't estimate it.

For genuinely exploratory tasks, estimates lie unavoidably. If you're doing something you've never done and don't even know what steps it contains, an honest estimate sounds like "no idea." And that's a fine answer. For jobs like that, plan not a finish date but a slice of time for the attempt: "today I dig for two hours, then I look at what I understood." Estimate the investment, not the result.

And one more thing: don't turn the estimate into a whip. The point isn't to hit the number at any cost and beat yourself up over a miss. The point is to make plans truer and stop the day from crumbling. If the estimate adds anxiety instead of clarity, you're aiming it the wrong way.

What to do today

You don't have to change everything at once. Start with one task.

1. Take your next task and, before you begin, honestly write down how long you think it'll take. A single number or a range.
2. Clock it. Just note when you sat down and when you finished, including every distraction and revision.
3. Compare. The gap between estimate and fact is your personal multiplier. It's usually more than one, and that's normal.
4. Repeat tomorrow with a different task. In a week you'll have five or six such pairs and you'll start estimating noticeably closer, not guessing anymore but knowing.

That's it. No willpower, just a small measurement repeated a few times. Estimates don't improve because you promised yourself to try harder. They improve on data.

Frequently asked questions

Why do I keep underestimating even though I know I do it?

Because knowing doesn't switch off how the brain works. The optimistic estimate appears automatically, before you've had a chance to recall past misses. What helps isn't "try to remember" but an external support: the recorded real time of similar tasks, which you check before naming a deadline.

How much should I multiply the first estimate by?

For a familiar job, about two; for an unfamiliar one, three. That's a starting reference. Your exact coefficient is your own, and you can only learn it by measuring: compare estimate to fact a few times and you'll see how many times over you usually miss.

Won't an inflated estimate become self-fulfilling – give more time, take more time?

That risk exists; it's called Parkinson's law: work expands to fill the time allotted. The defense is simple: put the upper bound of the range in your plan, but work against the lower bound with a timer. The estimate insures against a blowout while the timer keeps the pace.

Should I estimate really small jobs?

No. If a task takes a couple of minutes, estimating eats more than the task does. Don't plan or count those, do them the moment they surface. Estimating is for jobs that weigh half an hour or more.

How do I estimate something I'm doing for the first time and don't even know the steps of?

Don't estimate a finish date, estimate a slice for an attempt. Set aside, say, two hours to figure out what steps the job consists of. After that you'll have pieces you can price individually. Trying to name a final date blind means guaranteeing a miss.

Why do team projects slip more than personal tasks?

The errors add up, and at the handoffs people also wait on each other. If everyone underestimated their piece by a third, plus time is lost passing work between stages, the final date slips far more than a third. That's why teams budget slack both for tasks and for the pauses between them.

What if my real time keeps jumping and can't be predicted at all?

Then the tasks are too big or too varied to measure with one yardstick. Break them into smaller, more uniform steps; a single step always scatters less than a whole large job. And estimate a range: jumpy time is described more honestly by a from-to bracket than by a single number.

Estimating gets easier when you have something to lean on. Do It Today has a built-in focus timer that counts your work sessions across the day and the week, and the history of past days keeps a record of what actually took how long. After a couple of weeks you build a personal picture of real time by task type, and estimating stops being a guess. The app is free, installs on your phone, and works in both light and dark themes.