Key Takeaways
- A contingency figure derived from expected monetary value calculations is defensible to a board; one derived from a percentage rule of thumb is not, because it contains no information about the actual risks on your project.
- Known unknowns belong in contingency reserve, which the project manager controls and which should trace directly to specific risks in the register. Unknown unknowns belong in management reserve, a separate buffer held by senior leadership for events the project team could not have anticipated.
- Contingency percentages should shrink as project maturity increases: around 20 percent is appropriate at feasibility stage, 10 to 15 percent at detailed engineering, because uncertainty genuinely reduces as scope is defined.
- Large capital projects routinely overrun their budgets by significant margins, and the most common cause is not poor execution but optimism bias at the planning stage, where political pressure produces a budget that was never realistic.
- Running a Monte Carlo simulation across your risk register produces a probability distribution of cost outcomes, including P50, P85, and P90 figures, which gives you a basis for contingency that reflects the specific risk profile of this project rather than industry convention.
Large capital projects routinely overrun their budgets by enormous margins. The explanation is rarely bad site management or unexpected weather. The root cause is almost always the same: insufficient contingency planning at the outset, shaped by optimism bias and political pressure to present a budget the client or board will approve.
Project risk budgeting contingency is not a line item you add at the end when the estimate feels a little thin. It is a structured response to the specific risks sitting in your register, calculated from the evidence you have, and traceable back to individual risk assessments. The gap between a defensible contingency and an optimistic guess is almost always the quality of the risk thinking behind it.
Why most contingency budgets fail before the project starts
The standard approach goes something like this. The estimating team builds a cost model, someone senior asks what contingency to add, and a figure between 10 and 15 percent arrives through a combination of habit, industry convention, and the desire not to lose the bid or the board approval.
That percentage is not wrong in every case. It can be a reasonable order-of-magnitude check when you have very little project definition to work with. The problem is when it becomes the answer rather than a sanity check. A blanket percentage applied to a EUR 50 million project budget tells you nothing about whether your contingency of EUR 6 million is too high for the risks you have actually identified, or dangerously low for the ones you have not.
Optimism bias compounds the problem. Project teams are structurally incentivised to present lean budgets. A realistic contingency calculation that produces EUR 12 million on a EUR 50 million project is politically difficult to defend, so it quietly becomes EUR 6 million. By the time the risks materialise, the money is not there.
Known unknowns and unknown unknowns: the distinction that changes everything
Every project operates with two categories of uncertainty, and mixing them up in the budget creates real problems.
Known unknowns are risks you have identified, assessed, and registered. You do not know exactly when they will occur or precisely what they will cost, but you know they exist. A supply chain delay on a key component, a planning permission that might take longer than the programme allows, a subcontractor with a thin track record in this type of work. These risks have owners, probability assessments, and impact estimates. They belong in the contingency reserve.
Unknown unknowns are things you genuinely could not have anticipated at the time of planning. A new regulation that changes the technical requirements mid-project. A geopolitical event that closes a critical supply route. The financial collapse of a key supplier. These events are outside the project team's normal sphere of foresight, and they belong in management reserve, a separate budget buffer held by senior management, not the project manager.
The distinction matters for governance as much as for calculation. The project manager has authority to draw on contingency reserve to address known risks as they materialise. Management reserve requires an escalation and a decision at a higher level. Conflating the two means your project manager is either sitting on money that should have been in the reserve, or spending money that was never theirs to allocate.
A well-structured project budget keeps these three layers clearly separated: the base estimate, the contingency reserve for identified risks, and the management reserve for residual uncertainty. The UK's HM Treasury Green Book, the government's standard guidance on appraisal and evaluation for public spending decisions, is explicit on this point: a properly defined contingency should be traceable to specific risks, estimate assumptions, estimate maturity, and historical project data. It is not a convention. It is a structured response to the specific risk profile of this project at this stage.
How contingency percentages should move with project maturity
One of the more useful contributions of cost engineering practice is the recognition that contingency is not a fixed number. It should reduce as project definition improves, because uncertainty genuinely decreases as scope, design, and procurement become clearer.
A rough order of magnitude at feasibility stage might reasonably carry a contingency of around 20 percent, reflecting the breadth of unknowns at that point. By the time detailed engineering is complete and major contracts are placed, 10 to 15 percent is a more appropriate range, because you have eliminated a large portion of the uncertainty that existed earlier.
The important word is "appropriate," not "standard." A project with a well-populated risk register, good historical data on similar scopes, and experienced subcontractors might support a contingency at the lower end of the range at detailed engineering. A project with novel technology, limited comparable data, and a volatile supply chain might need more. The percentage is an input to a judgement, not a substitute for one.
What changes this from a rule of thumb into a real calculation is the quality of the risk assessment sitting underneath it. If your register has thirty identified risks with probability assessments, financial impact estimates, and named owners, you have something to calculate from. If your register has twelve vague entries with no scores and no owners, you have decoration, and no percentage will rescue that.
From risk register to contingency reserve: the calculation that matters
Expected monetary value is the simplest bridge between a risk register and a contingency number. For each identified risk, you take the probability of occurrence and multiply it by the estimated financial impact if it occurs. Sum those figures across your register, and you have a baseline contingency figure derived from actual risk assessments rather than convention.
Picture a construction project with five significant identified risks. A ground condition risk with a 30 percent probability and a EUR 400.000 cost impact if it occurs contributes EUR 120.000 to the expected monetary value. A planning delay risk with a 40 percent probability and a EUR 250.000 cost impact contributes EUR 100.000. A procurement risk at 20 percent probability with a EUR 600.000 impact contributes EUR 120.000. Two smaller risks add another EUR 60.000 between them. Your expected monetary value across those five risks is EUR 400.000, which gives you a contingency figure you can stand behind in a board conversation, because it traces directly to specific identified risks with named owners and assessed probabilities.
The limitation of a simple expected monetary value calculation is that it treats each risk independently and produces a single point estimate. In reality, risks can correlate, impacts can be skewed, and the distribution of outcomes matters as much as the central figure.
This is where Monte Carlo simulation adds real value. Rather than treating each risk as a single probability-times-impact calculation, you assign a range to each impact using a triangular distribution — a minimum, most likely, and maximum — and run thousands of simulated scenarios. The output is a probability distribution of total cost outcomes. From that distribution you can read a P50 figure (the outcome with a 50 percent probability of not being exceeded), a P85, and a P90. A board asking where the contingency figure came from can be told it represents the P85 outcome from a Monte Carlo simulation across forty-seven identified risks. That is a very different conversation from "we added 12 percent."
Risk Companion supports this directly. Risk assessments in the platform can be entered as triangular distributions, and the Monte Carlo simulation runs across the full register to produce those percentile outputs. You are not working from a spreadsheet where someone has typed a formula into a cell and hoped for the best. The contingency figure comes from the risk register, which means every change to a risk assessment updates the analysis. If a risk owner closes a measure and lowers the probability on a significant risk, the contingency calculation reflects that immediately.
Why the risk register is the budget document nobody uses
Here is the uncomfortable observation. On most projects, the risk register and the contingency budget are maintained by different people, updated on different cycles, and reviewed in different meetings. The register is a risk management document. The budget is a finance document. They reference each other in theory and ignore each other in practice.
This disconnect is where budget overruns are born. A risk that has been assessed at EUR 300.000 impact and 35 percent probability might not survive the translation into the finance model. Someone converts it to "contingency for supply chain issues: EUR 80.000" and moves on. By the time the risk materialises at EUR 290.000, the EUR 80.000 looks like a rounding error.
The solution is not a new process. It is a better connection between the two documents. When the risk register contains the financial impact estimates, the probability assessments, and the Monte Carlo output, it is already the contingency budget. You are not translating between two systems. You are reading two views of the same underlying data.
That connection also disciplines the risk register itself. When people know the register feeds the contingency calculation, vague entries with no probability and no impact estimate become a problem. "Regulatory changes may affect project delivery" is not a risk assessment. It is a placeholder. A register that feeds the budget forces specificity: which regulation, what probability, what financial impact under which scenarios.
What a defensible contingency actually looks like
A defensible project risk budgeting contingency has four characteristics.
It is traceable. Every euro in the contingency reserve maps to at least one identified risk in the register, with a named owner, a probability, and an impact estimate.
It reflects estimate maturity. The percentage is not a fixed habit. It acknowledges how much project definition exists at the point of calculation and adjusts accordingly.
It separates known from unknown. Contingency reserve and management reserve are distinct line items with distinct governance, not a combined buffer that the project manager can dip into freely.
It updates as the project progresses. Risk assessments change. Measures close risks. New risks emerge. The contingency is not set at the start and forgotten. It is a live number that the risk register keeps current.
Industry percentages of 10 to 15 percent give you a useful reference point. They are not a substitute for a calculation grounded in your actual risk register. The destination is a number with a probability distribution behind it, derived from the specific risks on this project, and presented with enough transparency that someone asking "where did that figure come from?" gets a real answer.
Risk Companion's free 14-day trial builds a demo project from your own organisation's profile, so you can see the P85 Monte Carlo output and the EMV breakdown for your identified risks before you commit to anything. No credit card needed. Start your free trial at risk-companion.com.
Ready to improve your risk management?
See how Risk Companion can help you implement these best practices with powerful, easy-to-use tools. Sign up and we'll prepare a demo project tailored to your company.