QSRA explained: what Monte Carlo actually does to your schedule

Every quantitative schedule risk analysis begins with the same scene: someone senior looks at a Gantt chart and asks what the chances are of hitting the date on it. A deterministic CPM schedule cannot answer that question — not because it is wrong, but because it was never designed to. Here is what the simulation actually does, and how to read what comes out of it.

The question the Gantt chart cannot answer

The boardroom version goes like this. The programme director points at the completion milestone — 14 June — and asks, reasonably enough, "what's the chance we hit June?" The planner has exactly one piece of information to offer: the date itself. The schedule says 14 June because every activity in it carries a single duration, the CPM engine added them up along the longest path, and 14 June is what fell out. Asked for a probability, the deterministic schedule can only shrug: either it happens or it doesn't.

The problem is baked into the inputs. A single-point duration — "piling, 45 days" — is a claim of certainty that nobody in the room actually believes, including the person who estimated it. Everyone knows piling might take 38 days or might take 70. But CPM arithmetic has no slot for "might": it takes one number per activity and produces one date, with the same confident precision whether the underlying estimates were measured from ten previous projects or invented in a tender war room at 11pm.

A QSRA — quantitative schedule risk analysis — exists to put the uncertainty back in. It does not replace the CPM model; it runs the same model thousands of times and is honest about the fact that the inputs were always ranges pretending to be numbers.

What the simulation actually does

Strip away the vendor gloss and Monte Carlo simulation on a schedule is four steps, none of them clever:

1. Replace each single-point duration with a distribution. Instead of "45 days", piling becomes "between 38 and 70 days, most likely 45" — expressed as a triangular, PERT (BetaPERT) or uniform distribution. Where those ranges should come from is a craft in its own right, and the subject of its own article.
2. Sample once from every distribution. The engine draws one duration for each ranged activity — piling gets 52 days this time, cladding gets 31, and so on through the network.
3. Recalculate the whole network with those sampled durations. A full CPM pass: forward pass, backward pass, new critical path, new completion date. That single recalculation is one iteration. Record the completion date and which activities sat on the critical path.
4. Repeat, typically 3,000–10,000 times. Each iteration is one plausible version of how the project might unfold. The pile of recorded completion dates is the output.

That is the whole trick. No exotic mathematics — just the CPM calculation your scheduling tool already performs, executed a few thousand times with the dice rolled fresh each pass. Everything useful in a QSRA report is a different way of summarising that pile of iterations.

Reading the output: the histogram, the S-curve and the P-levels

Sort the few thousand completion dates into weekly bins and you get a histogram: the completion-date distribution. Accumulate it left to right and you get the S-curve — for any date on the x-axis, the proportion of iterations that finished on or before it. That proportion is what the percentile labels mean:

• P50 — half the iterations finished by this date. A coin-toss commitment.
• P80 — 80% of iterations finished by this date. The fashionable commitment level in UK infrastructure, for reasons we'll come to.
• P90 — nine iterations in ten finished by this date. Where funders and boards like to live.

The detail that startles people the first time: the deterministic date almost never sits at P50. On real networks it typically lands somewhere between P10 and P30 — the schedule of record turns out to be a date the project's own risk model says it will miss seven or eight times out of ten. That is not a software quirk. It has a structural cause, and the cause has a name.

Merge bias: why your date was optimistic before anyone touched it

Take two parallel work streams that both feed one milestone, and suppose each — considered alone — has a 50% chance of finishing on time. What is the chance the milestone is hit? Not 50%. The milestone needs both paths home, and 0.5 × 0.5 = 0.25. Two coin-toss paths give the milestone they feed a one-in-four chance. Four parallel coin-toss paths give it about 6%.

This is merge bias, also called path convergence, and it is the main reason deterministic dates sink towards the left tail. The expected finish of the maximum of several uncertain paths is later than any individual path's expected finish — slippage on the latest path passes straight through to the milestone, while an early finish on one path is wasted unless every other path is early too. Uncertainty at a merge point only has one direction to push.

A deterministic CPM calculation implicitly assumes every merge in the network resolves favourably at once. Real programmes have dozens of merge points. The simulation does nothing more sophisticated than refuse to make that assumption, several thousand times in a row.

The risk-critical path is not the critical path

Because every iteration recalculates the network, the critical path is free to move — and it does. The criticality index records, for each activity, the percentage of iterations in which it sat on the critical path. On a healthy network the results are humbling for the deterministic view: the path your Gantt chart paints red might be critical in only 40% of iterations, while a "near-critical" path with ten days of float but a wide, ugly duration range drives the finish date in the majority of them.

Deterministic float, in other words, is a worse guide to where the danger lives than most people assume — a point we laboured in our article on float. A path with modest float and high uncertainty is more dangerous than a path with zero float and durations you could set your watch by. CPM can only show you the second one. The criticality index shows you both, plus paths that never once appear critical in the static view.

Tornado charts: what sensitivity tells you that criticality doesn't

The criticality index tells you where an activity sits; it doesn't tell you how much it matters. For that, QSRA tools compute duration sensitivity — the correlation, across all iterations, between an activity's sampled duration and the project completion date. Rank activities by that correlation and you get the tornado chart.

The two measures disagree more often than you'd expect, and the disagreements are the insight. A short, well-understood activity can sit on the critical path in 90% of iterations (high criticality) while barely moving the completion date, because its duration scarcely varies. A long activity with a brutal range can show middling criticality but top the tornado, because in the iterations where it goes wrong, it goes wrong by months. If you have budget to de-risk three activities, the tornado — not the red bars in your Gantt chart, and not the loudest stakeholder — tells you which three.

What a QSRA is actually for

Three legitimate uses, in roughly ascending order of organisational maturity:

• Setting contingency honestly. The gap between the deterministic date and the P80 is not pessimism — it is the time contingency the network's own structure demands. Carrying it as a visible, owned allowance beats discovering it one update at a time. Under NEC4 ECC, where terminal float belongs to the contractor and must be protected through compensation events, knowing the size of that buffer quantitatively is not optional sophistication; it is contract administration.
• Choosing a commitment level deliberately. Much of UK infrastructure — the major rail and highways clients in particular — has settled into a P80 culture: internal teams drive to something near the P50, the external commitment is made at P80, and the difference is managed contingency. You may disagree with P80 as a convention; the point is that a P-level commitment is a chosen level of confidence, where a deterministic commitment is an unexamined one.
• Targeting mitigation at what drives the distribution. The tornado converts "everything is a risk" into a ranked shortlist. Money spent compressing the top two sensitivity drivers moves the P80; money spent on activity 14 of the tornado moves a meeting agenda.

And one illegitimate use, for completeness: generating an S-curve to decorate a gate review, filed and never revisited. A QSRA whose inputs aren't refreshed as the schedule updates is a photograph of a forecast — we cover the living-forecast discipline, along with everything else about preparing inputs that deserve belief, in the companion piece on building a risk-loaded schedule.