Treat cost as a lifecycle decision

Contingency in a software project is money set aside for costs that cannot be precisely predicted at the outset. Unlike a marketing website where the scope tends to be visible upfront, a web application, CRM system or legacy modernisation project involves integrations, data structures and process logic that only reveal their full complexity once work is underway. Contingency exists to absorb that residual uncertainty without forcing the project to a halt.

The first distinction to understand is the difference between a risk buffer and a scope buffer. A risk buffer covers things going wrong with work that was agreed: an API behaves differently from its documentation, a legacy database contains unexpected data formats, or a third-party service changes its authentication method. A scope buffer covers the business deciding it wants additional features partway through. These are fundamentally different, and conflating them is a common source of dispute.

Contingency sizing should follow from the level of discovery completed before the build begins. A project that has gone through a thorough discovery phase—processes mapped, integrations tested at a technical level, data structures audited—carries less unknown risk than one moving straight from a conversation to a build. The appropriate contingency figure is not a fixed percentage; it reflects the remaining gaps in knowledge. A well-discovered system might warrant a smaller reserve, whereas a project proceeding on assumptions alone needs a larger one.

Contract structure affects how contingency is handled. Under a fixed-price arrangement, the supplier typically absorbs some risk into their margin, which means the client's contingency may be lower but the headline price higher. Under time-and-materials, the client carries more of the risk directly, making an explicit contingency reserve more important. Neither model eliminates the need for contingency—it simply shifts where it sits and who controls it.

Legacy system modernisation

Replacing or modernising a legacy system carries particular uncertainty because the existing codebase and data are often poorly documented. Even after an audit, surprises can emerge during migration: business logic embedded in stored procedures, hardcoded references to specific server paths, or data relationships that were never formally modelled. Contingency here needs to cover the possibility that the extraction and transformation work takes longer than initial sampling suggests.

Integration-heavy projects

A customer portal that connects to an existing CRM, billing platform and document storage system depends on the behaviour and stability of those external services. If an API has undocumented rate limits, returns errors under specific conditions, or requires an unexpected approval process for production access, the integration work expands. Contingency for integration-heavy projects should be considered separately from the core application build, because the risk profile is distinct.

Regulatory or compliance requirements

When a system must meet specific security standards, data-handling rules or accessibility requirements, the gap between initial interpretation and formal assessment can be costly. A security review might identify changes to session handling, logging or data encryption that were not anticipated. Contingency should account for the possibility that compliance verification produces a remediation list.

Who controls the contingency

A practical question that is often left vague: who decides when contingency funds are spent? If the supplier controls the reserve, the client may not have visibility until the money is gone. If the client controls it, there needs to be a clear process for the supplier to request access, with criteria that prevent delays when genuine issues arise. The contract should specify how contingency is released, what evidence is required, and what happens to unused funds at the end of the project.

Tracking contingency spend

Contingency should not be an opaque pot of money. Each draw against it should be recorded against a specific risk event, with a note on what occurred, what it cost and whether the remaining contingency needs to be reassessed. This creates an audit trail and, equally importantly, builds organisational knowledge for future projects.

Applying a blanket percentage

Setting contingency at a flat percentage of the build cost—say 15% or 20%—is common but rarely accurate. A small project with one integration and clear requirements may need less. A large project touching multiple legacy systems may need more. The percentage should be a starting point for a conversation, not a substitute for identifying what is actually uncertain.

Using contingency to fund scope changes

If the business decides midway through a build that it wants an additional reporting module, that is a scope change, not a contingency event. Paying for it from the contingency reserve depletes the buffer meant for genuine unknowns. Scope changes should be estimated and approved separately, with their own budgetary treatment.

Accepting hidden contingency in line items

Some suppliers build risk padding into individual line items rather than declaring a separate contingency figure. This makes the quote appear more precise than it is and reduces the client's ability to see where assumptions have been made. When reviewing a quote, it is reasonable to ask whether any line item includes a risk allowance and, if so, what specific risk it covers.

Not revisiting contingency as discovery progresses

Contingency set at the start of a project should be revisited as discovery work reduces uncertainty. If a technical spike confirms that an integration is straightforward, the associated risk portion of the contingency can be reduced—or reallocated to a different area where uncertainty has increased. Treating the initial figure as fixed throughout the project ignores the information gained along the way.

Leaving unspent contingency unexamined

If a project finishes with a large portion of its contingency untouched, that does not necessarily mean the budgeting was wasteful. It may mean the discovery phase was effective and risks did not materialise. However, it is worth understanding why: were the initial risks overestimated, or did the team simply avoid triggering them? That understanding informs better budgeting on the next project.

Key checks before agreeing a contingency approach

  • Is the contingency figure linked to specific identified risks, or is it a general allowance?
  • Does the contract distinguish between contingency for agreed scope and budget for scope changes?
  • Who authorises release of contingency funds, and what information must they receive first?
  • How will contingency spend be reported during the project?
  • What happens to unused contingency at project completion?
  • Does the supplier's quote include hidden risk allowances within line items?
  • Is there a mechanism to adjust the contingency figure as discovery reduces uncertainty?

Keep the estimate reviewable

Contingency budgeting is not an admission that the project is poorly defined. It is a recognition that software development involves interacting with systems, data and regulations that do not always behave as expected. The aim is to ensure that when something unforeseen occurs, the response is a measured decision rather than a crisis.