What QRA actually is (and isn't)
Quantitative Risk Analysis — QRA — is the process of putting numbers on uncertainty. Not traffic-light numbers. Not "high / medium / low" numbers. Actual probability distributions showing the range of plausible cost or schedule outcomes and the likelihood of achieving each one.
The output of a QRA is not a single figure. It is a curve — an S-curve — showing, for example, that a programme has a 50% chance of completing within £120m, a 70% chance of completing within £135m, and a 90% chance of completing within £158m. That spread is the point. The spread tells you what decisions are actually available to you.
QRA is not the same as a risk register, though it draws on one. A risk register lists risks and gives them qualitative or semi-quantitative scores. QRA takes those risks — and crucially, the underlying uncertainty in your estimates — and models how they interact to produce a range of outcomes. The two tools are complementary, not interchangeable.
QRA is also not a guarantee. A P80 cost figure does not mean "the project will cost that much." It means that, given the risks and uncertainties modelled, there is an 80% probability that the final cost will be at or below that figure. Whether the model is a faithful representation of reality depends entirely on the quality of the inputs. Garbage in, garbage out is a cliché precisely because it is true.
When you need one
Not every project needs a full QRA. A small, well-defined internal project with a fixed-price contract and limited scope variability probably does not. The overhead of building and running a meaningful model would outweigh the insight it produces.
You need a QRA when decisions are being made that depend on a defensible confidence range. The most common triggers are: setting a contingency or risk provision for a funding submission; advising a board or client on the difference between a P50 and P80 cost or date; satisfying a gateway review requirement (HM Treasury Green Book guidance requires quantified risk assessment for major public-sector projects, and the UK MoD CADMID lifecycle places explicit QRA expectations at Concept and Assessment phases); or understanding which risks are actually driving variability on a complex programme.
On UK infrastructure and construction programmes, quantitative schedule thinking is effectively contractual under NEC4 ECC Clauses 31 and 32 — the Accepted Programme has to show time risk allowances and float, which is the closest the standard form comes to mandating QRA. Beyond that, QRA adoption on major UK programmes is driven by HM Treasury Green Book expectations for risk and optimism-bias adjustment on high-cost / high-risk proposals, by IPA Cost Estimating Guidance which requires the P50 central estimate at every stage gate, and by sector-specific assurance practice on rail, highways, nuclear and defence programmes. Even where it is not strictly required, a well-run QRA is one of the most useful things you can do at RIBA Stage 2 or 3, when the project is still shapeable and the cost and schedule uncertainty is at its highest.
AACE International's guidance (specifically the Total Cost Management Framework, the Professional Guidance Document PGD-02 Guide to Quantitative Risk Analysis, and Recommended Practices 57R-09, 113R-20 and 123R-22 on integrated cost-schedule risk analysis) and the APM's Body of Knowledge both treat QRA as a core competence for projects above a meaningful scale. The decision threshold is not a hard number — it is whether the technical and schedule uncertainty on the programme is material enough that a single deterministic estimate would mislead the decision-maker. On most UK infrastructure and defence programmes above a few million pounds with genuine scope or interface complexity, the answer is yes.
What goes into a good QRA
A QRA model has three main inputs: the base estimate, the schedule, and the risk register. Each needs to be in reasonable shape before you start — a QRA cannot rescue a fundamentally flawed estimate or a schedule that has never been properly resourced. It can, however, reveal the fragility of both.
The base estimate should be your best deterministic forecast — what you expect to spend if things go broadly to plan. It should not include contingency, because the QRA is what generates the contingency. Cost engineers sometimes bake contingency into line items "just in case," which means the QRA model double-counts risk and produces inflated confidence levels. Strip the buried contingency out before you run the model.
The schedule needs to be logic-linked, resource-loaded where possible, and free of artificial constraints. A schedule with hundreds of hard constraints — dates imposed by the tool rather than by genuine dependencies — will not respond realistically to risk-driven delays. You are modelling what actually drives the project, not what makes the programme look tidy on a bar chart.
The risk register needs three-point estimates: optimistic, most likely, and pessimistic values for both cost and schedule impact, plus a probability of occurrence. This is where most QRAs fall down. Teams either use the same three-point range for every risk (because they do not know the answers) or they produce ranges so narrow that the model adds almost no variability. Getting credible three-point estimates requires workshops, challenge, and someone in the room who has done a similar project before. It is time-consuming. It is also the entire point.
Good QRA models also capture inherent estimating uncertainty — not just discrete risks, but the base variability in your cost estimates and durations. A concrete pour that is estimated at 20 weeks does not have a 100% chance of taking exactly 20 weeks. Applying uncertainty ranges to base estimate line items, separate from the risk register, is standard practice in cost risk analysis and is recommended by both AACE and HM Treasury Green Book guidance.
The modelling process (Monte Carlo explained plainly)
The engine inside almost every QRA tool is Monte Carlo simulation. It sounds technical. The concept is not.
The model takes every uncertain input — each cost line with its three-point range, each risk with its probability and impact range, each duration with its variability — and runs the project thousands of times, each time picking a random value for each input consistent with its probability distribution. Run it 10,000 times and you get 10,000 possible project outcomes. Plot those outcomes and you get a distribution. That distribution is your S-curve.
In practice, the software handles the iteration. Analysts use tools like Safran Risk, Oracle Primavera Risk Analysis (formerly Pertmaster), @Risk for Excel, or Acumen Risk. Each has strengths: Safran and Primavera Risk Analysis work directly with schedule logic and handle integrated cost-schedule risk well; @Risk is more flexible for cost-only models built in Excel. The choice of tool matters less than the quality of the inputs.
One thing Monte Carlo does not do automatically is handle correlation. If the civils package is late, the mechanical and electrical package is also likely to be late — they share the same ground conditions, the same weather risk, the same key subcontractor. Ignoring correlation between risks and activities produces a model that underestimates overall variability, because it assumes the unlucky scenarios on one activity are balanced by lucky scenarios on another. Building in realistic correlation coefficients is one mark of a well-constructed model.
The number of iterations matters less than people think. For most project models, 5,000 to 10,000 iterations is sufficient. Running 100,000 iterations does not make the model more accurate — it makes it take longer. The accuracy is in the inputs, not the iteration count.
Reading the outputs: S-curves, tornado charts, and confidence levels
The S-curve is the primary output. The horizontal axis shows cost (or completion date); the vertical axis shows cumulative probability. The point where the curve crosses 50% on the vertical axis is the P50 — the median outcome. The P80 is where it crosses 80%. The shape of the curve tells you as much as the numbers: a shallow, spread-out S-curve means high uncertainty; a steep, narrow one means the model has relatively tight constraints on the outcome.
On cost models, you will typically see a deterministic estimate marked on the S-curve. If the deterministic estimate sits above the P80, that is a signal — your base estimate may already be optimistic, or the risks are substantial. If it sits near the P50, you have roughly symmetric uncertainty. If it is above the P90, you should be asking serious questions about the estimate basis.
Tornado charts show which risks and uncertainties are driving the most variability in the outcome. They rank inputs by their contribution to the spread of results — the longer the bar, the more impact that item has. Tornado charts are where QRA becomes genuinely useful for project management, because they tell you where to focus. If three risks account for 60% of the variance, those are the three you need to be actively managing, monitoring, and reporting on.
Sensitivity analysis — related to but distinct from tornado charts — shows how the P80 (or whatever confidence level you care about) changes as individual inputs change. It answers the question: if we could eliminate that risk entirely, how much would it change our cost confidence? This is useful for prioritising mitigation investment.
Confidence levels are the other key output. P50, P80, and P95 are the most commonly reported. HM Treasury guidance uses P80 as the basis for Optimism Bias and contingency calculations for major public-sector projects. Commercial clients often want to see P50 as a central estimate and P80 as a "should-cost" funding ceiling. There is no universal rule for which confidence level to use — it depends on the organisation's risk appetite, the project's strategic importance, and the consequences of underfunding.
Common mistakes we see on real programmes
The most common mistake is running the QRA once, at a single point in time, for a gateway submission, and then never looking at it again. QRA is most valuable as a live tool — updated as risks mature, new risks emerge, and the estimate evolves. A static QRA produced at RIBA Stage 2 and never revisited is of limited use by the time the project reaches Stage 4.
The second most common mistake is allowing the QRA to be run by someone who has a stake in the outcome. If the delivery team are also running the risk model, there is an incentive — conscious or not — to narrow the ranges, reduce the probabilities, and produce a P80 that comes in under budget. Independent peer review of QRA assumptions, or independent QRA modelling, is standard practice on major programmes for precisely this reason.
Poorly calibrated three-point estimates are endemic. Most people, when asked for a "pessimistic" estimate, give a figure that is perhaps 20-30% above their most likely — when genuine project experience suggests that tail risks can be two or three times the base estimate on complex packages. P-value miscalibration is a known cognitive bias and a well-documented problem in project risk. Some organisations address this through structured elicitation techniques or by anchoring estimates to historical data on similar projects.
Treating risks and estimating uncertainty as separate things is another structural problem. Cost risk analysis should model both: the inherent variability in how well you can estimate a scope item, and the discrete risk events that might change the scope itself. Conflating the two — or modelling only one — will misrepresent the true uncertainty.
Finally, burying contingency in the base estimate before running the model is particularly destructive because it is invisible. If a cost manager has padded each line item with 10% "just in case," the QRA model produces a P50 that is already 10% above the genuine expected cost. The contingency appears to come from the model when it was actually in the estimate all along. Always audit the base estimate for embedded contingency before running QRA.
When to push back on a bad QRA
If someone hands you a QRA report, you should scrutinise it — especially if it is being used to justify a funding level or a go/no-go decision. Here are the things worth checking.
Does the S-curve look plausible? A P80-to-P50 ratio of less than 10% on a complex project is a red flag. Real projects have more uncertainty than that. If the spread is very narrow, ask what assumptions produced it — you will usually find either narrow three-point ranges, very low risk probabilities, or embedded contingency in the base estimate.
Are the top risks in the tornado chart actually the risks you would expect to drive variability? If ground conditions are a known uncertainty and they do not appear in the top ten, ask why. If the biggest driver is something trivial, the modeller may have missed the substantive risks.
Has the model been run by someone independent of the delivery team? If not, ask whether assumptions have been peer-reviewed.
Does the model include correlation? Most credible QRA tools support correlation. If a large model has been run without any correlation between related risks and activities, the spread of the S-curve will be artificially compressed.
Is the QRA date consistent with the current project state? A QRA based on a schedule that was superseded six months ago is not telling you about the project you are on now. Check the model date and the schedule revision it references.
A well-done QRA from a competent analyst who understands the project and has credible input data is one of the most valuable tools in project controls. A poorly-done QRA that produces a comfortable-looking number to pass a gateway is actively harmful — it gives false confidence to decision-makers who deserve honest information. If you are not sure which kind you are looking at, the questions above will usually tell you.