How this instrument works
PERT stands for Program Evaluation and Review Technique, a project-scheduling method developed for the U.S. Navy's Polaris missile program in the 1950s. Rather than asking for one single-point duration estimate, which tends to be overconfident, PERT asks for three: an optimistic time if everything goes right, a most likely time under normal conditions, and a pessimistic time if things go wrong. It then combines them into one expected duration using a weighted average.
The weighting isn't arbitrary — it comes from approximating the task duration as following a beta probability distribution, and the most likely estimate gets four times the weight of either the optimistic or pessimistic estimate. That weighting reflects a common-sense intuition: the most likely outcome should dominate the estimate, while the two extremes still pull it slightly toward whichever tail is more probable in a skewed schedule.
PERT expected time is most useful as an input to further scheduling work, not as a final answer on its own. Once you have an expected duration for each task on a project's critical path, those durations can be summed to estimate the whole project's expected completion time, and the same three-point inputs can be used to estimate schedule variance and confidence intervals around that total.
- Enter Optimistic time (O) — the duration if the task goes about as smoothly as it realistically could.
- Enter Most likely time (M) — the duration you'd genuinely expect under normal conditions, not a rounded guess.
- Enter Pessimistic time (P) — the duration if the task runs into real, plausible trouble, not a worst-case-imaginable outlier.
- Read Expected time (TE) — the PERT-weighted estimate the instrument computes from your three inputs.
- Keep all three estimates in the same time unit — days, hours, or weeks — since the formula has no unit awareness of its own.
Worked example — O=4, M=6, P=14 days
Enter 4 into Optimistic time, 6 into Most likely time, and 14 into Pessimistic time — a task the team expects to typically take six days, could finish in four under ideal conditions, but might stretch to fourteen if a dependency slips. Expected time reads (4 + 4x6 + 14) / 6 = (4 + 24 + 14) / 6 = 42 / 6 = 7.0 days.
Notice the expected time, 7.0 days, sits closer to the most likely estimate of 6 than a straight average of all three would: a simple mean of 4, 6, and 14 works out to 8.0 days, pulled upward by the wide pessimistic tail. PERT's 4x weighting on the most likely value is exactly what keeps a single unlikely worst case from dominating the schedule estimate.
Questions
Why does PERT weight the most likely estimate four times as heavily?
The formula approximates the task duration as following a beta distribution, and weighting the mode (most likely value) by four while giving the two endpoints a weight of one each approximates that distribution's mean reasonably well across a range of realistic skew. It's a modeling convenience validated by decades of use in scheduling, not an exact derivation from any single task's real probability distribution.
How is PERT expected time different from just averaging the three estimates?
A plain average of optimistic, most likely, and pessimistic gives all three equal weight, so a single extreme pessimistic guess can pull the estimate far from what's actually most probable. PERT's weighted formula counts the most likely estimate four times as heavily, keeping the result anchored closer to the realistic case while still letting the extremes nudge it in their direction.
What's a good pessimistic estimate — the worst case imaginable?
No — an unbounded worst case (a meteor strike, a company shutting down) would distort the formula. A useful pessimistic estimate is the duration if the task hits real, plausible trouble: a key person is out sick, a dependency is late, or a vendor slips a deadline. It should be a scenario you can actually picture happening, not a catastrophe.
Can I use PERT for an entire project, not just one task?
Yes, but apply it task by task first. Compute expected time for each task on the project's critical path individually, then sum those expected times to get the project's overall expected duration. Applying PERT once to a single 'whole project' guess loses the benefit of the method, which comes from estimating each task's own uncertainty separately.
Is PERT the same thing as the Critical Path Method (CPM)?
They're related but distinct: CPM identifies the longest sequence of dependent tasks (the critical path) that determines a project's minimum duration, typically using single-point estimates. PERT supplies a way to generate those duration estimates — and their uncertainty — from three-point inputs. Many project plans use PERT-derived durations as the inputs to a CPM schedule.
What happens if I enter a pessimistic time shorter than the optimistic time?
The instrument will flag it, since a pessimistic (worst-case) duration shorter than an optimistic (best-case) one is a contradiction — it means your three estimates aren't internally consistent. Double-check that optimistic is genuinely your fastest plausible case and pessimistic is genuinely your slowest before recomputing.