ERP budget and schedule overruns: causes, warning signs and contingency

ERP implementations commonly cost more and take longer than the first plan. Industry surveys report this often, but their methods and samples differ so much that no single percentage is reliable, so the practical approach is to assume an overrun is possible and design for it: hold a contingency of budget and time, control scope changes formally, track the partner's hours weekly against the estimate, and make the internal effort visible. This guide explains where overruns come from and how to contain them.

It is part of the failure patterns and official sources pillar. Amounts are illustrative.

Where the extra cost comes from

Source	How it shows up	Typical trigger
Scope growth	Change requests, new reports, extra integrations	Requirements discovered during build
Customisation	Custom code to replicate old processes	Reluctance to change how things are done
Data problems	Extra test loads, manual clean-up, delayed cut-over	Duplicates, missing costs, inconsistent units
Integration issues	Another vendor's API limits or delays	Connector not ready, unclear ownership
Internal capacity	Workshops postponed, testing late	Key users doing two jobs
Rework after testing	Fixes and retests	Testing started late or too narrow
Extended hypercare	Partner support after go-live	First month-end close problems
Paying for two systems	Old licences kept, new subscription started	Go-live delay

Warning signs to watch weekly

Hours burned versus progress: the partner has used 60% of the estimate but configuration is 40% complete.
Open decisions: a growing list of design questions awaiting sign-off.
Change requests: several approved in the first month of build.
Data test loads failing reconciliation.
Testing dates moving while the go-live date does not.
Key users missing sessions.

Ask the partner for a weekly report: hours used by phase, estimate to complete, open risks, open decisions and change requests. If you are on time and materials, this report is your main control.

Contingency: how much and how to hold it

There is no standard contingency. Many buyers hold 10% to 25% of the one-time project budget, more for time-and-materials work, complex inventory or manufacturing, poor data quality or many integrations. Hold contingency as a separate line approved by the owner or sponsor, not hidden in the partner's estimate, and release it only through the change process.

Illustrative example. One-time costs are budgeted at $150,000: $95,000 partner fees, $20,000 integrations, $10,000 training and $25,000 internal time. The business holds 20% contingency: $30,000. During build, three change requests are approved for $8,500, a third data test load costs $4,000, and hypercare is extended by two weeks for $5,500. Total drawn: $18,000, leaving $12,000. Without the contingency line, the same events would have looked like a 12% overrun ($18,000 ÷ $150,000) and caused a crisis meeting; with it, they are planned spending.

Time contingency matters as much: a plan with no slack between user-acceptance testing and go-live will either slip or go live untested.

Controlling change requests

Every change request states the business reason, the cost, the effect on the timeline and the effect on future upgrades.
A small group (sponsor, project lead, finance) approves or rejects each one.
Ask "can we change the process instead of the system?" first.
Park nice-to-have changes in a phase 2 list to revisit after the system is stable.
For fixed-fee contracts, check that the change-request rate is agreed in the statement of work.

Making internal effort visible

Internal time is the overrun nobody invoices. Track hours spent by your staff on the project, and price them at a loaded hourly rate. If the controller spends 15 hours a week for six months, that is around 390 hours; at an illustrative $60 loaded rate, about $23,400. If that time was not budgeted, the business pays for it in overtime, delayed work or temporary staff. Include it in the five-year TCO.

How an overrun changes the business case

Rerun the payback with the actual cost. Using the payback calculator: a project budgeted at $120,000 with a net yearly saving of $40,000 pays back in about 2.9 years. If it costs $150,000 and savings start six months late, payback moves to roughly four years or more. Seeing this early helps decide whether to cut scope or accept the delay. See the payback worked example.

Contract protections that limit overrun exposure

Protection	Effect
Fixed fee for well-defined phases	Partner carries estimate risk for that scope
Not-to-exceed cap on time and materials	Spending beyond the cap needs your written approval
Milestone payments tied to acceptance	You pay for delivered results, not elapsed time
Holdback until final acceptance	Keeps the partner engaged through hypercare
Subscription start aligned with go-live	Reduces paying for an unused system
Clear assumptions on your responsibilities	Reduces disputes about who caused a delay

Review contract terms on exit and data export at the same time.

FAQ

Is a fixed-fee implementation overrun-proof?

No. It protects the partner's hours within scope, but scope changes, data problems and your own internal time still add cost.

Should we stop a project that is overrunning?

Stopping writes off what was spent. First check whether a smaller phase 1 can go live on time, with the rest deferred.

Who pays for delays caused by the vendor?

That depends on the contract. Document causes of delay as they happen; it matters if there is a dispute.

Can we claim overrun costs as a tax deduction?

How project costs are treated for tax depends on their nature; ask your accountant.

Sources

Business Development Bank of Canada (BDC) — technology project planning resources
Innovation, Science and Economic Development Canada — small business resources
Canada Revenue Agency — treatment of business expenses