ERP projects often run over budget, even with strong planning and due diligence. Unexpected issues emerge, scope changes, integrations become more complex, data migration takes longer than expected, and change management requires more effort than originally assumed. This is why every ERP project needs a real contingency budget. But contingency is often misunderstood. It should not be a catchall for poor planning, scope expansion, or predictable work that was left out of the original budget. It should be a disciplined buffer for unknown and unforeseen issues that arise during implementation. This post explains how to define, manage, and protect an ERP contingency budget the right way.
Why ERP Contingency Budgets Matter
ERP and digital transformation projects are moving targets. Requirements evolve, operational realities surface, integration issues appear, and project teams discover complexity that was not visible during initial planning. Even when the project is well run, surprises happen.
A contingency budget helps protect the project from those surprises. It gives leadership a realistic financial cushion, reduces panic when unexpected issues arise, and allows the project team to solve problems without turning every issue into a budget crisis.
In our experience, projects without adequate contingency do not actually cost less. They simply push unavoidable costs into crisis mode, where decisions are made under pressure and usually become more expensive. A contingency budget is not a sign of weak planning. It is a sign of mature planning.
Contingency Is Only for Unknown and Unforeseen Factors
The most important rule is this: contingency should only be used for unknown and unforeseen factors.
If you think you may need customization, that should be a specific line item in the project budget. If you think you may need custom training materials, that should be a specific line item. If you know organizational change management will be required, that should be budgeted directly, not treated as a contingency item.
Contingency should be reserved for things like:
- Unexpected technical roadblocks
- Unforeseen integration complexity
- Data issues that were not visible during initial assessment
- Additional testing cycles caused by legitimate defects
- Operational interruptions that require unplanned mitigation work
Known risks belong in the budget. Unknown risks belong in contingency. Mixing the two creates confusion and makes it impossible to manage the project properly.
Contingency Does Not Cover Scope Expansion
Contingency is not a funding source for scope expansion. If the organization decides to add a functional area, deploy an additional module, or expand the project into a business unit that was not originally included, the overall project budget and timeline need to be modified through governance.
This is normal in ERP programs. Scope often changes as the organization learns more. But those changes need formal approval and a new budget. They should not quietly consume contingency funds.
Using contingency for scope expansion is dangerous because it leaves the project exposed when genuine unforeseen issues occur later. It also masks the true cost of business decisions and weakens accountability. A strong ERP selection and implementation governance model should clearly distinguish between contingency use and scope change approval.
Most Contingency Budgets Are Too Small
Most organizations underestimate the contingency required for a major ERP project. Depending on the scope and risk profile, we typically recommend 15 to 20% of the total project budget.
For example:
- If your estimated project budget is $5 million, a 20% contingency means seeking approval for $6 million.
- If your estimated project budget is $10 million, a 20% contingency means seeking approval for $12 million.
- If your estimated project budget is $25 million, a 20% contingency means seeking approval for $30 million.
The exact percentage depends on the complexity of the project. Higher risk projects may need more. Lower risk, narrower scope projects may need less. But for most meaningful ERP transformations, anything below 10% is usually insufficient.
A realistic contingency should be built into the approved budget before the project begins, not requested only after problems have already surfaced.
Contingency Percentages Should Move With Project Changes
If the project scope or budget changes, the contingency should change too. Contingency is a percentage of total project risk, not a fixed number that remains unchanged no matter how the project evolves.
If you add $500,000 of approved work and are maintaining a 20% contingency, you should request $600,000 in total budget authority for that change: $500,000 for the work and $100,000 for the added contingency.
This matters because every new workstream brings new risk. If the contingency does not scale with the project, the project becomes underprotected as scope grows.
Contingency Can and Should Be Used Carefully
Contingency is not something to be hoarded irrationally. If a genuinely unforeseen issue emerges, the contingency budget exists to address it. The key is disciplined approval and tracking.
Every use of contingency should document:
- What issue triggered the need
- Why the issue was unforeseen
- What alternatives were considered
- How much contingency is being used
- How much contingency remains
- Whether the risk profile of the project has changed
If the contingency budget is mostly spent in the first few months of the project, that is a red flag. It may indicate that the budget was not realistic, the project was poorly scoped, or contingency is being used for work that should have been planned directly. In that case, leadership should pause and reassess the full project budget rather than continuing as if nothing has changed.
The Goal Is Not to Use the Contingency Budget
The best outcome is to complete the project without using the full contingency. With strong planning, effective governance, disciplined change management, and careful risk management, it is possible to finish with contingency funds remaining.
That should be the goal. But planning for that outcome without funding contingency is unrealistic.
Think of contingency as insurance. You hope not to use it, but the existence of the buffer protects the organization from panic decisions when unexpected events occur.
Contingency Is Not Just for Dollars
ERP contingency is not only financial. Project timelines need contingency too.
Timeline buffers should account for:
- Unexpected defects during testing
- Key resource illness or turnover
- Vacations and holidays
- Weather or facility disruptions
- Vendor delays
- Late data migration issues
- Additional training or readiness work
Organizations often treat the timeline as if everything will go perfectly. It almost never does. A realistic timeline includes buffers for the same reason a realistic budget includes contingency: because uncertainty is part of every major transformation.
How Phase Zero Helps Control ERP Contingency
The best way to define a realistic contingency budget is to do better planning before the implementation begins. Phase Zero gives the organization the opportunity to identify risks, validate assumptions, define scope, and create a more credible budget before major project spend begins.
During Phase Zero, organizations should assess:
- Business process readiness
- Data migration complexity
- Integration scope
- Organizational change impact
- Internal resource availability
- Vendor estimate assumptions
- Testing and go-live readiness criteria
The Phase Zero Planning Checklist gives organizations a structured way to identify these risks early. Better Phase Zero work does not eliminate the need for contingency, but it makes the contingency more accurate and defensible.
The Role of Change Management in Contingency
Organizational change management should never be funded from contingency if you already know the organization will need it. Change management is a predictable requirement in any ERP project, not an unforeseen event.
However, change management can affect contingency in two ways. First, underfunded change management often causes issues that later consume contingency: delayed adoption, extra training cycles, resistance, and productivity loss. Second, a strong change management program can reduce the likelihood that contingency is needed by improving readiness and reducing disruption.
This is why organizational change management should be directly budgeted and properly resourced from the start.
Questions We Hear Most
How Much Contingency Should an ERP Project Have?
For most ERP projects, 15 to 20% of the total project budget is a reasonable starting point. Larger, more complex, higher risk projects may require more. Smaller or narrower scope projects may require less. The right percentage depends on the quality of planning, the complexity of integrations, the maturity of the organization, and the amount of unknown risk remaining after Phase Zero.
Who Should Approve Use of the Contingency Budget?
Contingency use should be governed by the steering committee or another defined governance body. The project manager should not have unilateral authority to spend contingency. Every use should be documented and approved based on whether the issue is truly unforeseen, whether the proposed response is necessary, and how much contingency remains.
What Happens If the Contingency Budget Runs Out?
If contingency runs out early, the organization should pause and reassess the entire budget, scope, and risk profile. Continuing without a contingency buffer leaves the project exposed and usually leads to reactive decisions. Running out of contingency is often a sign that the original budget was incomplete, the scope expanded without proper approval, or known costs were incorrectly charged against contingency.
If you are defining your ERP contingency budget and want an independent view of whether it is realistic, contact us at eric.kimberling@thirdstage-consulting.com.
