Why separate QRAs miss the point
Most UK project controls functions run cost QRA and schedule QRA as separate exercises. A cost team builds a probabilistic model of the outturn cost, producing an S-curve and a P80 figure. A schedule team builds a probabilistic model of the completion date, producing another S-curve and a P80 duration. The two outputs are reported to the steering group side by side and treated as independent views of project exposure. This is analytically incorrect and, on programmes of any real complexity, materially understates the true risk.
The reason is structural. Schedule delays drive costs. A six-month delay on a major construction programme typically incurs prolongation costs of 10-20% of the planned overrun duration in time-related costs — preliminaries, site staff, plant hire, finance charges, client-side supervision. If those time-related costs are not modelled as functions of the schedule outcome, the cost QRA is ignoring one of the largest drivers of cost exposure. Conversely, cost pressures drive schedule decisions — a contractor running over budget will defer non-critical activities, release resources, or challenge scope, all of which have schedule consequences. Treating the two as independent loses both effects.
The technique that addresses this is called integrated cost-schedule risk analysis — QCSRA, or integrated cost-schedule Monte Carlo. It is the standard approach recommended in AACE International Recommended Practice 57R-09, Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model. The name is unwieldy; the idea is straightforward. Build a single simulation in which the schedule and the cost model are linked, and run the Monte Carlo across both simultaneously so that each iteration produces a consistent pair of outcomes — a specific completion date and a specific outturn cost, reflecting the same sequence of risk events.
QCSRA is not universally applicable. On small, short-duration projects, the additional modelling effort outweighs the insight. On programmes with stable scope, limited time-related cost exposure, and well-understood risks, separate cost and schedule models are acceptable. The case for QCSRA strengthens as projects get larger, longer, more uncertain, and more exposed to time-related costs. On any major infrastructure programme — transport, utilities, defence (typically anything moving from CADMID Assessment into Demonstration on the MoD lifecycle) — the argument for running an integrated analysis is strong enough that clients should be asking for it by default.
What QCSRA actually does that separate analyses do not
The technical heart of QCSRA is a single Monte Carlo engine that samples from a shared set of risk events and uncertainty distributions, applying the outcomes to both a cost model and a schedule model in the same iteration. This produces three things that separate analyses cannot produce. First, a joint probability distribution of cost and schedule outcomes — you can see, for any given completion date, what the probable range of costs is, and vice versa. Second, a direct measure of time-dependent costs flowing from schedule outcomes. Third, a consistent set of risk scenarios that is the same for both outputs — when the ground conditions risk occurs, it occurs in both the cost model and the schedule model simultaneously.
The joint distribution is more than a presentational advantage. It supports real decision questions that separate S-curves cannot answer. "If we want 80% confidence on the completion date, what contingency do we need?" is not answerable from a cost P80 figure, because the cost P80 is the 80th percentile of cost across all schedule outcomes combined. The P80 cost associated with a P80 completion date is typically materially higher than the reported cost P80, because the P80 cost figure is dragged down by the faster scenarios. QCSRA produces both figures and tells you which combinations are plausible.
Time-dependent costs are the second major contribution. In a QCSRA model, time-related cost elements — preliminaries, staff, plant, finance — are calculated as a function of the simulated project duration, not as a static cost line. If the schedule iteration produces a 14-month completion, the preliminaries line reflects 14 months. If it produces an 18-month completion, the preliminaries line reflects 18 months. The cost curve shifts accordingly. This is particularly important on projects with high time-related cost content — tunnelling, offshore installation, large process industry work — where the preliminaries component can be 25-40% of total outturn.
The shared risk scenarios are the third contribution. In separate analyses, a risk that affects both cost and schedule is modelled twice, with independent probability draws. In reality, if the risk occurs, it occurs for both. Integrated modelling enforces consistency. If the "delayed regulatory approval" risk is sampled as occurring in a given iteration, the schedule feels the delay and the cost feels the associated rework and prolongation in the same iteration. Across thousands of iterations, this produces a correctly correlated view of joint exposure.
How it works mechanically
A QCSRA model has four components. First, a CPM schedule with cost-loaded activities — typically a live Primavera P6 or Microsoft Project file that has been simplified or summarised to the level of detail appropriate for risk modelling. Second, a risk register with probability, impact on cost, impact on schedule, and assigned-to relationships identifying which activities each risk affects. Third, uncertainty distributions applied to activity durations and cost rates, usually as three-point estimates with a triangular or PERT distribution. Fourth, a simulation engine that samples all of the above thousands of times.
The simulation mechanics are straightforward. For each iteration, the engine samples every risk (does it occur or not, given its probability?), every duration uncertainty (what is the sampled duration for this activity?), and every cost uncertainty (what is the sampled rate or quantity?). It then runs CPM on the resulting schedule to produce a completion date, and calculates total cost including time-dependent elements based on the resulting duration. Each iteration yields a consistent (duration, cost) pair. After 5,000 to 10,000 iterations, the engine produces the joint distribution and the marginal distributions on each axis.
The tools that handle this properly are relatively few. Safran Risk is widely used in UK infrastructure and defence — it is designed around integrated cost-schedule risk and handles time-dependent costs natively. Acumen Risk (now part of Deltek) is the other major tool in this space and is common on US programmes exported to the UK. @Risk, run as an add-in to Primavera or Microsoft Project, can do integrated analysis but requires more manual setup. Oracle Primavera Risk Analysis (PRA, formerly Pertmaster) handles schedule risk well but has more limited cost integration. The choice of tool usually depends on what the organisation already has and what the risk analyst knows rather than any intrinsic superiority.
The modelling effort for a QCSRA is substantial. On a typical major infrastructure programme, an initial QCSRA build can take six to eight weeks of a competent analyst's time, with additional time for workshop elicitation, calibration, and stakeholder review. Subsequent updates — typically quarterly — are faster once the model is established, but the build is not trivial. This cost is one of the main reasons QCSRA is less common than separate cost and schedule QRA, and it is also one of the main reasons the separate approach persists on projects where the integrated approach would be more informative.
Risk drivers versus risk events — and why it matters
AACE 57R-09 advocates a specific modelling technique called risk drivers, which differs from the traditional risk event approach used in most risk registers. A risk event is a discrete occurrence — "delayed permit approval" — that either happens or does not happen, with an associated cost and schedule impact. A risk driver is a continuous factor — "permit approval duration" — that has a distribution of possible outcomes and affects multiple activities in a coordinated way.
The risk driver approach produces better results on most programmes because it captures the correlation structure of risks more realistically. If permit approval takes longer than expected, it does not just delay one activity; it delays every activity that depends on that approval, and the delays are correlated by the common cause. Modelling this as a risk event with separate impacts on each affected activity loses the correlation. Modelling it as a risk driver that applies a consistent multiplier to all affected activities in each iteration preserves the correlation.
In practical terms, a QCSRA using risk drivers starts with a relatively small set of risk drivers — typically 15 to 40 — each mapped to the activities it affects and each with a probability distribution for its impact on cost and schedule. This is often more defensible and more informative than a traditional risk register with 200 discrete events, because the risk drivers correspond to recognisable underlying causes rather than to specific consequences.
The transition from a risk-event register to a risk-driver model is not trivial. It requires rethinking the risk register structure and often produces pushback from teams who have invested in the event-based approach. The case for making the transition is strongest on long, complex programmes where the traditional risk register has grown unwieldy and where the structural limitations of independent event sampling are producing implausibly narrow output ranges. Not every project benefits from the change, but for the projects that do, the improvement in model credibility is significant.
Common mistakes on integrated analyses
The most common mistake is building an integrated model that is technically integrated but practically treats cost and schedule as independent. If the time-dependent cost rates are static inputs rather than functions of the simulated duration, the model is producing integrated outputs but not capturing the integrated risk. Check that the preliminaries, site establishment, and staff cost elements in the model respond to schedule outcomes. If they do not, the model is functionally two separate analyses wearing integrated clothes.
The second common mistake is inconsistent treatment of risk correlations across the cost and schedule domains. In a well-built QCSRA, a risk that delays an activity by X weeks also drives an associated cost impact — prolongation costs on that activity, knock-on cost impacts on subsequent activities, possibly rework costs. In a poorly built one, the schedule impact and the cost impact of the same risk are defined independently, and the simulation samples them as if they were unrelated. This produces a model that technically simulates both cost and schedule but does not capture the relationship between them.
The third mistake is applying the risk-driver approach to a risk register that is not ready for it. A risk driver is meaningful only if the analyst has genuine understanding of the underlying cause and its relationship to project activities. If a risk is translated into driver form without that understanding — for example, renaming "regulatory delay risk" into "regulatory approval duration" without actually re-thinking which activities are affected — the model produces outputs that look sophisticated but rest on the same shallow inputs as before.
The fourth mistake is ignoring schedule logic in the cost model. Many cost QRAs are built in Excel with @Risk or similar tools, and the schedule context is represented as a single duration input. This loses the merge bias effects, the path sensitivity, and the sequence dependencies that a CPM-based integrated model captures. Running cost risk analysis without an explicit schedule logic underneath it produces a cost S-curve that is narrower than reality because it does not see the schedule variability correctly.
Briefing a client on the integrated result
The output from a QCSRA is a joint probability distribution, and boards are not comfortable reading joint distributions. The practical approach is to report three things: the marginal cost S-curve, the marginal schedule S-curve, and the joint distribution summary that shows the cost outcome associated with each schedule percentile. The joint summary is the distinctive QCSRA output and the one that typically changes the conversation.
The joint summary is most commonly presented as a table: P50 completion date with its P80 cost, P80 completion date with its P80 cost, P95 completion date with its P80 cost. This tells the client that if they want 80% confidence on the completion date (the P80 date), the associated cost is higher than if they only wanted 50% confidence, because the longer simulated durations carry more prolongation cost. The spread between these figures is often 10-20% of total cost, which is material for board-level funding decisions.
The recommendation to the client typically follows one of three patterns. If the organisation wants to manage to a schedule target (common on infrastructure programmes with external milestones), recommend contingency sized to the cost at the target schedule percentile. If the organisation wants to manage to a cost ceiling (common on fixed-budget programmes), recommend contingency sized to the cost percentile and accept the associated schedule risk. If the organisation is setting both a cost and a schedule target, be explicit that the joint probability of achieving both may be substantially lower than either individually — a project that has P80 on cost and P80 on schedule typically has P60 or lower on meeting both.
The briefing should also be explicit about the modelling assumptions. State the risk drivers used, the correlation structure applied, the time-dependent cost rates assumed, and the iteration count. A board reading a QCSRA output that does not include these facts is being asked to trust a number without context. A board reading the same output with full documentation of assumptions can reason about which assumptions might be wrong and what the sensitivity to those assumptions is. The second version is defensible governance; the first is not.
The final point is to calibrate the recommendation to the organisation's risk appetite. HM Treasury Green Book guidance uses P80 as the default confidence level for funding decisions on public-sector programmes. Private-sector clients may prefer P50 for central estimates and P90 for funding ceilings. Infrastructure owners with multi-project portfolios often accept lower per-project confidence in exchange for central portfolio contingency. There is no universal answer, and the QCSRA output supports multiple framings. The controls lead's job is to present the integrated result clearly and let the client make the decision with full sight of the joint exposure.