How to Estimate Task Time When You Always Run Over

For most of my twenties I believed I was bad at time management. Every plan I made ran over. A report I gave myself two hours for took four. A "quick" tax return swallowed a Saturday. I tried new planners, new apps and stricter rules, and the days still collapsed by mid afternoon.

It took me an embarrassingly long time to see that the plans were fine. The numbers inside them were wrong. I was not failing to follow my schedule; I was building it on estimates that had never once been checked against reality. If your days keep spilling over no matter which system you use, the estimates are the first thing worth looking at.

Why your guesses are short, and not by accident

Psychologists have a name for this: the planning fallacy, first described by Daniel Kahneman and Amos Tversky in 1979. The short version is that when we estimate our own tasks, we picture the best plausible run of events and treat it as the likely one.

The study I find most convincing came from Roger Buehler, Dale Griffin and Michael Ross in 1994. They asked psychology students to predict when they would finish their honours theses. The average prediction was 33.9 days. The average actual time was 55.5 days. Even when asked for a figure they were 99 percent sure of, fewer than half of the students finished by it.

What struck me was that the students knew their past projects had run late. They simply did not use that knowledge. Each new task felt different, special, more under control. I recognised myself immediately.

There are a few specific things the mind leaves out when it imagines a task:

• Starting costs: finding the file, reopening the email thread, remembering where you stopped.
• Waiting: for a reply, a download, a colleague's approval.
• Small sub tasks that seem too minor to count, like renaming files or checking a figure twice.
• Interruptions, which you know will happen but cannot place in advance.

None of these feel like part of "the task" when you picture it. All of them take real minutes.

Why "just add a buffer" rarely fixes it

The standard advice is to pad every estimate by some fixed amount, usually 20 or 25 percent. I tried this for about a year, and it helped a little, but it has two problems.

First, the padding is invented. You are correcting a guess with another guess. My own errors turned out to be far bigger than 25 percent for some kinds of work and close to zero for others, so a flat buffer left me late on writing and early on admin.

Second, people quietly spend the buffer. Parkinson noticed in 1955 that work expands to fill the time available, and a padded slot often gets filled by a slow start rather than saved for the overrun. The buffer works best as a separate block late in the afternoon, not as extra minutes tucked inside each task.

Measure your own multiplier

What finally worked was boring. For two working weeks I wrote down an estimate before starting every task longer than about fifteen minutes, then wrote down the actual time when I finished. I used a plain notebook with three columns. No app, because I knew I would stop opening an app by day four.

At the end I grouped the tasks into types and divided total actual time by total estimated time for each. That ratio is your personal multiplier. Here is roughly what mine looked like:

Two weeks is a small sample, and I would not trust the decimal places. But the pattern was clear enough to act on. Admin was fine. Editing was fine. Writing took nearly twice as long as I thought, and anything involving unfamiliar software was a disaster. A flat 25 percent buffer would have hidden all of that.

Now when I plan a day, I make my gut estimate as usual and then multiply it by the figure for that type of work. A draft I "feel" will take two hours goes into the calendar as three and a half. It looks absurd every time. It is usually right.

Two smaller habits that help

Breaking a task into parts before estimating it tends to raise the estimate, and in a useful way. Justin Kruger and Matt Evans showed this in 2004: people who listed the steps of a task first gave longer, more accurate predictions than people who estimated the task as a whole. When I write "tax return", I think two hours. When I write "find P60, download bank statements, check pension figure, fill in online form, review", the list alone makes three hours seem reasonable.

The other habit is to ask how long the last similar task took, rather than how long this one should take. Researchers call it taking the outside view. In practice it just means looking back at the notebook or calendar before guessing. If last month's board report took five hours, this month's probably will too, however much more organised you feel.

If your estimates are realistic and your days still fall apart, the problem may sit elsewhere, and my notes on why time blocking fails for some people and on planning a daily schedule you can keep cover the next layer.

Start the log on Monday

Take a notebook or a single note on your phone and draw three columns: task, estimate, actual. Starting Monday, fill in one line for every task over fifteen minutes, for ten working days. Do not change how you work and do not try to beat your estimates; just record them honestly. On the second Friday, group the lines by type and work out your multipliers. It will take about twenty minutes, and you will know more about your own time than any planner can tell you. More on this side of the craft lives in the time management section.