Delayed ERP project: what to do before increasing the budget?

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. Most ERP projects slip at least once. 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. In other words, when a project slips, it is almost never because of the software.

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 go-live date has been pushed back two or more times, each time by less than three months.
• The decision log contains more than ten items that have been open for over thirty days.
• Integrated testing is still uncovering process gaps, not just configuration bugs.
• Data migration has yet to produce a full load validated by business users.
• The rate of approved customizations exceeds 20% of requirements, without any revision to the maintenance budget.
• Business teams have stopped attending workshops or are sending substitutes.
• The integrator is billing for scope changes that the client does not recall approving.

Three or more out of seven signals: the project needs an independent diagnostic, not a new schedule.

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. The budget expands much faster than the schedule because you are buying time with money.

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.

• Continue : the cause is understood, the team can fix it, and the variance is less than 20% of the budget. Stick to the plan, tighten governance, and set a six-week check-in milestone.
• Realign : the cause is understood, but the original scope is no longer viable. Break the project into phases, deliver a core system (finance, procurement, inventory), and defer the rest with a separate budget.
• Freeze : the cause is not understood. Suspend billable work for three to six weeks for an independent diagnostic rather than burning through the budget in the dark.
• Replace the integrator : the cause is understood and relates to the partner's capacity or conduct. Never replace them before securing documentation, ownership of configurations, and a transition plan.

The most expensive reflex is to choose "continue" by default, because it is the option that requires no decision at all.

How do you conduct an ERP project diagnostic in three weeks?

A useful diagnostic takes three weeks and 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.

Typical case, anonymized and simplified: 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.

This recourse becomes justified in three cases: the steering committee can no longer reconcile the versions provided by the integrator and the internal team; the project has exceeded 20% of its budget without a firm delivery date; or the question of replacing the integrator is on the table. In other cases, tightened governance is often enough. Our page on ERP and IT project turnarounds describes what an independent diagnostic produces.

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.

Frequently asked questions about delayed ERP projects

How much delay is acceptable for an ERP project?

A single slip of less than three months on a twelve- to twenty-four-month project is common and can be managed through governance. A second delay, or a delay without a documented cause, warrants a diagnostic. The 2025 Panorama report places the median project duration at nine months; beyond double the initial estimate, the project must be reframed.

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, freezing billable activities for three to six weeks is less expensive than continuing in the dark. 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 typically adds three to six months. In the majority of cases, reframing the scope and governance solves the problem without changing partners.

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. All this in about three weeks, delivered 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.

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.