The PERT Formula Explained: Why (O + 4M + P) / 6 Beats Your Gut Estimate
The PERT formula turns optimistic, most likely, and pessimistic estimates into an expected value and a standard deviation. Learn how it works, why the most likely value is weighted 4×, and how to use it across a whole project.
Ask an engineer how long a task will take and you get one number. Ask again after the task ships and the number was usually wrong - not because the engineer was careless, but because a single number cannot describe a range of possible outcomes.
The PERT formula is a sixty-year-old fix for that problem, and it remains the most practical one. It takes three honest inputs - an optimistic, a most likely, and a pessimistic estimate - and produces two outputs: an expected value you can plan around, and a standard deviation that tells you how much to trust it.
This guide walks through the formula itself, the reasoning behind its famous 4× weighting, and the part most articles skip: how to combine PERT estimates across an entire task list without inflating the total. If you want to follow along with real numbers, open our free PERT calculator in another tab.
What is the PERT formula?
The PERT formula estimates a task as a weighted average of three values: Expected = (O + 4M + P) / 6, where O is the optimistic estimate, M is the most likely estimate, and P is the pessimistic estimate. PERT stands for Program Evaluation and Review Technique, developed for the US Navy's Polaris program in the late 1950s.
Take a task estimated at best case 4 days, most likely 6 days, worst case 14 days. The PERT expected value is (4 + 24 + 14) / 6 = 7 days. Notice the result is higher than the most likely estimate - the long pessimistic tail pulls it up, which is exactly what your gut estimate fails to do.
Why is the most likely estimate multiplied by 4?
The weights come from approximating a beta distribution - a bell-like curve stretched between your optimistic and pessimistic bounds. Real task durations cluster around a peak: most of the time the work goes roughly as expected, occasionally it goes unusually well, and sometimes it goes badly. The 4× weight places two-thirds of the estimate's mass at that peak.
The alternative most teams reach for first is the triangular average: (O + M + P) / 3. It treats a one-in-a-hundred disaster scenario as seriously as the everyday case, which systematically inflates estimates. PERT keeps the tail risk where it belongs - in the standard deviation - instead of silently padding every task.
How do you calculate the PERT standard deviation?
The standard deviation is σ = (P − O) / 6. It measures how uncertain a task is: the wider the spread between your best and worst case, the less you should trust the expected value.
This is the part of PERT that single-number estimation throws away. Two tasks can share an expected value of 7 days while one is estimated 6–7–9 and the other 3–6–18. The first is a safe commitment. The second is a risk that needs monitoring, a spike, or a contingency line in the proposal. The standard deviation is what makes that difference visible.
How do you combine PERT estimates across a project?
Expected values add up normally: total expected effort is the sum of each task's PERT mean. Standard deviations do not. They combine using root-sum-of-squares: σ_total = √(σ₁² + σ₂² + …).
This matters more than it looks. Independent risks partially cancel out - some tasks run long while others run short - so a project's realistic worst case is far better than the sum of every task's worst case. Teams that pad every task and then pad the total again produce estimates nobody believes. Teams that add PERT means and combine deviations properly produce a total that is both honest and competitive.
How do you turn a PERT estimate into a commitment?
The PERT expected value is a P50 - a number you will beat about half the time. Quoting it to a client means a coin-flip chance of being late. The standard deviation lets you do better: add 1.036σ for an estimate you will hit 85% of the time, or 1.645σ for 95% confidence.
A worked example: ten tasks with a combined expected value of 400 hours and a combined standard deviation of 40 hours give a P85 of roughly 441 hours and a P95 of 466 hours. The choice between them is commercial, not mathematical - we cover how to pick in our guide to committing at the 85th percentile.
When should you not use PERT?
PERT assumes your three inputs are honest and roughly independent across tasks. It breaks down when the optimistic and pessimistic values are theater - a ±10% band around the most likely guess models nothing. It also understates risk when tasks share a common failure mode, like one legacy system every integration touches, or one specialist every task waits on.
For those cases the fix is not a better formula. It is modeling the shared constraint explicitly - as a dependency, a shared resource, or a separate risk item - and then letting PERT handle the residual task-level uncertainty. This is exactly the gap between running the formula in a spreadsheet and running it inside a plan that knows about dependencies and resource allocation.
Final thoughts
The PERT formula survives because it hits a sweet spot: three inputs any team can produce in a planning session, two outputs that support real commercial decisions. It will not make estimates correct - nothing does - but it makes uncertainty explicit, additive, and priceable.
If you want to try it without building a spreadsheet, our free PERT calculator runs the formula across a multi-task list, combines deviations correctly, and shows the P50, P85, and P95 totals side by side. For the broader method behind the three inputs themselves, start with our guide to 3-point estimation.
Explore the product on the features page section, compare flat pricing, or log in to plan your next project with the whole team in AxioPlan.