Methodology

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.

It is described in AS/NZS IEC 31010:2020 at B.5.10, under techniques for understanding consequences and likelihood. Two things there are worth knowing up front. The standard notes that models "can be developed using spreadsheets and other conventional tools, but more sophisticated software tools are available" — this is not a technique that requires a licence. And it is explicit that the method suits problems where "analytical techniques are not able to provide relevant results or when there is uncertainty in the input data", which is exactly a project risk register.

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:

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).
Percentile outputs. "80% of simulated outcomes fall at or below $X" is a defensible claim you can show the working for; "carry 15% because we always do" isn't.
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.
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:

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.
For triggered risks, draw a sample from their impact distribution (triangular, PERT, or fixed — see probability distributions in PRQ).
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 — PRQ's starting point

80% of simulated outcomes land at or below this value. PRQ funds at P80 unless you choose otherwise, and the percentile chooser above the results lets you move it to P50, P75, P90 or P95 without re-running anything. Note what the sentence does and does not say: it is a statement about the simulation, not a forecast. It carries every assumption the register was built on, and says nothing about risks nobody identified.

Which percentile should you actually use?

There is no universal answer, and guidance genuinely differs. Australian public infrastructure works in P50 and P90 rather than P80. Infrastructure Australia states that cost estimates are "primarily presented as at P50, P90 and/or expected value", and the Infrastructure NSW Cost Control Framework requires contingency "provisioned at P90 for Tier 1 HPHR projects and P50 for Tier 2 projects". Queensland Transport and Main Roads requires P90 status for QTRIP projects.

The UK Green Book treats a P90 as a way of expressing uncertainty around a central estimate rather than a funding rule, and the example it works through is a reference-class exercise rather than a simulation: rank comparable projects by cost and take the ninetieth percentile of that list (2026 edition, paragraph 6.72). It separately requires an explicit adjustment for optimism bias (paragraph 2.25). Neither is a mandated percentile. AACE International's Recommended Practice 41R-08 does not prescribe a level either: it observes that "the more conservative, risk-averse attitude used by many profit-making companies, is to specify a probability of 80% or higher", then warns that doing so inflates cost and "results in a maldistribution of funds".

So P80 is a defensible starting point, not a standard. Choosing the level is a risk appetite decision, and appetite sits with the board rather than the analyst. The Institute of Operational Risk puts it plainly: "Business managers do not, normally, get involved with determining an organisation's appetite for operational risk, given that this is part of a Board's governance responsibilities." Check what your own framework requires before adopting ours.

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. Note that it is the tail specifically, not the total. The mean is unaffected by dependence, and the median can move either way.

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.

Do not add percentiles together

The most expensive mistake available with these numbers is aggregating them by hand. If you run five projects separately and add their P80s to get a programme P80, the answer is wrong, and it is usually wrong in the direction that leaves you short. Percentiles are not additive.

The standard says so directly, at the clause on aggregating risk:

If correlation is not taken into account appropriately the outcomes will be inaccurate and may be grossly misleading. Consolidating risks by simply adding them up is not a reliable basis for decision making and could lead to undesired results. Monte Carlo simulation can be used to combine distributions.

The intuition people reach for, that adding up must be conservative because the projects are unlikely to all have a bad day at once, is true sometimes and is not a rule. Five independent projects each carrying a low-probability tail risk can produce a portfolio P80 several times the sum of the individual P80s, because across five projects it is no longer unlikely that one of the tails fires. A portfolio number has to be simulated at portfolio level. Worked through, with the simulation, on the blog.

The same clause adds a second constraint worth remembering when a register mixes methods: "Qualitative or semi-quantitative measures of risk cannot be directly aggregated." You cannot total a column of matrix ratings.

Strengths and limitations

Strengths, from B.5.10.5: the method "can, in principle, accommodate any distribution in an input variable, including empirical data derived from observations of related systems"; models "are relatively simple to develop and can be extended as the need arises"; "any influences or relationships can be represented, including effects such as conditional dependencies"; and sensitivity analysis can be applied to identify which inputs matter.

Limitations are mostly limitations of the register rather than of the arithmetic, and they are the ones to say out loud when presenting a result:

The output describes the model, not the project. It excludes anything not in the register, which always includes some things.
Accuracy depends entirely on the input distributions. A precise-looking P90 built on ranges somebody guessed in a workshop is precise about a guess.
Large iteration counts produce narrow convergence intervals, which can read as confidence the model has not earned. Convergence is a statement about arithmetic stability only.

What the engine doesn't do

Three deliberate limits worth knowing:

Seeding is opt-in. PRQ's Seed field pins the random source so a run can be reproduced exactly (our own published figures are seeded runs). Leave it blank and the engine draws fresh randomness each time, so re-running produces slightly different P50 / P80 / P90 values within the convergence band. For an audit trail, record the seed and iteration count alongside the exported result.
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.