How to estimate the duration of a task?

Somebody in the planning meeting asks how long the task will take. You say six days. Nobody writes down that you meant somewhere between four and nine, with six as the likeliest figure, and from that moment the six is treated as a commitment.

That is where most schedule trouble begins. Not in the estimate, which is usually a reasonable guess, but in the loss of what surrounded it: the range, the assumptions, and the reason that number was chosen.

Estimating the duration of a task means producing two things: a central value and the margin around it, with a stated level of confidence. A project is a set of tasks, so the schedule is only as good as the estimates underneath it, and those margins tell you whether the end date is a plan or a wish.

Who should put a number on it

The estimate should come from people who routinely do work of the same kind. They know what the task involves once it starts, which parts take longer than they look, and what has to be ready before anybody begins. An expert opinion is often the fastest way to find out that the task as described is not the task that will be done.

What an opinion cannot do is check itself. An estimate is worth more when it rests on something recorded than on something remembered.

ITM Platform keeps four effort figures on each task: the hours estimated for a named person, the hours held against a professional profile nobody has been assigned to yet, the hours the team reports in timesheets, and an accepted figure a manager can set for consolidation. Effort management: estimated, actual and accepted explains how those four relate.

Risk and variability are not the same thing

Two different sources of uncertainty get folded into one number, and separating them is the most useful thing you can do before estimating anything.

An identified risk is an event that may or may not happen. Inherent variability is the spread that remains even when nothing goes wrong.

Padding each task to cover a risk hides both. The duration stops meaning what it says, the padding is invisible to everyone but the person who added it, and the risk is never managed, because nobody else knows it exists.

Identified risks belong in the risk process, where each one is assessed, given an owner and given a planned response, and the time they might cost is carried as a contingency reserve rather than buried inside each estimate. The six steps for controlling project risk set out that cycle.

What stays in the estimate is the variability that cannot be removed: the task runs longer or shorter depending on conditions nobody controls, and that spread is a property of the work itself.

Which method you can actually use

The method is not a matter of preference. It is decided by what you have on hand when the question is asked.

Method	What it needs	What it gives you	Where it breaks
Estimation by analogy	Recorded times for similar finished tasks	A central value and a measured confidence interval	No history, or history from work that was not similar
Parametric estimation	History at another size, plus a size driver you can measure	An estimate scaled to the job in front of you	A driver that moves with the work but does not drive it
Expert judgment	People who have done this kind of work	A usable range when nothing else is available	Nothing checks the estimate except another opinion

Estimating from your own history

Estimation by analogy starts from completion times for similar work, finished inside your own organization or published by somebody else. That sample gives you a mean completion time and a standard deviation, and if the durations are roughly symmetric it gives you confidence intervals directly.

mean ± 1 × standard deviation covers about 68% of past cases

mean ± 2 × standard deviations covers about 95%

mean ± 3 × standard deviations covers about 99.7%

Confidence and width pull against each other. Near the center, a small change in the band’s width moves the probability a lot; out in the tails it moves it very little. Going from two standard deviations to three buys about four percentage points and costs fifty percent more width, which is why 95% is the conventional working point. It is a convention rather than a measured fact about projects, and the exact 95% interval is 1.96 standard deviations, not 2.

Most teams never get this far, because the history exists but not in a form anybody can query. ITM Platform builds configurable lists and saved reports over tasks across projects, with filters, chosen columns, grouping and sorting, and exports to Excel. Reports and lists covers how those are built.

When the history is skewed rather than symmetric

Durations are frequently not symmetric, and the reason is structural: a task can finish a little early, but there is no limit on how late it can run. Data like that is often close to lognormal, which means the logarithm of the duration is normally distributed, giving a long upper tail that pulls the mean above the typical case.

Two things follow for an estimator:

• The average and the typical case are different numbers. Quote the median and a high percentile, the 85th for example, rather than mean and standard deviation.
• Do not delete the long tail. The runs that took three times as long are the distribution’s defining feature, not noise in it. A genuine outlier with an identified external cause, a supplier that failed or a reorganization mid-project, can be set aside with the reason recorded. Everything else stays in.

Sometimes the long runs share a cause, and often it is simply that those projects were much larger. That is the case parametric estimation exists for.

When there is no comparable project

Parametric estimation answers the same question when nothing in your history was done at the scale you are facing. Instead of borrowing a duration, you borrow the relationship between duration and a size driver, then apply it at your own size. Linear regression against that driver is the usual way to express it.

A worked example. A rollout has been done nationally in several small countries and several very large ones, with nothing in between, and the project in front of you is a medium-sized country. Fit the observed durations against population, which yields a correction factor per inhabitant, then interpolate to the population you are planning for. The estimate is no longer borrowed but scaled.

The learning curve deserves a correction of its own. Repeated work gets faster, so a sample drawn entirely from experienced groups is optimistic for a team doing it for the first time. The effect flattens rather than continuing indefinitely, so the correction should flatten too: the gap between the first run and the second is much larger than between the ninth and the tenth.

When all you have is judgment

Expert criteria is the least reliable method and sometimes the only one available, when no historical data exists or what exists is too scattered to fit anything to.

The mathematical methods also depend on human decisions, about which past projects belong in the sample and which model to apply. The dividing line is not whether people are involved, but how much of the estimate somebody else can check afterwards.

Two things make judgment more defensible. The first is to ask several experts independently and average the answers, which cancels part of each bias instead of letting the loudest voice set the number. The second is three-point estimation: ask for an optimistic duration, a most likely one and a pessimistic one, then combine them.

Triangular: E = (O + M + P) ÷ 3

PERT: E = (O + 4 × M + P) ÷ 6

With an optimistic estimate of 4 days, a most likely of 10 and a pessimistic of 22, the triangular form gives 12.0 days and PERT gives 11.0. Triangular treats all three inputs as equally informative and is pulled toward the pessimistic figure; PERT weights the most likely value. Pick one and apply it consistently, so estimates made by different people stay comparable.

One caution carries over. Experts tend to fold external risks into the pessimistic figure, which puts risk back inside the duration. Ask what the pessimistic case assumes, and move any identifiable event into the risk register.

From an estimate to a date

An effort estimate is not yet a duration, and the gap is where schedules go wrong even when the estimating was sound. Forty hours of work is one week for one person at full dedication, two weeks at half, and longer again if the calendar has holidays or the person is shared across projects.

Converting effort into dates takes four inputs: who does the work, what share of their time they give it, the working hours in the project calendar, and the non-working days. ITM Platform can set a task’s duration from its estimated effort: assign hours and a percentage of dedication to each team member, select the task, and the Gantt converts that into working days using the project’s working-hours schedule and holiday calendar, taking the span of whoever needs longest. Gantt chart describes that conversion.

Whatever the method, write the range and the assumptions next to the number, and keep the estimate beside the actual once the task closes. That is what turns this year’s guesses into next year’s history.

Next steps

• Try ITM Platform and put an estimate on a task you are planning this week, then compare it with the hours reported when it closes.
• What to Do When a Task Gets Delayed covers the conversation that follows when an estimate turns out to be wrong.
• See what planning and monitoring covers, from the work breakdown structure and the Gantt chart to progress against the baseline.