The planning fallacy: a five-day task that was really thirteen

Five days, finishing Thursday

The task was estimated at five days of work, and the plan showed it finishing on Thursday of the following week. Nobody questioned it. The estimate came from the engineer who would do the work, and he knew the task well.

The person who saw it first

Nadia, the planner, looked at who was assigned rather than at the estimate. The engineer worked six-hour days under his contract, and he was shared with a second project at half his time. Five days of work, at eight hours a day, was forty hours. At three hours a day on this project, it was more than thirteen working days on the calendar.

She did not change the estimate. The work was still forty hours. She told the plan the truth about the person: his day length and his share of time. The finish date moved before the work started, not after it slipped. The client heard the real date in the first week and planned around it, and the project manager never had to explain a surprise.

The textbook name: the planning fallacy

The planning fallacy is the well-documented tendency to underestimate how long work will take, even when we know similar work took longer before. In projects it has a very practical form: we estimate the work, and forget the person who has to do it. Estimates are made in ideal days, while people work real days of different lengths, on several projects at once, with holidays and other commitments.

The gap is not in the estimate. It is in the conversion from effort to calendar, and that conversion is usually done by a tool that assumes everyone works the same full day on one task at a time.

Signs to watch for

The planning fallacy leaves a trail. Tasks that consistently finish later than planned even though the hours spent match the estimate. People assigned to several projects at full time each. A plan in which every person works the same eight-hour day, every day, with no holidays. Finish dates that are discovered by the team rather than shown by the plan.

Another sign is the way slips are explained. If the explanation is usually that he was also on another project, or that she only works mornings, the information existed before the plan was made. The plan simply did not use it.

The cost is paid in trust. A plan that is wrong from the first day teaches the team and the client to ignore it. Once that happens, the plan stops being a tool for decisions and becomes a document that is updated after the fact to match what already happened.

How to prevent it

Separate effort from duration. Estimate the hours of work. Then let each person's real working day, from his own calendar, and his real share of time on the task, turn those hours into dates. When someone is shared, say so in the plan. And use the same figures everywhere, so that the plan, the expected hours and the cost never disagree about what a day is.

It also helps to look back. After each task, compare the planned and actual hours and the planned and actual dates separately. If the hours match and the dates do not, the estimate was right and the conversion was wrong. If the hours do not match, the estimate needs work. Keeping the two apart tells you which of the two problems you actually have.

How ApprovedFlow does it

In ApprovedFlow each person has one working-day length, from his own calendar, and a share of his time on each task. The plan, the list of missing time and the cost all use the same figures. Change his share, and the finish date answers at once. Change the task's hours, and each person's hours follow by his share.

A question for you

In your plan, is a day the same length for everyone, and is that true?