- Establish causes before adding funding.
- Choose between continuing, reframing, suspending or preparing a transition.
- Base thresholds on actual risks, not an arbitrary score.
- Fund demonstrated and accepted deliverables.
Fictional illustrative situation. The steering committee is meeting for the sixth time this year. The go-live date has been pushed back twice. The integrator talks about "stabilizing requirements," the controller reports a 40% budget overrun, and no one in the room can say what decision would actually move the project forward. This specific moment, before the third budget request, is where a delayed ERP project is either saved or lost.
According to Gartner (Denis Torii, 2024), more than 70% of recently implemented ERP initiatives will not fully achieve their initial business objectives by 2027.
Is a delayed ERP project necessarily a failed one?
No. A delay is a symptom; failure comes from how the organization reacts to it. A delay can remain manageable when its cause and consequences are documented. What distinguishes projects that recover is the speed at which leadership replaces explanations with decisions.
The 2025 ERP Report from Panorama Consulting (172 organizations, data collected from January 2024 to January 2025) reports that more than three-quarters of projects met their planned schedule and that the most common cause of delays was data quality. This survey does not establish the cause of your project’s delay; it supports checking data readiness among other factors.
At PlanAxion, the projects we take over share one trait: the delay had been known for months, but no one had the mandate to name it and make a decision based on it. The schedule had been rewritten three times without a single initial assumption being challenged.
What signs indicate that a delayed ERP project is truly spiraling out of control?
Seven field signals warn of a drift before it shows up in the budget. They are found in the day-to-day reality of the project, not in the monthly report.
- The production date keeps moving without a documented critical-path explanation.
- Blocking decisions remain open without an owner or due date.
- Integrated testing is still uncovering process gaps, not just configuration bugs.
- Data migration has yet to produce a full load validated by business users.
- Customizations increase without revisiting test effort and support costs.
- Business teams have stopped attending workshops or are sending substitutes.
- The integrator is billing for scope changes that the client does not recall approving.
These signals are a checklist, not a validated predictive score. A single critical issue can justify a diagnostic; no count replaces an impact assessment.
Why does adding budget to a delayed ERP project often make the problem worse?
Because the budget funds the same causes that produced the delay in the first place. Without a diagnostic, new money pays for additional integrator hours on a scope that hasn't been finalized and data that hasn't been cleaned.
The study by McKinsey and the University of Oxford (2012) on large IT projects already measured this: on average, these projects exceed their budget by 45% and their schedule by 7%, while delivering 56% less value than expected. This older study concerns large IT projects initially exceeding $15 million; its averages do not predict the outcome of a Quebec SME ERP implementation.
Panorama makes the same observation in 2025: the primary cause of budget overruns is the unforeseen need for additional technology, discovered along the way. This is not a money problem. It is a scoping problem that is being addressed with money.
What decision should you make when an ERP project is behind schedule: continue, realign, freeze, or replace?
There are four options, and the right one depends on two questions: is the cause of the delay understood, and can the current team fix it? Here is the matrix we use for diagnostics.
| Option | Condition | Evidence before commitment |
|---|---|---|
| Continue | Cause understood, capacity available and risks accepted | Demonstrated blocked deliverable, named owner and dated checkpoint |
| Reframe | Original scope is no longer viable; a coherent release remains possible | Approved reduced scope, dependencies and deferred costs |
| Suspend selected work | Cause unknown or work lacks verifiable deliverables | Suspended work identified, critical activities protected and diagnostic commissioned |
| Prepare a transition | Partner capacity or conduct prevents recovery | Access, documentation, contractual rights and replacement team secured |
The most expensive reflex is to choose "continue" by default, because it is the option that requires no decision at all.
How should an ERP project diagnostic be organized?
A diagnostic can be organized over three weeks when documents and decision-makers are available. It answers five questions: where is the project really, why did it drift, what is blocking the critical path, which decisions are pending, and what is needed to deliver. It doesn't rewrite the plan; it gives management the information needed to make a call.
Week 1: Fact-finding. Signed scope versus delivered scope, change log, actual status of testing and migration, open decisions, and their owners. Week 2: Interviews with business leaders, the project team, and the integrator, separately. The discrepancies between the three accounts are the diagnostic. Week 3: Costed scenarios for the four options, with the decisions to be made and their deadlines.
An ERP project isn't turned around by adding more hours. It is turned around when every decision has an owner and a date.
Fictional teaching scenario, without an attested client outcome: a multi-site Quebec distributor, four warehouses, mid-market ERP, go-live pushed back twice. The diagnostic compared the contractual scope with the actual configured processes: the integrator had set up goods receipt for only one warehouse, while the contract covered four. No one had compared the two documents. Once the gap was on the table, the steering committee decided in one meeting: realign into two phases, deliver finance and procurement on schedule, and defer multi-site logistics with its own budget.
When should you bring in an independent third party to turn around an ERP project?
When neither the integrator nor the internal team can provide a neutral assessment of the project. The integrator defends their method and hours; the internal team defends the plan they approved. A third party that sells neither licenses nor integration hours has nothing to protect except the client's decision.
Panorama notes in 2025 that only 25.3% of organizations sought support for contract negotiation, even though that is precisely where the rules of the game are set in case of drift: responsibilities, penalties, and ownership of deliverables. A project whose contract does not account for drift is harder to turn around.
Independent input is useful when facts remain disputed, tests do not demonstrate operational readiness or a partner transition is under consideration. An ERP audit establishes the diagnostic; project recovery then organizes execution of the restart.
What should you remember when an ERP project is behind schedule?
Name the delay, understand its cause, choose one of the four options, and give every decision a date. The budget comes after, never before. The articles on the actual cost of an ERP implementation in Quebec and on the average duration of an ERP implementation provide benchmarks to judge the variance; the one on the conflict of interest of the certified integrator explains why the delivery partner cannot be the one judging the project.
What criteria should release the next recovery budget?
The steering committee can fund a tranche linked to evidence rather than hours without defined outcomes. Adapt these proposed governance criteria to the contract.
- An approved baseline: remaining scope, committed spending, forecast cost to complete and schedule.
- A critical dependency resolved through a demonstrated deliverable.
- Reconciled data accepted by its owner.
- Passed critical business scenarios and classified residual defects.
- An owner for every decision and an approved change register.
Recovery example for a Quebec distributor
Fictional scenario. A 120-employee distributor can invoice, but multi-site receiving fails in testing. Separate working processes from blockers: opening stock, transfers, receipts and warehouse availability. Further funding can depend on demonstrated receiving and transfers with inventory reconciliation. Deferring a function also requires pricing the temporary process.
If deployment is imminent, protect operations before reorganizing the engagement: escalation contacts, backups, access, open orders and rollback decisions. Client-side ERP governance must identify who may approve or stop cutover.
Frequently asked questions about delayed ERP projects
How much delay is acceptable for an ERP project?
There is no universally acceptable delay. Assess operational, contractual, cash-flow and staffing consequences. An explained delay with verifiable recovery evidence differs from a date pushed back without proof. Have the steering committee approve a new baseline.
Should you stop a delayed ERP project to conduct a diagnostic?
Not always. If the cause of the delay is understood, the diagnostic can be conducted in parallel with the work. If it is not, suspending non-critical work can limit exposure during the diagnostic; also assess suspension costs and contractual obligations. The decision to freeze belongs to the steering committee, not the integrator.
When should you replace your ERP integrator?
Only when the cause of the delay stems from the partner's capacity or conduct, and never before securing the documentation, ownership of configurations, and a transition plan. A poorly prepared replacement can delay the project further; estimate timing from the actual transition requirements. First assess whether reframing scope and governance allows recovery with the current partner.
What does an independent ERP project diagnostic produce?
A real-time status of the project (scope, testing, data, open decisions), an explanation of the causes of drift, a list of dependencies blocking the critical path, a decision log with owners and deadlines, and costed scenarios to continue, reframe, freeze, or replace. Agree timing based on scope and access to evidence, with delivery to the steering committee.
Who should lead the recovery of an ERP project?
A client-side lead with the authority to decide on scope and budget, supported by a steering committee that meets weekly during the stabilization phase. The integrator executes; they do not lead. An independent third party can structure the diagnostic and the pace of decisions without replacing management.
Which indicator matters more than billed hours?
Track demonstrated and accepted critical processes, blocking defects, reconciled data and decisions that free the critical path. Hours explain spending; they do not prove that the system can support operations.
Before adding budget: an independent ERP audit helps establish gaps, responsibilities, and the decisions that need to be made. If the diagnostic confirms structural drift, then explore our approach to project recovery and client-side ERP governance.
Read next: if the project needs an outside perspective, see how an ERP consultant in Montreal can represent your interests with the integrator.
- Gartner, Denis Torii, What IT Leaders Must Do to Avoid Disappointing ERP Initiatives, 2024.
- Panorama Consulting Group, The 2025 ERP Report, 2025.
- McKinsey & Company and University of Oxford, Delivering large-scale IT projects on time, on budget, and on value, 2012.
