Late ERP project: what to do before adding budget

The steering committee is meeting for the sixth time this year. The go-live date has moved twice. The integrator talks about “stabilizing requirements,” the controller talks about a 40 percent overrun, and nobody in the room can name the decision that would move the project forward. That moment, right before the third budget request, is where a late ERP project is saved or lost.

According to Gartner (Denis Torii, 2024), more than 70 percent of recently implemented ERP initiatives will fail to fully meet their original business goals by 2027.

Is a late ERP project necessarily a failed project?

No. A delay is a symptom; failure comes from how the organization responds to it. Most ERP projects slip at least once. What separates the ones that recover is how quickly leadership replaces explanations with decisions.

Panorama Consulting’s 2025 ERP Report (172 organizations, data collected January 2024 to January 2025) found that more than three quarters of projects finished within the expected timeline, and that the most common cause of schedule overruns was data issues. When a project slips, the software is almost never the reason.

In the troubled projects PlanAxion is asked to review, one trait keeps coming back: the delay had been known for months, but nobody had the mandate to name it and turn it into a decision. The schedule had been rewritten three times without a single starting assumption being challenged.

Which signals show that a late ERP project is really going off the rails?

Seven field signals announce the drift before it shows up in the budget. They are visible in the project’s daily life, 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 holds more than ten decisions that have been open for over thirty days.
• Integration testing is still uncovering process gaps, not just configuration defects.
• Data migration has not yet produced a full load validated by business users.
• Approved customizations exceed 20 percent of requirements, with no revision of the maintenance budget.
• Business teams have stopped attending workshops, or send substitutes.
• The integrator is billing scope changes the client does not remember approving.

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

Why does adding budget to a late ERP project often make things worse?

Because the new money funds the same causes that produced the delay. Without a diagnostic, fresh budget pays for more integrator hours on a scope that was never settled and data that was never cleaned.

The McKinsey and University of Oxford study (2012) of large IT projects measured it: on average these projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Budgets inflate far faster than schedules, because organizations buy time with money.

Panorama makes the same observation in 2025: the leading cause of budget overruns is the unexpected need for additional technology, discovered mid-project. That is not a money problem. It is a scoping problem being settled with money.

What should you decide about a late ERP project: continue, rescope, 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? This is the matrix we use in a diagnostic.

• Continue: the cause is understood, the team can fix it, and the gap is under 20 percent of budget. Keep the plan, tighten governance, set a control milestone at six weeks.
• Rescope: the cause is understood, but the original scope no longer holds. Split into phases, deliver a core (finance, procurement, inventory) and defer the rest under a separate budget.
• Freeze: the cause is not understood. Suspend billable work for three to six weeks for an independent diagnostic, rather than burning budget in the dark.
• Replace the integrator: the cause is understood and it lies in the partner’s capacity or conduct. Never replace before securing documentation, ownership of configurations and a transition plan.

The most expensive reflex is choosing “continue” by default, because it is the one option that requires no decision.

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

A useful diagnostic fits in three weeks and answers five questions: where the project really stands, why it drifted, what is blocking the critical path, which decisions are pending, and what it would take to deliver. It does not rewrite the plan; it gives leadership what it needs to decide.

Week 1: read the facts. Signed scope against delivered scope, change log, real status of testing and migration, open decisions and their owners. Week 2: interview business leads, the project team and the integrator, separately. The gaps between the three accounts are the diagnostic. Week 3: costed scenarios for the four options, with the decisions required and their deadlines.

An ERP project does not recover with more hours. It recovers when every decision gets an owner and a date again.

A typical case, anonymized and simplified: a Quebec multi-site distributor, four warehouses, a mid-tier ERP, a go-live pushed back twice. The diagnostic compared the contractual scope with the processes actually configured: the integrator had set up goods receiving for a single warehouse, while the contract covered four. Nobody had compared the two documents. Once the gap was on the table, the steering committee decided in one meeting: rescope in two phases, deliver finance and procurement on the planned date, and defer multi-site logistics under its own budget.

When should you bring in an independent third party to recover an ERP project?

When neither the integrator nor the internal team can form a neutral judgment on the project. The integrator defends its method and its hours; the internal team defends the plan it 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 percent of organizations sought guidance for contract negotiation, even though that is exactly where the rules for a troubled project get set: responsibilities, penalties, ownership of deliverables. A project whose contract never anticipated drift recovers more slowly.

Outside help is justified in three cases: the steering committee can no longer reconcile the integrator’s account with the internal team’s; the project is more than 20 percent over budget with no firm delivery date; or replacing the integrator is on the table. In other cases, tighter governance is often enough. Our page on ERP and IT project recovery describes what an independent diagnostic produces.

What should you remember when an ERP project is late?

Name the delay, understand its cause, pick one of the four options and give every decision a date again. Budget comes after, never before. Our articles on the average ERP implementation timeline and on the certified integrator’s conflict of interest give the benchmarks for judging the gap and explain why the delivery partner cannot be the one judging the project. If you are choosing an advisor, read integrator, vendor or independent ERP consultant.

Frequently asked questions about late ERP projects

How much delay is acceptable on an ERP project?

A single slip of under three months on a twelve to twenty-four month project is common and is handled through governance. A second postponement, or one without a documented cause, warrants a diagnostic. Panorama’s 2025 report puts the median project at nine months; beyond double the original estimate, the project must be rescoped.

Do you have to stop a late ERP project to run a diagnostic?

Not always. If the cause of the delay is understood, the diagnostic runs alongside the work. If it is not, freezing billable activity for three to six weeks costs less than pressing on blind. The decision to freeze belongs to the steering committee, not to the integrator.

When should you replace your ERP integrator?

Only when the cause of the delay lies in the partner’s capacity or conduct, and never before securing documentation, ownership of configurations and a transition plan. A poorly prepared replacement typically adds three to six months. In most cases, rescoping and tighter governance fix the problem without changing partners.

What does an independent ERP project diagnostic produce?

A true picture of the project (scope, testing, data, open decisions), the causes of drift, the dependencies blocking the critical path, a decision log with owners and deadlines, and costed scenarios to continue, rescope, freeze or replace. All of it in about three weeks, delivered to the steering committee.

Who should lead the recovery of an ERP project?

A client-side leader with the authority to decide on scope and budget, backed by a steering committee that meets weekly during stabilization. The integrator executes; it does not steer. An independent third party can structure the diagnostic and the decision cadence without replacing management.