Contingency Reserve vs Management Reserve: Who Owns Which

Ask a PM where the contingency reserve line item is and most can point to it. Ask where the management reserve is, and how much of it is left, and the answer gets vague fast, usually because both numbers were folded into a single "buffer" line during budgeting and nobody has tracked them separately since. That's the mistake: contingency reserve vs management reserve isn't a naming preference, it's two pots with different owners, different triggers, and different accounting treatment, and treating them as one pot means neither gets managed correctly.

The direct answer: contingency reserve covers known risks identified in the risk register, sits inside the approved cost baseline, and the PM can release it without a change request. Management reserve covers unknown-unknowns nobody identified in advance, sits above the cost baseline as part of overall project funding, and needs a sponsor's or change control board's formal approval to release. Spend either one down without tracking which pot it came from, and the project loses the ability to answer a basic finance question: how much true contingency is actually left.

Contingency Reserve: Known Risks, PM-Owned

Contingency reserve exists for risks the team already identified and analyzed during risk planning: a vendor that historically slips delivery dates, a permit that sometimes takes longer than scheduled, an integration with a known history of rework. Each of these is a named line in the risk register with a probability and a cost impact attached, and contingency reserve is the money or time set aside specifically to absorb them if they fire.

Because these risks were already accounted for when the budget was baselined, contingency reserve is part of the approved cost baseline itself. That has a direct consequence for who can spend it: the PM releases contingency reserve when one of the risks it was sized for actually occurs, without routing a change request through the sponsor, because the spend was already planned and approved as part of the baseline. What the PM should not do is spend contingency reserve on a problem that wasn't in the risk register it was sized against; that's a management reserve situation instead, even if the dollar amount looks similar.

Management Reserve: Unknown-Unknowns, Sponsor-Owned

Management reserve exists for the risks nobody identified: the kind of problem that shows up specifically because it wasn't anticipated. A regulatory change mid-project, a key vendor going out of business, a scope discovery nobody could have planned for. Because these are unknown by definition, management reserve isn't derived from the risk register the way contingency reserve is; it's typically set as a percentage of the total project budget, sized to the project's overall estimate uncertainty and the organization's appetite for that uncertainty.

The accounting treatment is the structural difference that matters most: management reserve sits outside the cost baseline, as part of the project's total funding requirement rather than its approved spend plan, a distinction project finance guidance is explicit about. Releasing it requires a formal change request to the sponsor or a change control board, and once approved, that specific amount moves into the cost baseline going forward. This is why management reserve isn't a PM-level decision: spending it changes the baseline itself, which is a governance action, not a schedule action.

The diagram below shows where each reserve sits relative to the cost baseline, since that placement is what drives who can release which one.

Contingency Reserve vs Management Reserve: Side by Side

Dimension	Contingency Reserve	Management Reserve
Covers	Known risks, already in the risk register	Unknown-unknowns, not identified in advance
Part of the cost baseline?	Yes	No, sits above it as part of total funding
Who releases it	The PM	The sponsor or a change control board
How it's released	Directly, when the identified risk fires	Via a formal change request
Sizing method	Expected monetary value from the risk register, or a Monte Carlo simulation	A percentage of total project budget, set by risk tolerance
Effect on the baseline	None, it was already in the baseline	Moves into the baseline once released
Typical owner of the sizing decision	Project manager, during risk planning	Sponsor or PMO, during budget approval

Sizing Each Reserve So It Survives a Finance Review

A finance reviewer's first question about any reserve line is "how did you get that number," and "we added 10 percent to be safe" doesn't survive that question for either reserve, for different reasons.

For contingency reserve, the defensible method starts from the risk register: take each risk's probability and multiply it by its cost impact to get its expected monetary value, then sum the expected monetary values for the risks the reserve is meant to cover. A more rigorous version runs a Monte Carlo simulation across the full cost and schedule model, producing a distribution rather than a single number, and lets the organization pick a confidence level, commonly the 80th percentile, to size the reserve against. Either way, the number traces back to specific, named risks, which is exactly what a reviewer wants to see.

For management reserve, the defensible method looks different because there's no risk register to derive it from; the reserve exists for what the register can't see. The standard approach sizes it as a percentage of total project budget, commonly landing in the single digits up to around 10 percent, set deliberately by the sponsor or PMO based on the project's overall estimate maturity and the organization's documented risk appetite. What doesn't survive review is picking that percentage after the fact to make a budget balance; the percentage needs to be a stated policy, applied consistently, not a plug figure.

The Two Traps That Break Both Reserves

The first trap is combining them into one line item. Once contingency and management reserve share a single number, nobody can answer "how much of our true contingency is left" without unpacking which withdrawals came from which pot, and PMs under schedule pressure reliably start treating the combined pot as PM-releasable, quietly spending money that should have required a change request.

The second trap is releasing management reserve without updating the baseline. Because management reserve sits outside the cost baseline until it's formally released, skipping that update step means the project's reported baseline understates what's actually been approved, and the next earned value calculation runs against a baseline that no longer matches reality. The same discipline that keeps a schedule buffer separate from the tasks it protects applies here: a reserve only works if its boundary is enforced, not just documented.

Getting the budget-vs-schedule tradeoff right depends on this same discipline, since a PM weighing whether to spend money to protect a date needs to know which pot that money is actually coming from before making the call. For the fuller risk-planning context both reserves sit inside, see the project risk management guide.

What happens next for most PMOs running this split for the first time: audit the current budget for a single merged "contingency/buffer" line, split it into its known-risk and unknown-unknown components using the sizing methods above, and set the release-authority rule (PM for contingency, sponsor for management reserve) in writing before the next reserve gets spent. The rest of the Onplana blog covers the wider PMO practice these two reserves sit inside, from baselines to the risk register they're sized against.