Aggregating Task Estimates: Why Summed Ranges Come Out Too Narrow

A plan built from task estimates fails in a characteristic way. Each task carries a range that the people doing the work consider reasonable, the ranges are added end to end, and the resulting total is presented as the plan. When the work overruns, the post-mortem usually blames the individual estimates. The arithmetic deserves more suspicion than the estimators, because adding ranges is not a valid operation on anything except variances, and even then only under conditions that projects routinely violate.

What a three-point estimate actually encodes

The classical three-point method, introduced with PERT in 1959, asks for an optimistic, a most likely, and a pessimistic duration per activity, then approximates the activity’s mean and standard deviation as:

mean = (O + 4M + P) / 6, standard deviation = (P − O) / 6

The weights come from fitting a beta distribution whose mode is M and whose support is [O, P]. Two properties of that model matter here. The distribution is bounded, so P is an absolute maximum that the estimator asserts cannot be exceeded. And the shape is right-skewed whenever P is farther from M than M is from O, which is the normal case for engineering work, since the left tail is floored by the minimum time to type something and the right tail is open to rework and discovery.

The boundedness is the first weak point. A distribution with a hard upper bound assigns zero probability to the events that actually wreck schedules: the vendor whose API differs from the documentation, the migration that requires a second migration, the reviewer who is unavailable for a week. Truncating the tail does not remove the events; it removes them from the model.

The diversification argument and why it does not hold

If task durations were independent random variables, aggregation would be reassuring. Means add, variances add, so for n tasks with equal standard deviation sigma the total has mean n·mu and standard deviation sigma·sqrt(n). Relative uncertainty, the ratio of standard deviation to mean, falls as 1/sqrt(n). Twenty independent tasks each with a 30 percent relative spread would produce a total with about 7 percent spread. Under that model, a sum of ranges is not too narrow; it is arguably too wide, and the correct aggregate interval is tighter than intuition suggests.

The model fails because independence is false. Two regimes bracket the truth:

Assumption	Total standard deviation	Relative spread vs single task
Fully independent	sigma · sqrt(n)	shrinks by sqrt(n)
Fully correlated	sigma · n	unchanged

Perfect correlation means every task is exposed to the same unknown: an unfamiliar platform, a service whose owner is being reorganised, a compliance review that nobody has scoped. When one of those goes wrong, it goes wrong for all twenty tasks at once, and the total spread is the sum of spreads. Real portfolios sit between the rows, and the honest position is that the correlation coefficient is unknown, which is itself a reason not to publish a single tight interval.

Medians do not add

A subtler error survives even with independence. Teams usually quote the duration they consider most likely, which behaves like a median. For a right-skewed distribution the median is below the mean, and the median of a sum is not the sum of the medians. The sum of many skewed variables converges towards a normal shape by the central limit theorem, and its median converges towards its mean. Since each task’s mean exceeds its median, the total’s median exceeds the sum of the task medians. The gap grows with the skew and with the number of tasks, and it appears with no individual estimate being wrong.

import random, statistics

random.seed(7)
n, trials = 20, 20000
# Each task: median 2 days, right-skewed, roughly 1.5x spread to the upper side.
def task():
    return random.lognormvariate(mu=0.0, sigma=0.5) * 2

sum_of_medians = n * 2.0                      # what naive addition reports
totals = [sum(task() for _ in range(n)) for _ in range(trials)]
print(sum_of_medians, statistics.median(totals))

The two numbers differ by an amount set by the skew, on the order of ten percent of the total for this shape, and always in the same direction. The gap is a property of the distributions, not of anyone’s optimism, so it cannot be corrected by asking for better per-task numbers.

The same effect explains why the sum of twenty “two day” tasks does not complete in forty days even when every task really does take two days at its most likely. Roughly half of the individual tasks finish early, balancing the ones that finish late, but the plan is judged against one date, so the early finishes buy nothing while the late ones consume the buffer.

Scope grows while the sum is being computed

A sum is taken over the task list as it exists at planning time. The list is not fixed: integration work, review cycles, environment provisioning, and the investigation of an unexpected failure each arrive as new tasks after the plan is agreed. If the number of tasks is itself random with mean n and spread, the total inherits that spread multiplicatively rather than additively, and the plan’s interval covers only the part of the work that was visible.

There is a related selection effect. When a total exceeds what the schedule allows, scope is trimmed until the arithmetic fits, and the trimmed plan is then treated as an estimate rather than as a decision about what to leave out. The published number and the actual work diverge by construction, and no amount of re-estimation closes the gap while the target is an input to the estimate.

Convergence points and the probability of a date

Most plans are not a single chain but a set of parallel branches that merge. At a merge, the earliest possible completion is the maximum over the branches, not the mean. If k branches each have probability p of finishing by a common date, and the branches are independent, the merge holds that date with probability p^k: two branches at 0.9 give 0.81, four give about 0.66. This merge bias means that a plan in which every branch is “likely” to be on time is a plan that is unlikely to be on time overall, even when every branch estimate is unbiased.

Dependencies make the effect worse. A merge point has no float downstream until the last branch arrives, so the whole schedule absorbs the maximum of several random variables, and the maximum of several skewed variables sits deep in the upper tail. Oversubscribing the same people across branches creates negative correlation between them, which prevents any one branch from finishing early even while the merge waits for the slowest: shared capacity is consumed by whoever is late, not by whoever is nearly done. The critical path computed from mean durations is therefore not the path that determines the date; the path with the largest upper-tail exposure usually is.

Estimating the total as a total

The alternative is to stop composing the total from parts. Top-down estimation takes the size of the whole job, measured in whatever unit the organisation can compare across jobs, and applies a rate derived from completed jobs of similar size. Parametric models such as COCOMO work the same way, fitting effort as a function of size and a set of cost drivers. The variance of the prediction comes from the historical spread of actuals around the model, not from the sum of imagined task-level ranges.

Where a task-level breakdown is needed for coordination, the defensible aggregate is produced by simulation rather than addition: sample each task from a distribution with an explicit tail, add a shared factor representing common-mode risk, and read the 50th and 85th percentiles off the resulting totals. The output is a distribution, and the number reported should be a percentile with its meaning stated, which is the discipline described in calibrating interval estimates. A single number without a percentile behind it invites the reader to assume the middle, which is the one value a skewed total is least likely to take.