PERT vs Monte Carlo: three-point estimates lie

PERT squeezes a whole range of outcomes into one average. Here is why that fails on a real 10-task project, and what to do instead.

Why PERT compresses risk out of your estimate

PERT takes your optimistic, most-likely, and pessimistic figures for a task and fuses them into one expected number. For a task estimated at 6 / 10 / 20 days with a standard Beta-PERT weighting (lambda 4), the expected duration is:

(6 + 4 × 10 + 20) ÷ 6 = 11 days.

One number vs. the distribution it came from PERT mean · 11 days What PERT gives you the range collapsed into one number client date · 14 days What Monte Carlo gives you the tail that decides whether you lose money Bars past the date are the worlds where the promise breaks — PERT never showed you they existed.
Same task, same three numbers. PERT answers “how long on average?”; the simulation keeps the failure tail visible — and it is the tail that signs contracts.

That single number is useful for sequencing. It is useless for the question you actually get asked: will we finish by the 14th? An average is not a probability. Eleven days expected tells you nothing about whether finishing inside fourteen is a 95% bet or a 55% bet — and those two situations deserve very different promises to the client.

Where the average hides the damage

Dependencies make it worse. Averages of individual tasks do not add up to an average project: when task C cannot start until A and B both finish, the delay of whichever one slips last lands on you. Sum the expected values and you quietly assume the middle happens everywhere at once.

Discrete risks are worse still. Suppose there is a one-in-five chance your supplier misses a delivery and pushes the build two weeks late. A weighted average spreads those two weeks across the whole probability mass, so they all but vanish from the number you quote. The 20% of worlds where the project is two weeks late simply disappear into the arithmetic.

None of this means PERT is wrong at what it does. It means PERT answers about how long, on average, while a fixed-price bid needs what is the probability we finish inside this number. Those are different questions.

A ten-task example

Take a ten-task build, each task estimated optimistically / most-likely / pessimistically, several tasks dependent on earlier ones, and one supplier risk with a 20% chance of a two-week slip. PERT-style arithmetic gives you a single expected finish date. Simulating the same network with a Monte Carlo run gives you the full distribution:

MethodResult
PERT expected totalDay 44
Simulated P50Day 46
Simulated P80Day 51
Simulated P90Day 54

Notice that the PERT total lands below even the median of the simulation. The gap comes from the dependency structure and the supplier risk: PERT cannot see either, because it averages risk into nothing before the network is ever built.

If you quoted the PERT total as a deadline, you would be promising a date you miss more often than you hit. If you quote the P80, you carry an 80% chance of landing on or before the date you promised.

What a network simulation does differently

Monte Carlo does not replace the three-point estimate. It keeps your per-task optimistic / most-likely / pessimistic figures and draws from each distribution thousands of times, then runs the real dependency network every iteration. Risks that fire only sometimes fire on the right fraction of runs. The result is an honest histogram of finish dates and costs instead of a single average.

Try it on a single task first with the free PERT calculator — it shows the full distribution behind one three-point estimate. The underlying model, including how the Beta-PERT spread is chosen, is documented on the methodology page. When you are ready to run the whole network of tasks, dependencies, and discrete risks at once, the app does exactly that: 5k to 100k iterations, seeded so you can reproduce the same answer twice.

The takeaway

A three-point estimate is the raw material of a good forecast, not the forecast itself. The moment a second task depends on the first, and a real risk has a real probability, the arithmetic of averages stops telling you what you need to know. Quote from the distribution, not from the mean — and if you only remember one number from a simulation, make it the percentile you can live with, not the one that happens to sit in the middle.

Try the calculation or follow the workflow

Browse the complete resource library →