Blog
8 min read
Contingency is money you hold against delivery risks that may or may not happen. Ask three partners how much contingency to add to an implementation project estimate and you will get three percentages. Fifteen. Twenty. Twenty-five if the client is new and the system you are replacing is old.
None of them can show the working. In construction estimating, a percentage on a base cost is documented practice, and it is pegged to how much of the design is settled. The software version has the habit without the reasoning.
There is a better answer, and it is not a different percentage. It is a list.
Price every delivery risk you have logged, then total them. That total is your contingency. Whatever percentage it comes to is an output, not an input.
This is the expected value method, and it is not new. Project Control Academy sets it out as one of the standard cost contingency calculation approaches, alongside percentage uplifts and Monte Carlo simulation. Probability multiplied by cost impact, summed across the register. The mechanics take an afternoon to learn.
What makes it work on an implementation job is that the risks are already knowable. You have read the client's architecture diagram, and you know which of the four integrations has no test environment.
Here is what that looks like on a 400-hour deployment:
| Logged risk | Hours if it happens | Likelihood | Allowance |
|---|---|---|---|
| Legacy CRM API documentation is wrong | 40 | High | 30 |
| Client data extract needs manual cleansing | 24 | Even | 12 |
| A second identity provider surfaces late | 16 | Low | 4 |
| Sign-off spans three departments, not one | 12 | Even | 6 |
Fifty-two hours of contingency. On a 400-hour base, thirteen per cent. Unremarkable as a number. The difference is that you can point at every hour of it and say where it came from.
Now the client asks why the price is what it is. You have four sentences ready instead of a shrug. That conversation is also the one that stops quotes going over budget. Assumptions get tested before anyone signs, not discovered in week three.
Because it is fast, and because a defensible version of it exists.
The percentage method is real estimating practice. It tracks how much you know, and it falls as the design firms up. Construction estimators publish phase-based contingency bands that do exactly that. From 20 to 25% at concept, down to 10 to 15% at design development, and 3 to 5% once building is under way. Class-based estimate ranges in the cost engineering literature work on the same principle.
Read those bands again and the problem with the software version becomes obvious. Every one of those numbers is tied to a stated level of design maturity. The 15% on your proposal is tied to nothing.
So the flat uplift is not wrong because percentages are wrong. It is wrong because nothing underneath it moves when your certainty moves. Nothing to release, nothing to defend.
Anything with a named trigger and an hours figure attached to it. If you cannot write the sentence "if this turns out to be true, it costs us that many hours", you have not logged a risk. You have logged a worry.
That test removes most of what ends up on a register. "Client may be slow to respond" fails it. Nothing to act on. "Sign-off needs the finance director, who is away until the 22nd, so allow two weeks of holding cost" passes, because someone can put a date and a cost against it.
Four families cover most implementation work:
Every entry wants a trigger, an hours impact and a rough likelihood. Precision is not the point here. A risk sized to the nearest half-day beats a risk nobody sized at all, and sizing it is what prompts the clarifying question that removes it.
No. Contingency covers risks that may not happen. Margin covers the risk you have already taken on by fixing the price at all.
That second one is easy to miss because it never appears on a register. The moment you quote a fixed price, you have accepted every overrun above your buffer. A guide for agency buyers puts it plainly: fixed-price quotes transfer risk to the agency, and its worked example puts the buffer inside a £30,000 build at £4,000 to £6,000. That transfer has a price. The price is margin.
Three separate lines, then:
Collapse contingency and margin into one number and you can no longer tell two stories apart. A job that hit its target because no risk landed is not the same as a job that was priced well. One is luck. The other repeats.
The distinction matters most on the jobs that go badly. When a blended 25% buffer is exhausted, all anyone can say afterwards is that the project overran. Split the lines and the post mortem gets sharper. Either the risks were priced correctly and the base estimate was light, or the base was fine and a risk landed at triple its allowance. Different fixes, and only one of them is about contingency.
It goes back to margin. An unused allowance is money you earned by pricing a risk correctly. Not a budget for work nobody logged.
This is where most contingency quietly disappears. The legacy API turns out to be documented properly, thirty hours come free, and the client mentions a reporting tweak in the same week. Nobody connects the two decisions. The hours get spent, the margin looks normal, and a good estimate never gets the credit.
Construction has a firmer convention here. The same estimating guidance recommends logging every contingency drawdown with a date, a reason and a running balance. It also says the fund should not absorb costs caused by poor planning. Those belong in a change order.
Your version of that discipline is a change request process for fixed price projects that runs beside the risk register. One question settles most cases. Was this event on the register? If not, it is a change request, whatever the contingency balance says.
Release should also need authority. A delivery lead under pressure will always find a use for spare hours. So name the person who signs contingency out in the statement of work, exactly as you would for any other spend.
Yes. Every risk that closes should release its allowance, because certainty rises as delivery progresses and the register gets shorter.
Run the review weekly. It takes ten minutes and it is the same conversation each time: which risks closed, which grew, which arrived. The API documentation checked out in week two, so strike the line and release the thirty hours; the data extract turned out worse than expected, so raise that allowance and note why.
By the halfway point a well-run implementation should be carrying far less contingency than it started with. Still sitting at the opening figure in week eight? The register is decorative.
That falling curve is also the cheapest estimating feedback you will ever get. A risk that never once materialised across nine projects is not a risk. It is a habit, and it has been quietly inflating your prices against competitors who dropped it years ago.
From the jobs you have already finished. That is the only source that reflects how your team delivers.
Korrel records delivery risks against a proposal, each with a suggested allowance and a derived severity, and estimate components can be linked back to the risk that justifies them. The estimate then carries labour, contingency, overhead and margin as separate lines rather than one blended figure. Nothing is applied automatically. The allowance is yours to set and review, because the judgement about a specific client's legacy system is not one software should be making for you.
The payoff shows up later, in Estimate Accuracy analytics and in knowing which implementation projects are actually profitable once the real hours land. Bias by cost category is the number to watch. If your integration estimates run 20% light every time, no contingency percentage fixes that. Pricing the risks one by one is what makes the pattern visible.
Start with the next proposal that leaves your desk. Write the risks down, put hours and a likelihood against each, and total them. Then compare the percentage that falls out with the one you would have written by reflex. Where the two disagree, trust the register. The gap between them is the argument for the estimating discipline that produced it.
COMMON QUESTIONS:
RELATED READING:
Three piles: what you price firm, what you price with a stated allowance, and what you refuse to price until the client answers. And how to write each into the quote.
The single-project sum takes a minute. The version that matters is the roll-up, where a handful of underwater jobs hide inside a perfectly healthy blended number.
Quotes go over budget because they were priced from memory. The fix is a diagnostic: ten finished jobs, quoted against actual, and the pattern that survives all ten.
Korrel turns briefs into structured proposals, then tracks what each job actually costs.
START FREE TRIAL