The short answer
QSRA — Quantitative Schedule Risk Analysis — answers the question: given the risks and uncertainties on this programme, what is the realistic range of completion dates, and what is the probability of hitting any given date?
QCRA — Quantitative Cost Risk Analysis — answers the equivalent question for money: given the same risks, what is the realistic range of final costs, and what contingency is defensible at a given confidence level?
Both are Monte Carlo simulations. Both draw on the same risk register and three-point estimates. Both produce S-curves and tornado charts. The difference is what they are modelling: schedule duration and float in the QSRA; budget lines and cost packages in the QCRA. Running both together — an integrated QCSRA — lets you see the cost consequence of schedule risk directly, rather than inferring it.
How a QSRA works
A Quantitative Schedule Risk Analysis starts with a logic-linked schedule — typically built in Primavera P6, Asta Powerproject, or Microsoft Project. The schedule must have proper relationships between activities, realistic durations, and minimal artificial constraints. A schedule with hundreds of mandatory dates baked in will not respond meaningfully to risk-driven delays, because the constraints prevent the model from propagating the uncertainty through the network.
Each activity duration is then given a three-point estimate — optimistic, most likely, and pessimistic — usually using a triangular or PERT distribution. On top of this, discrete risk events from the risk register are applied: risks that might delay specific activities or chains of activities, each with a probability of occurring and an impact range.
The Monte Carlo engine runs the schedule thousands of times, each time sampling random values from the input distributions. On some iterations, the groundworks go well and finish early. On others, poor ground conditions extend them by six weeks. The engine aggregates those thousands of outcomes to produce a distribution of completion dates — which is your S-curve.
The QSRA output tells you the P50 completion date (the median outcome — you have a 50% chance of finishing by this date) and the P80 (an 80% confidence target, typically what gets submitted to clients and funders). The tornado chart shows which activities and risks are driving the most variability in the completion date — the ones where mitigation effort is most likely to bring the P80 date in.
A good QSRA also surfaces merge bias: the systematic optimism built into network logic when multiple converging paths exist. Even if each individual path looks achievable, the project must complete all of them — and the probability of all paths finishing on time simultaneously is far lower than the probability of any one of them finishing on time. Deterministic schedules routinely underestimate the completion date as a result. A QSRA corrects for this.
How a QCRA works
A Quantitative Cost Risk Analysis starts with a cost estimate — usually structured by Work Breakdown Structure, with costs broken into base estimate lines and, separately, risk provisions. The base estimate should be the best deterministic forecast of what the project costs if things go broadly to plan. Any contingency already embedded in line items needs to be stripped out before the model runs, because the QCRA is what generates the contingency — double-counting produces inflated confidence levels.
Three-point estimates are applied to each cost line: the optimistic and pessimistic values around the base reflect estimating uncertainty — how well you can actually pin down the cost of that package at this stage of the project. This is separate from discrete risks: a ground-condition risk that might add £2m to civils if triggered is a different beast from the ±15% estimating uncertainty on the structural steelwork package.
Risk events from the register are applied as discrete inputs: each has a probability of occurring and a cost impact range. A QCRA model that only models risks and ignores base estimate uncertainty will underestimate the spread of outcomes. Both layers — base uncertainty and discrete risks — need to be in the model for the S-curve to be credible.
Correlation matters significantly in cost models. If two work packages share the same subcontractor, the same ground conditions, or the same design risk, they are not independent. If ground conditions are poor, both the civils and the drainage packages suffer. Ignoring correlation produces a model that artificially dampens the spread of the S-curve, because it assumes lucky outcomes on one package are offset by unlucky ones on another. In practice, risks cluster. A credible QCRA builds in correlation explicitly.
The output is a cost S-curve: P50, P80, and P95 cost figures, with the tornado chart showing which estimate lines and risks are driving the spread. The P80 is typically what gets approved as the funding ceiling on UK public sector programmes — it is the figure required by HM Treasury Green Book guidance for major projects, and the figure MoD CADMID Main Gate Boards expect to see at Concept-to-Assessment and Assessment-to-Demonstration transitions.
The relationship between the two
Schedule risk and cost risk are not independent. A programme that runs four months late also incurs four months of site overheads, four months of extended preliminaries, four additional months of inflation exposure, and potentially liquidated damages. The cost consequence of schedule risk is often the largest single driver of cost overrun on major programmes.
An integrated QCSRA models this relationship explicitly: schedule delays drive cost overruns in the model, rather than being calculated separately and added afterwards. This is technically more demanding — you need a schedule that is resource-loaded with time-dependent costs — but it produces a more honest picture. The P80 cost figure from an integrated model is invariably higher than one from a standalone QCRA that ignores schedule risk, because the integrated model captures the compounding effect.
On smaller projects, or where time and budget are limited, it is common to run one analysis rather than both. The choice depends on what the decision-maker needs. If the primary question is "will we finish on time?" — a milestone-driven contract, a handback obligation, a regulatory deadline — QSRA is the priority. If the primary question is "how much contingency do we need to hold?" — a funding submission, a board sanction request, a contract negotiation — QCRA is the priority.
When both questions matter, and when the programme is complex enough that schedule risk is a material driver of cost risk, the integrated QCSRA is the right answer. It takes more resource to build and run, but it avoids the false comfort of a cost model that does not account for the thing most likely to blow the budget.
When you need each
Run a QSRA when: you are approaching a major programme milestone and need a defensible confidence level on the date; when your client or funder requires a P80 date; when the schedule is network-complex with multiple converging paths; when you suspect merge bias is making the headline programme more optimistic than it looks; or when you want to identify which activities and risks are most likely to drive a delay.
Run a QCRA when: you are preparing a funding submission and need a defensible cost confidence level; when the contract requires risk-quantified contingency; when the base estimate is at an early stage (Class 3 or above) and estimating uncertainty is high; or when a board or sponsor needs to understand what contingency they are approving at a given confidence level.
Run both — integrated — when: the programme is large enough that schedule delay is a material driver of cost; when you have a mature, logic-linked, resource-loaded schedule that can serve as the model backbone; when the decision-maker needs to understand both schedule confidence and cost confidence together; or when a gateway review, Treasury approval, or independent review requires it.
A note on tools: the choice of software is less important than the quality of the inputs. @Risk for Excel handles QCRA well and is widely used for cost-only models. Primavera Risk Analysis (Pertmaster) and Safran Risk are the leading tools for integrated schedule-cost risk analysis. Acumen Risk and ARM are also used on UK programmes. The underlying Monte Carlo methodology is the same across all of them; the differences lie in workflow integration with the schedule and in how correlation is specified.
If you are commissioning a QRA from a consultant, ask specifically whether the model includes base estimate uncertainty as well as discrete risk events, and whether correlation has been modelled. These two questions will tell you quickly whether you are dealing with someone who understands the craft.