Cost risk analysis quantifies the uncertainty in a cost estimate. Each uncertain line item gets a range instead of a single number, identified risks get a probability and an impact, items that move together are correlated, and a Monte Carlo simulation turns all of it into a probability distribution of total cost — the basis for contingency and funding decisions.
The single-number alternative fails quietly. A base estimate built from most-likely values is not a 50/50 number: cost ranges are right-skewed and identified risks only ever add cost, so the base typically sits well below the median — in the worked example on this page, a €12.0m base has an 82% chance of being exceeded. Cost risk analysis exists to replace “the estimate plus a percentage we can defend in a meeting” with a funding level chosen off the project's own distribution — a P80 — that a review board can interrogate line by line. This page covers the methods in use, how the standard model is built, and the outputs the analysis should hand a decision-maker; every number quoted comes from a downloadable model you can check.
Both, for different jobs. Qualitative analysis — the probability–impact register, the heat map — is a screening tool: it collects the risks, forces owners to be named, and sorts the obviously trivial from the possibly serious. Quantitative analysis is a funding tool: it puts a number and a confidence level on the total, which a heat map cannot do — no arrangement of red, amber and green cells answers “how much contingency does this project need?”.
The practical failure mode is stopping at the first one: scoring risks 1–5, multiplying two ordinal scales together, and treating the result as arithmetic. Ordinal scores cannot be added or multiplied meaningfully, and a register full of them creates the feeling of analysis without its content. The mature pattern is a short qualitative pass to decide which uncertainties and risks deserve quantification, then a quantitative model of those — a focused subset of material uncertainties and top risks, not the whole register.
Five approaches cover practice, from the crude to the complete. They answer different questions, and a serious estimate review will usually see two of them — a bottom-up model plus a top-down sanity check.
These are not rivals. The core of a defensible analysis is the third row — a first-principles Monte Carlo model of this project's estimate — with the fourth as an independent challenge (“projects like this one have historically overrun by more than your model says — why is yours different?”). The first two survive only as placeholders before a real analysis exists. The fifth becomes necessary when time is money: on schedule-driven projects, most of the cost risk enters through the calendar, and a cost-only model structurally understates it.
The standard structure has five steps, and it deliberately mirrors how the estimate was built in the first place. One: start from the line-item base estimate at most-likely values. Two: give each uncertain item a three-point range — low, most likely, high, elicited from whoever owns the number — and model it with a distribution such as PERT that respects the skew (where an item has real historical data behind it, fit a distribution to that data instead). Three: add the discrete risks from the register as risk events — a probability and an impact range, kept together as one entity per risk, because either the ground conditions are worse than surveyed or they are not. Four: correlate the items that move together; a common market or productivity driver across the big packages is the rule, not the exception. Five: simulate — enough samples that the percentiles are stable — and read the results off the distribution.
Step four is the one most often skipped, and it is quietly expensive: in the worked example, switching the correlation off drops the P80 by about €295k — roughly 15% of the contingency — while leaving the model looking identical on the surface. A model that assumes its line items are independent undersizes the reserve by exactly the amount nobody can see. The full step-by-step walkthrough, with the elicitation and distribution choices spelled out, is in our guide to calculating cost contingency; the finished model behind it is a free download that runs on the ModelRisk trial.
Three artifacts, each answering a different decision-maker question. The first is the S-curve — the cumulative distribution of total cost — which answers “how confident are we at any given budget?” and makes the central problem visible: the base estimate sits far down the curve, not in the middle of it.
The second is the percentile menu the funding decision chooses from. From the €12m worked example (400,000 samples; figures in €000):
Which percentile to fund at is a real decision with a real method behind it — our contingency guide covers choosing between P50, P80 and P90 from the cost of being wrong in each direction. The third artifact is the ranked list of drivers: a tornado chart showing which inputs actually move the total, in euros. In the worked example it reports that a shared market/productivity driver dominates the project (six correlated items with ~€2.2m bars), that the ground-conditions risk is the largest independent driver (€1.28m), and that the second-largest line item — ordered mechanical equipment — is worth no further analysis effort at all (€56k). That ranking is what turns the analysis from a funding exercise into a management one: it says where de-risking money should go next.
A review board that knows its job asks three questions: where do the ranges come from, what did you assume moves together, and what happens to the number if I poke it. A defensible analysis has answers ready. The ranges are elicited from named owners and documented, not typed in by the analyst. The correlation is explicit, justified, and testable — the worked model ships with a switch that reruns it with the correlation off, so the €295k it contributes to the P80 is an auditable fact rather than an opinion. The risks are modelled as single events, not split into probability and impact cells that quietly halve their visibility in the sensitivity ranking.
Two arithmetic rules protect the result from well-meaning damage downstream. Percentiles do not add — the sum of line-item P80s is not the project P80, so contingency must be read from the simulated total, never assembled bottom-up. And a probability-weighted “expected value of the register” is not a reserve — funding at the mean still leaves close to a coin-flip chance of overrun (in the worked example the mean, €13.05m, sits barely above the P50 of €12.96m). Reproducibility closes the case: an analysis whose model can be handed over, opened in ordinary Excel, and rerun to the same figures survives an audit in a way a slide deck never will.
For cost-only analysis, a Monte Carlo add-in inside Excel is the right tool — the estimate is already a spreadsheet, and the model should stay one your reviewers can open. ModelRisk covers the whole method described above natively: 135 probability distributions including the three-point PERT family, risk events, correlation with copulas, conditional-mean tornado charts, and simulation reports to Word, PowerPoint and PDF — at a maximum of €1,550 per user per year, with a free fully-functional 15-day trial and built-in converters for existing @RISK and Crystal Ball models.
For integrated cost–schedule analysis, the model has to live where the schedule lives: Tamara imports Primavera and Microsoft Project schedules directly and simulates cost and time together, so delay flows into standing time, overheads and escalation instead of being estimated separately. For a market-wide view of the options in both categories, our review of project risk analysis tools compares the realistic candidates honestly, prices included.
What is cost risk analysis? Cost risk analysis quantifies the uncertainty in a cost estimate. Instead of one number, each uncertain item gets a range, identified risks get a probability and an impact, items that move together are correlated, and a Monte Carlo simulation turns all of it into a probability distribution of total cost — the basis for contingency and funding decisions.
How is cost risk analysis different from calculating contingency? Contingency is one output of a cost risk analysis: the distance from the base estimate to the confidence level you choose to fund at, read off the simulated distribution. The analysis itself produces more — the full S-curve, the ranked cost drivers, and the evidence trail that lets a review board interrogate the number rather than take it on faith.
How much contingency is typical? There is no defensible typical percentage — contingency should be derived from the project's own simulated distribution, not benchmarked from a rule of thumb. In our worked example a P80 funding level implies 16.4% of the base estimate, and a flat 10% would fund the same project at only about the P58 — a materially different promise to the board.
What is integrated cost and schedule risk analysis? A method that simulates the project schedule and the cost estimate together, so that delay flows into cost through time-dependent items such as site overheads and escalation. It is the right tool when schedule risk is a major cost driver. Tamara runs this analysis directly on Primavera and Microsoft Project schedules.
What data does a cost risk analysis need? Four things: a line-item base estimate; three-point ranges (low, most likely, high) for the uncertain items, ideally elicited from the people who own them; a risk register with a probability and an impact range for each discrete risk; and a view on which items move together, so the model can correlate them. Historical outturn data, where it exists, calibrates the ranges.
Ranges, risk events, correlation and the full percentile menu on your own estimate — download the worked-example model, check every figure on this page, then point the same method at your project.