Monte Carlo QCRA in Depth: How to Build, Run and Read a Quantitative Cost Risk Model

Monte Carlo simulation turns estimates, uncertainties and risk events into a range of possible project costs. Its value depends less on the number of simulation runs than on whether the underlying model represents the project honestly: the estimate structure, risk register, assumptions and dependencies must all stand up to scrutiny.

I have managed Quantitative Cost Risk Analysis (QCRA) governance alongside Quantitative Schedule Risk Analysis (QSRA) oversight on a major defence infrastructure programme, chairing monthly risk reviews. That work reinforced a practical principle: the model is a decision tool, not a substitute for sound estimating, planning or risk ownership. This article is the first method deep dive in our series, following the overview of how to calculate construction project risk costs using Monte Carlo, PERT and review frequency. For the relationship between cost and schedule analysis, see QCRA vs QSRA: which analysis should you run first?.

1. Define what the model must answer

Before choosing distributions or running simulations, establish the decision. Is the analysis intended to test affordability, set contingency at an agreed confidence level, compare options, or assess the chance of exceeding a cost limit?

Then define the cost boundary and base estimate. Make clear whether escalation, known risks, design development, fees and other allowances are already included. An unclear boundary creates double counting and makes the resulting contingency difficult to interpret.

A useful model structure follows the project’s cost breakdown structure (CBS), with costs aligned to the estimate and, where appropriate, the work breakdown structure (WBS). It separates:

• Estimate uncertainty: variation in quantities, rates, productivity or other assumptions within defined scope.
• Discrete risk events: identifiable uncertain events, each with a probability of occurrence and a cost consequence.
• Base cost and allowances: the deterministic estimate and any provisions already included.

Map each risk-register entry to the model: identify its cause, affected cost line, probability, impact range, owner, mitigation and treatment in the base estimate. Each exposure should appear once, in the right place.

2. Select distributions that fit the evidence

A distribution is a description of uncertainty, not decoration. Choose it to reflect the nature of the input and the quality of available evidence.

Distribution	A defensible use	Watch point
Triangular	A bounded input with credible low, most-likely and high estimates	Simple and transparent, but can imply a sharp peak
PERT/beta	A bounded input where the most-likely value should carry more weight than the extremes	The chosen shape still depends on credible range estimates
Normal	A roughly symmetric variable with no meaningful probability of impossible values	Can generate negative or otherwise implausible values
Lognormal	A positive, right-skewed variable where large adverse values are possible	Avoid using it as a default without evidence for the skew
Discrete	A defined set of possible outcomes, such as alternative responses or event consequences	Probabilities must be explicit and total 100%

For estimate uncertainty, triangular or PERT distributions are often practical when robust historical data are limited. If reliable, relevant data exist, an empirical distribution may be more defensible. Use a normal distribution only where symmetry and its unbounded tails are reasonable for that input.

For a discrete risk event, model the chance that it occurs separately from the cost if it occurs. A risk with a 30% probability should not be entered as a guaranteed cost at 30% of its impact if the model needs to show the full range of possible outcomes.

Eliciting low, most-likely and high estimates

Do not ask for three numbers without defining them. Agree what the values mean, including scope, assumptions, mitigation status and price base. Ask the estimator or risk owner to explain the evidence behind each point: comparable work, supplier information, productivity records, design maturity or professional judgement.

The low and high values should be plausible bounds for the selected modelling purpose, not best-case and worst-imaginable outcomes. Record who provided them, when, and what would cause them to change. Challenge estimates that are unusually narrow, or that combine several unrelated drivers into a single range.

3. Model dependence, not just individual risks

Inputs are rarely independent. Shared market conditions may affect multiple material rates; weather may influence productivity and duration; late design information may affect both rework and procurement. If those inputs are modelled as independent, the combined upper tail can be understated.

The practical approach is to identify common causes first. Use shared risk drivers where possible, then document any necessary correlation assumptions in a correlation matrix. A matrix records the assumed relationship between selected inputs; it should be checked for mathematical validity and explained in plain language. Avoid applying correlation indiscriminately: it can just as easily distort the result as improve it.

Test the effect of material assumptions by comparing the model with independence against the adopted correlation case. Where the result changes significantly, treat that difference as a governance issue requiring evidence and scrutiny, not a technical footnote.

4. Run the simulation and test stability

In each iteration, the model samples the uncertain inputs, calculates the resulting costs and stores the outcome. Repeating the process produces a cost distribution rather than one point forecast.

For a typical project model, 5,000–10,000 iterations can be a useful starting range. It is not a guarantee of accuracy. A rare event or a decision that depends on the extreme tail may require more runs. Monte Carlo random sampling draws values randomly from each input distribution. Latin Hypercube sampling divides each distribution into probability bands and samples across those bands, improving coverage of the input space for a given run count. Neither method corrects poor inputs or a flawed model.

Check convergence by running the model again with a different random seed or in independent batches. Compare the outputs that matter to the decision, especially P80 or P95-not only the mean. If key percentiles move materially between runs, increase iterations or investigate why the model is unstable. Record the iteration count, sampling method, software settings and stability checks.

5. Link cost analysis to the schedule where it matters

Where time drives cost, a standalone QCRA can miss important exposure. Prolonged site overheads, time-dependent escalation, acceleration and delayed procurement are common examples. An integrated model can pass schedule risk into cost outcomes, but only if the cost and schedule logic are aligned and the relationship is causal.

For example, an activity delay may extend preliminaries. The model should represent that consequence once; adding a separate delay-cost risk on top could double count it. Likewise, a schedule event that changes cost but not duration should not be forced into the schedule model.

In Monte Carlo schedule risk analysis, sampled durations are run through the schedule network so critical paths can change from iteration to iteration. Where cost is linked to those outcomes, the model can show how schedule uncertainty affects cost. The QCRA vs QSRA guide explains when separate or integrated analysis is appropriate. AACE’s guidance on integrated cost and schedule risk analysis provides further technical context.

6. Read the outputs in decision terms

The main output is usually a cumulative distribution, often called an S-curve. It shows the probability of an outcome at or below each cost value. A histogram shows how frequently outcomes fall within defined cost bands.

A percentile is a position on that distribution: P80 cost means the model estimates an 80% probability that cost will be at or below that value, subject to the model’s assumptions. P50 is the median, not a guaranteed budget.

Reporting convention	Interpretation
P50 / P80 / P95	Median, 80% confidence and 95% confidence cost positions
P10 / P50 / P90	Lower-bound, median and upper-bound positions used on some programmes

Some programmes report P10/P50/P90 rather than P50/P80/P95. The reporting convention should follow the programme’s funding and governance policy. The important control is consistency between the stated confidence level, contingency held and rules for drawdown.

A tornado or sensitivity chart ranks the inputs that most influence the modelled result. It is useful for prioritising investigation and mitigation, but it is not a substitute for checking the risk register: sensitivity shows influence on the modelled output, not whether a risk has a credible owner or response.

Illustrative example

Suppose a defined cost item has a low estimate of £900,000, a most-likely estimate of £1,000,000 and a high estimate of £1,250,000. Separately, a discrete event has a 30% chance of occurring, with a cost impact between £200,000 and £500,000 if it occurs. The simulation samples the estimate uncertainty and tests whether the event occurs in each iteration. It then combines the resulting costs with the other modelled items.

The example is intentionally small: a live project model must also account for the cost boundary, dependencies, mitigation and any schedule-linked consequences.

7. Document and assure the model

A model should be reproducible and reviewable. Maintain an assumption log, distribution rationale, risk-to-cost mapping, correlation record, model version, input dates and named approvals. Before each refresh, obtain sign-off from the relevant estimate owners and risk owners that inputs remain current and mitigation status is accurately reflected.

Assurance should test more than arithmetic. Reviewers should examine whether:

• The base estimate and cost boundary are clear.
• Risks are mapped to the correct cost lines and not double counted.
• Distribution ranges and probabilities have evidence.
• Correlations reflect credible shared causes.
• Schedule links and time-related cost logic are sound.
• Outputs are stable enough for the decision being made.
• Changes since the previous model run are traceable and explained.

Common failures have practical remedies: unclear scope needs a defined baseline; unsupported ranges need evidence and recorded judgement; double counting needs a risk-to-model map; omitted dependence needs driver analysis; unstable tails need further convergence testing. A technically polished S-curve cannot repair these weaknesses.

Conclusion

Monte Carlo QCRA is most useful when it makes uncertainty visible and connects that evidence to a decision. Build the model from the estimate and risk register, select distributions that match the inputs, represent dependence deliberately, test convergence and document the assumptions. Where schedule affects cost, link the analyses through clear causal logic.

That discipline is what makes a P-level meaningful, and what allows project leaders to use the result with appropriate confidence.

About the author

Nick Garvey is MCIOB, FCaSA and FQSi, with more than 25 years’ experience in commercial leadership and project controls. His work includes cost risk governance, monthly risk reviews and QSRA oversight on a major defence infrastructure programme.

All views my own, shared in a personal capacity.