QSRA (Quantitative Schedule Risk Analysis)

Quantitative Schedule Risk Analysis (QSRA) applies Monte Carlo simulation to a project schedule to produce a range of possible completion dates with associated probabilities. The typical output is an S-curve showing the likelihood of completion on or before any given date, with specific reference points at P50 (median, the date the project has a 50% probability of finishing by), P80 (80% probability) and P95 (95% probability). Rather than asking "when will this project finish?", QSRA asks "with what confidence can we say it will finish by date X?" — a fundamentally more honest question on programmes with material uncertainty.

The difference between QSRA and a generic Schedule Risk Analysis (SRA) is the word quantitative. An SRA might be a qualitative review of risks against the schedule, or a deterministic what-if analysis of a few scenarios. QSRA is specifically the Monte Carlo simulation — typically tens of thousands of iterations across the network — that produces a true probability distribution. In UK practice, when buyers ask for an SRA on an infrastructure or defence programme they almost always mean a QSRA; the terms are used interchangeably in everyday usage but the formal AACE definition reserves "QSRA" for the Monte Carlo method.

A QSRA requires three inputs that a deterministic schedule does not. First, three-point estimates on activity durations: a minimum, most-likely, and maximum duration for each activity, capturing the inherent uncertainty in how long that work will actually take. The shape of the distribution between those three points matters — triangular, beta-pert, and lognormal are the common choices, each with different tail behaviour. Second, discrete risk events mapped from the project risk register to the activities they would impact if they occur, with their own probability and impact distributions. Third, correlation structure between activities that do not move independently — a labour shortage affects multiple activities simultaneously, a regulatory delay affects every downstream approval — and these correlations have to be specified explicitly because the default of zero correlation almost always understates the spread.

The model output is the S-curve plus a tornado chart showing which activities and risks drive the variance. The S-curve tells the sponsor the confidence position; the tornado tells the project manager where to focus mitigation. A QSRA without an interpretable tornado chart is delivering only half its value — sponsors want a number, but the project team needs to know which inputs they can act on.

On UK programmes the leading QSRA tools are Safran Risk (purpose-built for QSRA, integrates natively with Primavera P6, dominant on rail and nuclear), Primavera Risk Analysis (formerly Pertmaster, still in widespread use but on Oracle extended support — security fixes only, no new features), Acumen Risk by Deltek (handles integrated cost-schedule QCSRA in the same workbench), and @Risk by Palisade (Excel-based, more common in cost-led QCRA contexts but used for QSRA on smaller schedules). The choice of tool is far less important than the calibration of the inputs and the discipline of the methodology — a well-run @Risk model produces better results than a poorly-run Safran model. The AACE Recommended Practices that codify QSRA methodology are RP 57R-09 (Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model), RP 113R-20 (Integrated Cost and Schedule Risk Analysis and Contingency Determination Using Combined Parametric and Expected Value), and RP 123R-22 (Determining Project Cost and Schedule Contingencies Using Expected Value and Statistical Methods).

Where QSRA is most valuable is at gateway decisions — project sanction, funding approval, major baseline re-set — where the sponsor needs a defensible view of confidence rather than a single optimistic headline. UK infrastructure and major programmes typically require QSRA aligned to HM Treasury Green Book standards (paragraphs 6.72-6.84) and IPA Cost Estimating Guidance, particularly at OBC and FBC business cases. On NEC4 contracts, the Accepted Programme requirements under Clauses 31 and 32 — explicit Time Risk Allowances against a planned completion that sits inside the contractual completion date — make quantitative schedule thinking effectively contractual on any non-trivial NEC4 programme.

A worked example clarifies the mechanics. Take a £200m rail station rebuild on a 30-month programme. The deterministic critical path runs through deck-construction (18 months), platform-finishes (5 months), then signalling-commissioning (4 months) with three months of float to the contractual completion. The QSRA inputs: three-point durations on each activity (e.g. deck-construction 16/18/22 months reflecting weather, possession-access and existing-services discovery uncertainty); discrete risks including a 30% probability of an unforeseen contaminated-ground event adding 2-4 months, a 20% probability of signalling-system integration issues adding 3-6 months, a 15% probability of a possession-curfew change costing 1-2 months; correlation between deck-construction durations and platform-finishes (shared weather exposure, same supply chain). Running 50,000 Monte Carlo iterations produces an S-curve with P50 = month 31, P80 = month 33.5, P95 = month 35. The deterministic 30-month plan has a 35% probability of being met. The contractual completion at month 33 has a 70% probability. The contractor needs to defend a P80 finish, which means accepting a 3.5-month sensitivity beyond the deterministic plan.

Common QSRA failures cluster around three problems. First, three-point estimates that come out of the workshop without calibration — practitioners guess at minimums and maximums without reference to comparable benchmark data, and the resulting spread is either implausibly tight or arbitrarily wide. Second, correlation that is set to zero across the board for convenience; this almost always understates the spread because real projects bunch risks around common causes. Third, the discrete risk register being copy-pasted from a template rather than built from delivery experience on this specific programme — generic risks produce generic results that the experienced reader recognises immediately. A defensible QSRA addresses all three: calibrated three-point estimates against benchmark data, explicit correlation structure based on the actual programme, and a risk register built from the specific delivery context.

QSRA done well becomes a governance tool that persists through delivery. The model is re-run at each major milestone or compensation event, the inputs are updated as the risk register evolves, and the confidence position is reported in steering-group packs alongside CPI/SPI metrics. QSRA done badly becomes a one-off document produced for a gateway, ages out within a quarter, and is forgotten by the project team. The difference is the maintenance discipline — and a project controls function that owns the QSRA as a live tool rather than a deliverable. SOMA delivers QSRA to AACE International recommended practices, structured to satisfy IPA and client-side assurance scrutiny and designed to remain useful through delivery rather than ending at gateway approval.