How long, honestly?

Three estimates per activity, weighted into one number — and uncertainty combined the right way along the path, which is where this calculation usually goes wrong.

HomeProject Management › PERT

Three-point estimates, and what they say about a date

Optimistic, most likely, pessimistic. This weights them, adds the uncertainty correctly along the path, and is careful about what that does and does not prove.

Local tool — your project data stays in your browser
A planning aid, not a commitment. Everything here is calculated from figures you typed. A schedule is only as good as its estimates and its dependencies, and neither of those is something arithmetic can check for you. Treat the output as a way to test a plan, not as a promise to anyone about a date.
To get a probability of meeting it.

Activities on one path

These should be activities that run in sequence — typically your critical path. Uncertainty adds along a chain, not across parallel work.

Per activity

Confidence across the path

Your project stays in this browser. Task names, owners, durations, dates and estimates are calculated on your own device. Nothing is uploaded, stored on a server, or included in analytics — project content is never passed to the advertising or analytics scripts on this page.
How this is calculated

Beta-PERT: expected = (o + 4m + p) ÷ 6

Triangular: expected = (o + m + p) ÷ 3

Spread: σ = (p − o) ÷ 6, and variance = σ²

Along a path, variances add — standard deviations do not. This is the error worth knowing about. Adding the standard deviations of four activities instead of their variances roughly doubles the apparent spread, which turns a reasonable plan into an alarming one. The correct combination is σtotal = √(Σ σ²), so uncertainty grows with the square root of the number of activities, not in proportion to it.

Percentiles use a normal approximation of the summed path, which is reasonable for a chain of several activities and progressively worse for one or two.

The /6 is a convention. It assumes the optimistic-to-pessimistic range spans about six standard deviations. Nobody measured that for your project. It is a defensible default and it is not a fact.

Why the mode is not the estimate

Ask anyone how long a task takes and you get the most likely case — the version where nothing surprising happens. That is a real answer to a different question. Work has a floor and no ceiling: it can rarely finish much faster than the good case, and it can overrun almost without limit.

That asymmetry is what the weighting captures. If a task is most likely four days, could be done in two, and could take twelve, the expected duration is five — above the most likely value, because the long tail has to go somewhere. Planning to the mode across twenty tasks is how projects end up late without any single task being dramatically wrong.

The error that doubles your uncertainty

Variances add along a path. Standard deviations do not. It is an easy thing to get wrong because standard deviation is the number people quote, and adding the quoted numbers feels like the natural move.

For four activities each with a standard deviation of 1.67 days, adding directly gives 6.67 days of spread. The correct answer is √(4 × 1.67²), which is 3.33 — exactly half. One of those numbers supports a sensible contingency and the other supports a panic.

What a probability here is worth

If this reports an 80% chance of finishing within a target, that figure is conditional on a great deal: that your three-point estimates are honest, that the activities are genuinely independent, that the path you entered stays critical, and that the six-sigma range convention holds.

The independence assumption is usually the weakest. Real project delays are correlated — the same absent specialist, the same late supplier, the same optimistic team affects several activities at once. Correlated delays make the real spread wider than this calculation shows, which means the honest reading of an 80% figure is "reasonably likely under favourable assumptions," not "four times out of five."

Where this stops and simulation starts

This treats your path as fixed. In a real network, a near-critical path can overtake the critical one once durations start varying, and then the whole calculation is describing the wrong chain. A path that is two days shorter but far more uncertain will govern the finish more often than its length suggests.

Answering that properly needs a simulation across the entire network rather than arithmetic along one path. That is a genuine limitation of the method rather than of this page, and it is worth knowing which questions it can actually answer.