Most project estimates fail in a predictable way: a single number is given, it turns out to be optimistic, and nobody can say how uncertain it was. The Programme Evaluation and Review Technique, universally known as PERT, was developed in the 1950s for the Polaris missile programme precisely to handle that problem. Instead of asking for one duration per task, PERT asks for three: an optimistic estimate, a most likely estimate, and a pessimistic estimate. Those three numbers are combined into an expected duration and a measure of uncertainty, and the uncertainty can then be carried through to the whole project. The result is not a promise, but it is a far more honest basis for committing to a date.
The three inputs each have a specific meaning, and sloppy definitions are the most common source of bad PERT estimates. The optimistic time, O, is the duration if everything goes better than expected, not a fantasy in which nothing can go wrong, but a genuinely achievable best case. The most likely time, M, is the duration under normal conditions, the figure an experienced person would give if asked for a single number. The pessimistic time, P, is the duration if things go badly, short of catastrophe: the supplier is late, a key person is ill, a review cycle slips. If the pessimistic case includes disasters that would cancel the project, it will distort everything downstream, so it should be a bad-but-plausible outcome. Getting a team to give all three numbers is itself valuable, because the spread between them reveals how much is actually known about the task. A task estimated at 4, 5, and 6 days is well understood; a task estimated at 2, 5, and 20 days is not, and that ignorance deserves attention before the schedule is built.
The PERT expected duration is a weighted average: expected time = (O + 4M + P) / 6. The most likely estimate gets four times the weight of either extreme, which reflects the assumption that outcomes cluster near the most likely value with a beta-like distribution. The standard deviation, which measures the uncertainty, is (P − O) / 6. That formula comes from the rough statistical rule that nearly all outcomes of a bell-shaped distribution fall within three standard deviations either side of the mean, so the full spread from optimistic to pessimistic spans about six standard deviations. Both formulas are approximations, and they should be presented as such, but they are good enough to turn vague unease about a deadline into a quantified judgement.
Consider a worked example with a single task. A software feature is estimated at an optimistic 4 days, a most likely 6 days, and a pessimistic 14 days. The expected duration is (4 + 4 × 6 + 14) / 6. Four times six is 24, and 4 + 24 + 14 is 42, so the expected duration is 42 / 6, which is 7 days. Note that the expected value, 7 days, is higher than the most likely value, 6 days, because the long pessimistic tail pulls the average upward. That asymmetry is realistic: tasks overrun more often and by more than they underrun. The standard deviation is (14 − 4) / 6, which is 10 / 6, about 1.67 days. So the task is expected to take about 7 days, with a typical variation of roughly 1.7 days either way.
Now extend the example to a small project of two tasks in sequence. The second task is estimated at an optimistic 2 days, a most likely 3 days, and a pessimistic 10 days. Its expected duration is (2 + 4 × 3 + 10) / 6, which is (2 + 12 + 10) / 6, which is 24 / 6, exactly 4 days. Its standard deviation is (10 − 2) / 6, which is 8 / 6, about 1.33 days. For tasks in sequence, expected durations add: the project expected duration is 7 + 4, which is 11 days. Variances, which are squared standard deviations, also add for independent tasks: the first task's variance is 1.67 squared, about 2.78, and the second's is 1.33 squared, about 1.78, giving a total variance of about 4.56. The project standard deviation is the square root of 4.56, about 2.14 days. The project is therefore expected to take about 11 days with a standard deviation of about 2.1 days.
That pair of numbers lets you answer the question managers actually ask: what are the chances of meeting a deadline? Using the normal approximation, compute a z-score: the deadline minus the expected duration, divided by the standard deviation. For a deadline of 14 days, the z-score is (14 − 11) / 2.14, which is 3 / 2.14, about 1.40. A z-score of 1.40 corresponds to roughly a 92 percent probability of finishing by the deadline. For a deadline of 11 days, the z-score is zero, giving about a 50 percent chance, which is another way of saying that committing to the expected duration itself is a coin flip. For a deadline of 9 days, the z-score is (9 − 11) / 2.14, about −0.93, corresponding to roughly an 18 percent chance. Presented this way, a deadline stops being a matter of optimism and becomes a risk decision: how much probability is the organisation willing to buy with extra time, scope cuts, or added resources?
Applying PERT to a real project means applying it along the critical path, the longest chain of dependent tasks that determines the project duration. Tasks off the critical path have float, and their uncertainty matters less unless it grows large enough to make them critical. A common refinement is to compute the expected duration and variance for every task, find the critical path using expected durations, and sum the variances along that path only. Near-critical paths deserve a glance too, because a path that is only slightly shorter can become critical if its tasks overrun. None of this requires sophisticated software for a small project; a spreadsheet with the two formulas per task and a sum along the path is enough, and the discipline of writing down three estimates per task is worth more than any tool.
PERT has honest limitations. The formulas assume task durations are independent, which is often false: a late supplier, a shared specialist, or a bad week can delay several tasks at once, making the true project variance larger than the sum suggests. The beta-distribution assumption behind the weighting is a modelling convenience, not a measured fact. And the method is only as good as its inputs: estimates produced under pressure to please a manager, or copied from a previous project without thought, will produce precise-looking nonsense. The remedy is to estimate in a setting where honesty is safe, to record the reasoning behind extreme values, and to revisit the estimates as work progresses and uncertainty resolves. A PERT estimate updated halfway through a project, with completed tasks replaced by actuals, is far more useful than the original estimate defended unchanged.
Used well, PERT changes the conversation about deadlines. Instead of arguing about whether a date is "realistic" in the abstract, a team can say that a date carries a ninety percent chance, a fifty percent chance, or a twenty percent chance, and can decide explicitly what level of risk to accept. That clarity is the technique's real contribution, and it survives even when the individual estimates prove imperfect.
Try it next: use the PERT Project Estimator with your own three-point estimates, then check percentage confidence with the Percentage Calculator and average durations with the Average Calculator. For background reading, see Maintenance Work Orders Explained.