Most capital project budgets carry money above the base estimate. Ask what that money is for, and the answers start to drift. One person calls all of it contingency. Another says part of it is reserve. A third says the reserve is "just contingency the project can't touch." By the time the budget reaches a funding review, nobody can say which dollars cover which uncertainty, who can release them, or how the amount was arrived at.
Contingency and management reserve are different things. They cover different uncertainty, they're sized differently, they belong to different owners and they're spent differently. Keeping them apart is one of the cheapest controls a project can have.
Two kinds of uncertainty
Contingency covers uncertainty inside the defined scope. It's for things you know about but can't price exactly: pricing ranges on the estimate lines, quantities that will grow as design develops, productivity, and the discrete events on the risk register, each with a probability and an impact. Taken together, contingency is expected to be spent. Not every dollar on every line, but in aggregate a project that finishes with all of its contingency untouched was probably estimated high.
Management reserve covers what hasn't been identified. It's money for the risks nobody has written down yet, the conditions no one anticipated, the outcomes outside the range the analysis considered. It isn't expected to be spent on any particular thing, because by definition nobody knows what that thing would be.
The common standards draw the same line. PMI's project management guidance keeps contingency reserve inside the cost baseline the project is measured against, and keeps management reserve outside that baseline but inside the overall budget. AACE International's cost engineering terminology lists management reserve among the things contingency typically does not include, along with major scope changes. The wording differs between organizations, but the separation is consistent: contingency belongs to the project's scope, and reserve sits above it.
Who owns which
The ownership question matters more than the definitions, because it decides how each one actually gets used.
Contingency usually belongs to the project. The project manager or project controls lead holds it and draws it down as risks materialize, through the project's own change process. That's appropriate: the project team is closest to the risks and best placed to see when one has occurred.
Management reserve usually sits one level up, with the sponsor or the business. Releasing it typically means moving budget into the project's baseline through a formal change, because it's money the project was never measured against.
Whatever the arrangement in your organization, write it down. For each pot: who can release it, on what evidence, and where the release is recorded. If those three answers are vague, the two pots will merge the first time the project is under pressure.
How each one gets sized
Contingency can be analyzed, because its contents are known. A quantitative risk analysis puts ranges on the estimate, adds the discrete events, models how related work moves together, and simulates the result. Contingency is then read off that distribution at a confidence level. The analysis describes the curve, and choosing where to stand on it is a decision for the people accountable for the funding. If the percentiles themselves need unpacking, What P50 and P80 Really Mean covers what a confidence level does and doesn't tell you.
Management reserve can't be analyzed the same way, because its contents aren't identified. Organizations usually set it by policy, by portfolio experience, or by how novel the project is: a first-of-a-kind process, a new region, an unfamiliar delivery model. That's a legitimate basis, but it's a different basis, and it should be written down as its own rationale. A reserve justified as "a bit more on top of contingency" is really just a higher confidence level that nobody chose on purpose.
Where the two get blurred
The same failure modes show up again and again:
- Reserve sized as a markup on contingency. If the reserve is a fixed fraction of the contingency figure, it's padding on the same curve, not cover for anything the curve leaves out.
- Contingency spent on scope changes. A new requirement from the owner is a change to the scope, not a risk within it. Paying for it out of contingency leaves the risks contingency was sized for with less cover than the analysis assumed.
- The same exposure in both. A risk that's on the register and in the model is already inside contingency. Holding reserve "for that one too" counts it twice.
- Drawdowns without a record. If contingency is released without saying which risk occurred, nobody can tell at the end whether it went to real risks or to estimate errors, and the next project learns nothing.
- Contingency released early. Returning unspent contingency before the risks it covers have actually been retired turns a good month into a bad quarter.
- Contingency buried in the lines. Padding individual line items hides money from the analysis and from the basis of estimate. It can't be measured, attributed or explained, and it usually ends up counted again in the contingency anyway.
Questions to settle before the next funding review
- What does our contingency cover, and what does it explicitly exclude? Where does escalation live: inside the risk analysis or carried as its own line? Either works, as long as it's written down and counted once.
- Which estimate version was the contingency analyzed against, and at what confidence level?
- Who can release contingency, who can release reserve, and on what evidence?
- What's the written rationale for the reserve, separate from the contingency analysis?
- Is any exposure counted in both?
- How are drawdowns recorded, and against which risk?
If a team can answer those in a few sentences each, the money above the base estimate has a story behind it. If they can't, the budget has a number on it, but no one can say what it's for.
Where the software fits
Jakten Risk works on the contingency side of that line. It runs a Monte Carlo analysis on a specific estimate version and reports the funding contingency at the confidence level your team selects. That figure includes pricing spread, quantity growth, schedule-driven cost, dependency effects and discrete risk events, and attribution shows how much each risk layer adds at your confidence target, so "what is this contingency for?" has an answer on the page.
In Jakten Assurance, the Cost Model can reference that published contingency result as its own row as the estimate builds from direct cost to the loaded total, separate from any percentage or lump-sum rows your team adds. If the Risk result is missing, the row shows as unavailable, never as zero.
Management reserve isn't something Jakten models. It's a decision held above the project, and it should stay one. Jakten supports professional judgment; it does not approve or authorize funding decisions.
To see the contingency analysis on a fictional sample project, the Jakten Risk page has a short demo and sample reports.