A duration estimate commits everything that follows: the end date, the budget, everyone's workload, and the credibility of whoever announced it. Yet it usually gets produced in thirty seconds, by the person least placed to produce it. Here is how to make an estimate that holds, and what degrades one before you even start.
What degrades an estimate before you start
Four factors weigh more than the method you pick. Knowing them stops you blaming the team for a gap that was never theirs.
The horizon
A task starting Monday estimates well. The same task eight months out estimates badly, and no method changes that. Precision decays with distance, because the context that will decide it does not exist yet.
The practical consequence: do not spend the same effort everywhere. Estimate finely what starts soon, roughly what comes later, and redo the exercise as the date approaches.
Complexity
The number of people involved matters more than the volume of work. A technically hard task owned by one person estimates better than a simple task that needs four departments to agree.
The competence of whoever estimates
This is the strongest factor, and the easiest to fix. Someone who has done the work before gives you a useful range. Someone imagining it gives you a number.
Attitude to risk
Given the same information, two people produce different figures. One adds a silent buffer so as never to be caught out, the other quotes the favourable case to look efficient. Both reflexes come from company culture as much as from personality, and they distort the estimate in opposite directions.
The remedy is easy to state: ask for a duration under normal conditions, and handle the buffer separately. More on that below.
Two ways to estimate, and a predictable conflict
Top-down estimating starts at the top. A manager compares with a neighbouring project and announces an overall envelope. It is fast, it is useful for deciding whether to launch at all, and it is rarely accurate: the person estimating does not do the work.
Bottom-up estimating starts at the bottom. You break the project down into elementary tasks, each one is estimated by someone who knows it, and the totals roll up. It takes longer, it is more accurate, and it produces a baseline to compare against later.
The conflict always lands in the same place: the top-down envelope has already been quoted to the client when the bottom-up figure arrives, and the bottom-up figure is higher. The negotiation that follows then turns on the credibility of the people in the room, for want of anything better.
The sequence that avoids this has five steps.
- A preliminary top-down estimate, presented as an order of magnitude.
- The project breakdown.
- The bottom-up estimate, task by task.
- The schedule, which accounts for dependencies rather than the sum of durations.
- Reconciling the two, with the sponsor.
The fifth step is the only one that really matters. It turns an end-of-project disagreement into a start-of-project discussion, at the moment when levers still exist: cut the scope, move the date, add people.
Six rules for estimating a task
They hold whatever project management method you have chosen.
1. Whoever does the work estimates it
This is the rule with the most effect. It improves accuracy, and it turns an imposed number into a commitment. One person estimates a given task, just as one person delivers it: two owners on one task means no owner at all.
2. Cross-check when you can
Everyone has biases. Two or three people estimating separately, then comparing the gaps, almost always surface the omission each of them made alone. The point is not the average of the figures, it is the conversation about the difference.
3. Define what normal conditions are
A duration only means something against a frame. How many hours a day does the person actually spend on this project? Is the equipment available? Are approvals instant?
Write those assumptions down. They earn their keep twice: to explain an overrun when a condition was not met, and to revise the estimate when the frame changes.
4. One unit, the same everywhere
Working day, hour, person-day: it does not matter, as long as you never mix them. The classic trap is confusing calendar days with working days. On a twenty-day task, that confusion costs a week.
5. Estimate each task on its own
The common mistake is to estimate a bundle of tasks, then split the total between them. The result is always optimistic: what makes each task specific disappears into the average, and the heaviest ones get hidden by the ones around them.
6. An estimate contains no buffer
This is the least intuitive rule, and the most useful. If everyone hides their own buffer inside their figure, nobody knows where the project's reserves are, or how much they add up to.
The estimate states the duration under normal conditions. The buffer is added afterwards, explicitly, by the project manager, from the risks actually identified. It then becomes a visible reserve that can be discussed and managed, instead of a pile of invisible precautions.
Three-point estimating, for what is uncertain
On a task nobody can pin down to the day, a single figure hides the disagreement instead of resolving it. Ask for three.
- Optimistic: everything goes well, nothing waits on anyone.
- Most likely: the realistic case, the one you would bet on.
- Pessimistic: things go badly, without a disaster.
The value of those three numbers is not the weighted average you derive from them, useful though it is. It is the gap between the optimistic and the pessimistic. A two-day gap signals a task under control. A three-week gap signals a task nobody understands, and that is fixed by going to find the information, not by adding days.
The weighting formula and the full calculation are set out in the article on the PERT formula and critical path calculation, together with the float that comes out of it.
What happens to an estimate once it exists
An estimate on its own is useless. Adding up task durations does not give you the project duration, because some tasks run in parallel and others wait.
Dependencies are what turn a list of durations into an end date, and what identify the critical path, the one chain where a day lost is a day lost for the whole project. It is also where a dependency nobody declared does the most damage.
Finally, keep your original estimates. Compared with reality at the end of the project, they tell you where your organisation is systematically wrong, and by how much. It is the only known way to get better at this.
Estimating your tasks in Orchesia
Every task created in the mind map opens onto a detail panel where you set the owner, the duration and the cost. The estimate therefore lives where the task is defined, not in a spreadsheet beside it.
The comment thread on each task is there for this: the person who will do the work answers directly, and the exchange stays attached to the task instead of being buried in an inbox.
Estimates are kept. Once dependencies are declared, the total duration, the critical path and the float are computed on their own, and the baseline holds a record of what was planned.
On a task nobody can estimate, the built-in assistant helps break it into smaller pieces. That is nearly always the right reflex: a task you cannot estimate is a task you have not broken down.
The rest is down to you, and to one habit: ask the person who will do the work, and ask them before you announce a date.
