Monte Carlo basics for project risk

A Monte Carlo simulation answers the question "what could happen?" by sampling. You take a model that has uncertain inputs, randomise the inputs across their plausible ranges, run the model thousands or millions of times, and read the distribution of outcomes. In project risk quantification (PRQ), the model is "the sum of every risk's impact, weighted by whether it triggered" and the inputs are per-risk probability of occurrence and per-risk impact distribution.

The technique was named for the Monaco casino district by the physicists who codified it during the Manhattan Project. The method long predates them — anyone who's rolled dice to estimate a probability has used Monte Carlo informally — but the rigorous version with quantified distributions and large iteration counts is what the term means today.

Why simulate at all?

The deterministic alternative is a single contingency number set by a rule of thumb: "add 15% to the base estimate". That works as a budgeting heuristic but loses the shape of the uncertainty. A project with two near-certain medium-cost risks and a project with one tail-event catastrophic risk could both warrant a 15% contingency under a heuristic; a Monte Carlo run separates them cleanly.

Specifically, simulation gives you four things a deterministic estimate doesn't:

1. The full distribution of total impact, not just a point estimate. You can see whether the right tail is fat (concentrated downside) or symmetric (impact is generally well-bounded).
2. Confidence-bounded percentiles. "Carry $X to have an 80% probability that contingency suffices" is a defensible claim; "carry 15% because we always do" isn't.
3. Sensitivity to specific risks. The tornado chart ranks each risk by how much variance it contributes — so you know which risks to invest treatment effort on first.
4. Scenario testing. Bump one risk's mode upward, re-run, see the contingency move. The model becomes a conversation tool, not just a one-time deliverable.

How PRQ runs the simulation

For each iteration i of N:

1. For each active risk in the register, draw a uniform random in [0, 1). If it's below the risk's probability, the risk triggered for this iteration.
2. For triggered risks, draw a sample from their impact distribution (triangular, PERT, or fixed — see probability distributions in PRQ).
3. Sum the per-risk samples. This is the iteration's total impact.

After all N iterations, sort the totals and read off the percentiles. The 50th-percentile value is the median outcome (P50); the 80th is the value that 80% of iterations fell at or below (P80); the 90th is the same for P90.

Reading P50, P80, P90

These three percentiles do different jobs. Treating them interchangeably is the most common Monte Carlo mistake.

P50 — the median outcome

Half the time the total impact will be below this value, half above. Useful for the expected story: "in a typical outcome, expect about $228k in total risk-driven cost". Don't carry P50 as your contingency — by construction you'd be under-funded half the time.

P80 — the recommended contingency

80% of iterations land at or below this value. Carrying P80 as contingency means you have an 80% confidence that the budget won't be breached by risk events. This is the value PRQ treats as the default contingency recommendation; it's also the value the headline narrative paragraph and the hero StatCard on the results page emphasise.

Why 80%? It's a defensible balance between under-budgeting (P50 is too generous to risk) and over-budgeting (P95 is too defensive for routine projects). 80% is the percentile you'll see in most major-project guidance — UK Government Treasury Green Book, AACE International Recommended Practice 41R-08, and most internal oil-and-gas / construction governance frameworks.

P90 — the tail check

90% of iterations land at or below this value. The gap between P80 and P90 tells you how rough the tail is. A small gap (P80 to P90 is, say, 1.4× P80) means most of the variance is captured below the contingency line. A large gap means there's meaningful tail risk you're explicitly choosing not to fund — a conversation with the project sponsor follows.

The independence assumption

By default, PRQ samples each risk's trigger and impact independently of every other risk. In reality, risks are often correlated — a vendor outage and a schedule slip might co-occur because they share an underlying root cause. Independent sampling will understate the tail in the presence of positive correlation, because correlated risks tend to either all trigger together (very-high outcome) or none trigger (very-low outcome), giving a wider distribution than the independent case.

PRQ supports specifying pairwise rank correlations between active risks via the Iman-Conover method. When a non-identity correlation matrix is in play, the simulation reorders the per-risk impact samples to match the target rank correlation while preserving each risk's marginal distribution. The methodology disclosure on the results page flips from "independence assumed" to "rank correlations specified — see correlation heatmap" so the provenance is honest.

What the engine doesn't do

Three deliberate limits worth knowing:

• No seedable PRNG. PRQ uses Math.random() directly. Re-running the simulation will produce slightly different P50/P80/P90 values each time (within the convergence band). If you need reproducible runs for an audit, increase iteration count until the values converge to within your tolerance, or export the result and attach it to the audit pack.
• No second-order uncertainty. The probability and distribution parameters per risk are treated as known. PRQ doesn't model uncertainty in the parameters themselves (e.g. "we think the impact is somewhere between TRI(50, 120, 350) and TRI(80, 200, 500)"). For high-stakes models that matters; for most project work it doesn't.
• No risk dependencies beyond pairwise rank correlation. If risk A only triggers when risk B has triggered, PRQ won't capture that without modelling them as a single composite risk. This is fine for almost all project work — actual conditional dependence is rare in practice.