# How much contingency to add to an implementation project estimate Source: https://korrel.ai/blog/contingency-implementation-project-estimate Published: 2026-08-11 Updated: 2026-08-10 Topic: how much contingency to add to an implementation project estimate Tags: estimating, project-costs --- ## Key points - Contingency should be the sum of individually priced delivery risks, not a flat percentage applied by habit. - A flat uplift cannot be defended to a client, adjusted mid-project or released when a risk closes. - Margin is the return for carrying a fixed price, not a buffer against named delivery risks. - An unused allowance belongs in margin, not in unlogged extra work nobody priced. - Contingency should fall through delivery as unknowns close, which a single blended percentage cannot do. 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. ## How much contingency to add to an implementation project estimate? 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](https://www.projectcontrolacademy.com/cost-contingency-calculation/), 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](/blog/why-quotes-go-over-budget). Assumptions get tested before anyone signs, not discovered in week three. ## Why the flat percentage survives 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](https://www.smaestimating.com/how-to-calculate-construction-contingency-costs/) 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. ## What belongs on an implementation risk register? 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: - **Source system unknowns.** Undocumented APIs, data quality nobody has profiled, integrations with no test environment. - **Client-side dependencies.** Sign-off chains, extracts owed to you, third-party vendors outside your control. - **Scope edges.** Requirements marked as assumed rather than confirmed, where being wrong has a price. - **Delivery capacity.** A named specialist you need for a fortnight who is already committed elsewhere. 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. ## Is contingency the same thing as margin? 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](https://commissioningdesk.com/why-agency-quotes-vary-so-much/), 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: - **Base cost.** The hours and fixed costs you expect to spend if nothing surprises you. - **Contingency.** A priced allowance against named risks, each one traceable to a register entry. - **Margin.** What the business earns for carrying the fixed price, before any risk occurs at all. 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. ## What happens when a risk does not materialise? 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](/blog/change-request-process-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. ## Should contingency shrink as the project runs? 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. ## Where the next estimate gets its numbers 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](/blog/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](/blog/topics/estimating) that produced it. ## Common questions ### Is 15% contingency enough for a software implementation? There is no way to answer that without seeing the risk register. Fifteen per cent is generous on a repeat integration you have shipped nine times, and thin on a first migration off an undocumented legacy system. Price the specific risks, total them, and compare the resulting percentage against your last few jobs of similar shape. ### What is the difference between contingency and margin? Contingency covers named risks that may or may not happen. Margin is what the business earns for accepting the fixed price in the first place. They behave differently: contingency is released or spent against specific events, while margin is the return you are targeting whatever those events do. Folding them into one buffer hides which one you got wrong. ### Who should own the contingency on a fixed-price project? The commercial owner of the project, not the delivery lead. Release should need the same authority as any other budget decision, because a delivery lead under pressure will always find a use for spare hours. Name the authoriser in the statement of work and log every drawdown with a date and a reason. ### Should contingency appear as a visible line in the client quote? That is a commercial choice, and both answers are defensible. Showing it invites a negotiation about a number the client cannot evaluate. Hiding it means the client reads your contingency as scope and expects to consume it. Folding contingency into deliverable prices while keeping the risk register visible shares the reasoning without exposing the arithmetic.