PERT vs Monte Carlo: your three-point estimate lies about the deadline

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.

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:

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.