Why this matters
The conflation of cost contingency and schedule contingency costs money every year on projects that should know better. Not because the teams involved are incompetent, but because the two things are referred to using the same word, governed by different parts of the organisation, and consumed in entirely different ways. The confusion is structural, and it persists because nobody explicitly explains the distinction at the start of a project.
The practical consequence is that boards and sponsors are routinely asked to approve "the contingency" as a single line item in a funding paper, without any clarity about whether they are approving a cost buffer, a schedule buffer, or some conflation of both. Risk managers report contingency drawdown without distinguishing between cost overruns and schedule slippage. And when a project is delayed, the question "should we draw down contingency to recover the programme" gets answered differently depending on who in the room you ask — because the finance director and the project planner are using the same word to mean different things.
Getting this distinction right matters most at three points: when you are setting the project budget, when you are advising a board on funding adequacy, and when you are deciding how to respond to a delay. In all three cases, treating cost and schedule contingency as a single undifferentiated pot leads to decisions that are at best suboptimal and at worst actively harmful to the project.
The structural difference
Cost contingency lives in the budget. It is a financial reserve, owned by finance or the project sponsor, held above the base cost estimate to cover the cost impact of risks that materialise. It is drawn down through formal change control: a risk event occurs, the cost impact is quantified, a change is raised, and the contingency is released to cover it. Cost contingency is denominated in pounds. It appears on the project's financial statements. It is subject to governance approvals before it can be accessed.
Schedule contingency lives in the schedule. It is a time buffer, owned by the planner or project manager, built into the programme to absorb delays without pushing the completion date beyond its target. Schedule contingency can take two forms: float on the critical path (the difference between the calculated completion date and the target completion date, where that difference is positive), or explicit buffer activities built into the programme at strategic points. Schedule contingency is denominated in time. It does not appear on financial statements. It is consumed when activities overrun their planned durations.
These two things are not interchangeable. A two-month schedule slip does not get fixed by drawing down £2m of cost contingency — unless you can spend that money to compress the schedule, and even then, compression through additional resources or acceleration works only where the critical path activities are genuinely resource-constrained and can be crashed. Many schedule slippages cannot be bought out. Ground conditions, regulatory approvals, weather, third-party interfaces — none of these respond to additional spend in the way that, say, doubling the labour force on a constrained excavation might.
The governance implications follow from this structural difference. Cost contingency is a financial governance question: who can approve drawdown, what evidence is required, what is the residual exposure if it is drawn down. Schedule contingency is a programme management question: how much float remains on the critical path, which activities are consuming it, and when does float exhaustion trigger a formal recovery plan. These questions go to different people, require different evidence, and have different consequences if the answer is unsatisfactory.
On a well-run project, both are tracked separately and reported separately. The cost report shows the base estimate, approved changes, cost contingency held, and forecast final cost. The schedule report shows the current programme, float on the critical path, schedule contingency consumed to date, and forecast completion date. The two reports inform each other but are not substitutes for each other.
How three-point estimates feed both
Three-point estimates are the mechanism by which individual risks are translated into contingency. For each risk on the register, the estimator specifies three values: the minimum cost impact if the risk occurs, the most likely cost impact, and the maximum cost impact. The same three values are specified for schedule impact. A probability of occurrence is also assigned.
The simplest aggregation of these inputs is the Expected Monetary Value (EMV) calculation. For each risk, EMV = probability × ((minimum + most likely + maximum) / 3). This gives you the probability-weighted expected cost impact of that risk. Summing the EMVs across the entire risk register gives you the EMV-weighted contingency: the total expected cost exposure from all identified risks.
The same arithmetic applies to schedule impact. For each risk, calculate probability × ((minimum duration impact + most likely + maximum) / 3) to get the expected schedule impact in days or weeks. Aggregate across the register and you get the expected schedule exposure. This is useful for understanding the aggregate picture, but it has a significant limitation: it assumes all risks are independent, which they are not. A weather delay that extends groundworks will also delay the structure, which will also delay fit-out. The EMV of each risk in isolation does not capture how they interact.
This is the structural reason Quantitative Risk Analysis (QRA) exists. A Monte Carlo simulation does not just add up the expected values — it models the interaction of risks, captures correlation between related activities, and produces a distribution of possible outcomes rather than a single point estimate. The difference between the EMV and the P80 from a QRA is not a matter of arithmetic; it is the additional uncertainty that comes from risks combining in adverse ways. On a complex project, the P80 from a well-run QRA will typically be materially higher than the sum of the individual EMVs, precisely because real projects experience clusters of bad luck rather than a smooth average of risk impacts.
For cost contingency, the three-point estimates on cost risks feed the cost QRA model. For schedule contingency, the three-point estimates on schedule risks feed the schedule risk model (integrated cost-schedule risk analysis handles both simultaneously, which is the most rigorous approach but requires a well-structured schedule as input). The output of each model is a distribution: for cost, a range of possible final costs with associated probabilities; for schedule, a range of possible completion dates with associated probabilities.
EMV vs QRA — when each is right
EMV is right for forecasting and forward visibility. If you want to understand how much contingency to release back to the budget each quarter as risks close out, EMV is the right tool. As risks are retired from the register, their EMV contribution is removed from the expected exposure, and the remaining contingency requirement reduces. This gives finance a rational basis for releasing contingency back to the budget or to other parts of the programme as the project de-risks over time.
EMV is also useful as a sense-check on the risk register. If the aggregate EMV across the register is £50m on a £200m project, that is a 25% expected overrun. That is either a signal that the base estimate is well-calibrated and the risks are genuinely significant, or a signal that the risk register has been over-populated with high-probability, high-impact risks that are not independent of each other. Either interpretation is worth understanding.
QRA is needed when you need a defensible confidence level for a contingency recommendation. If you are writing a board paper recommending that the project be approved with a £30m contingency, you need to be able to say what confidence level that represents. "We recommend £30m of contingency because the EMV of the risk register is £28m" is not a defensible statement — it implies that the contingency is adequate only if risks occur exactly as expected, with no clustering, no correlation, and no surprises beyond those already on the register. That is not how projects work.
"We recommend £30m of contingency based on a QRA that gives a P80 cost outcome of base estimate plus £30m, meaning there is an 80% probability that the final cost will be within that figure" is a defensible statement. It acknowledges uncertainty, it quantifies the confidence level, and it gives the board a clear picture of the residual exposure: there is a 20% chance the project will cost more than the contingency allows, and the QRA shows what that tail exposure looks like.
Confusing EMV with QRA is one of the most common mistakes in board papers and gateway submissions. The two numbers are often close enough that the distinction seems academic — until the project hits a cluster of correlated risks and the actual outcome lands in the tail of the distribution that EMV never acknowledged.
Defending the contingency number in a board paper
The contingency number in a board paper is the figure that gets the most scrutiny and the least context. Boards are accustomed to challenging it: "why is contingency 20% of the base estimate?", "can we reduce it to get the project within budget?", "what happens if we approve less?" These are legitimate questions. The problem is that contingency recommendations are often presented in a way that invites those questions rather than pre-empting them.
Lead with the confidence level you are recommending and why. Not the number first — the confidence level. "We are recommending a contingency provision that gives the project an 80% probability of completing within the approved budget" is a statement about risk appetite and governance, not just about money. It frames the number as a decision about acceptable risk exposure rather than a cost estimate to be negotiated down. The P80 figure then follows as the consequence of that decision.
Back it up with the QRA output, the top five risk drivers, and the residual exposure if contingency is set lower. The QRA output — even a simplified S-curve showing the P50, P80, and P95 cost outcomes — gives the board a picture they can reason about. The top five risk drivers from the tornado chart tell the board what to watch: if those specific risks are actively managed, the contingency requirement reduces. The residual exposure at P70 or P60 tells the board what they are accepting if they approve less than the P80 recommendation: "if the board approves £20m rather than £30m, the project has a 60% probability of completing within budget and a 40% probability of requiring further funding — the expected overrun in the latter scenario is £8m." That is a decision the board can make. Approving a number without that context is not governance; it is guessing.
What not to do: do not apologise for the size of the number. Contingency is not a sign of poor cost management; it is an honest acknowledgement that complex projects involve uncertainty. A project team that presents a small contingency to avoid challenge, knowing the real exposure is higher, is not managing risk — it is deferring the problem. The board will encounter the real exposure eventually, and they will be less sympathetic when it arrives as a cost overrun than they would have been if it had been presented honestly at the start.
Do not lead with the EMV. EMV is a useful internal calculation; it is not a board-level recommendation. The EMV represents the average expected outcome across all possible scenarios, but boards are not funding the average scenario — they are funding the project, which will experience one specific set of outcomes. The P80 is the right number to recommend because it reflects a genuine risk appetite decision: we are confident enough in this outcome to fund it, and we accept that there is a 20% chance we will need to return for more.
Do not hide the assumptions. Every QRA rests on assumptions about risk probabilities, impact ranges, and correlations. If those assumptions are challenged, the output changes. Be explicit about the key assumptions: the risks that are driving the contingency, the probability and impact ranges used for each, and any areas where the modelling team has limited data and has had to use professional judgement. Transparency about assumptions is not a weakness in a board paper; it is a mark of analytical rigour. It also makes the recommendation harder to dismiss, because a board that challenges an assumption must propose an alternative — and that forces a substantive conversation about the actual risk rather than a procedural challenge to the number. On MoD CADMID Concept and Assessment-stage business cases, the same logic applies in front of an IPA Gateway Review: lead with the confidence level, present the QRA output, and be transparent about the optimism-bias adjustment and the reference class behind it.