A client recently called us about what was supposed to be a 12-month ERP implementation. Three years later, the project was on its third systems integrator, still far from cutover, and no one could clearly explain what work remained.

Given the weekly burn and lack of progress, we recommended a short pause: stop the work, run a focused implementation audit, and align on a realistic recovery plan. It would have taken two to three weeks.

The company rejected the approach.

“We can’t stop and risk losing more time.”

Five weeks later, the team had been working harder than ever. The project had not advanced. It had gone backward, and much of the work would need to be redone.

That response is common.

When ERP projects get into trouble, leaders usually do not ignore the problem. They act. The issue is that the first moves often feel right while making the situation worse.

Here are six common responses that tend to create more motion than progress.

Common Leadership Responses That Feel Right – But Aren’t

1. “We just need to keep moving.”

Once a project is deep in motion, stopping to recalibrate feels like losing momentum. The organization has already invested heavily. Teams are busy. Leadership wants visible progress.

But continuing to execute against a misaligned plan does not build momentum. When teams keep building, configuring, and testing against a foundation that has not been fixed, every deliverable becomes a candidate for rework. In our experience, the time spent on a structured implementation audit and recovery plan can save months of delay and significant cost.

2. “We’ll tell the recovery consultants what to do.”

Once leadership loses confidence in the project team, the instinct is to take control.

That is understandable. Leaders want faster answers, visible action, and less ambiguity.

But if you bring in a recovery team and then tell them exactly what to do, you are not really asking them to recover the project. You are asking them to execute your current theory of the problem.

That is risky, because in troubled ERP projects, leadership often knows what is wrong but not why it is happening.

The better approach is not blind trust. It is controlled trust. Give the recovery team room to diagnose, challenge assumptions, and define the recovery path — then hold them to short, measurable milestones.

3. “We just need to replace the system integrator.”

Sometimes the system integrator is the problem. Weak consultants, poor methodology, thin advisory support, or weak project management can absolutely put an ERP project at risk.

But replacing the SI does not automatically fix the project.

A new partner inherits the same governance, decision-making culture, unresolved business issues, and internal capacity constraints. If those conditions are not addressed, the same problems usually reappear with a different team.

Before replacing the SI, get clear on the division of labour. What did the partner own? What did the client own? Where did the handoffs fail? Where were decisions delayed? Where was the business not ready?

Then decide whether the answer is a new partner, a reset of roles and accountability, or both.

4. “A stronger project manager will fix this.”

When an ERP implementation starts to slide, it is easy to blame the project manager.

A strong ERP project manager matters. They bring structure, discipline, cadence, and visibility to the work.

But ERP recovery is not just a management problem.

A project manager can flag stalled decisions. They can escalate risks. They can show where workstreams are slipping. What they cannot do is make executives align, force business owners to make decisions, or create accountability where none exists.

A stronger project manager can bring discipline to the work, but they cannot recover an ERP project if the people who own the business decisions, workstreams, and outcomes are not doing their part.

5. “We just need more people.”

When an ERP project falls behind, adding people feels like the obvious fix.

Sometimes it is. If the work is clear and the bottleneck is capacity, targeted help can make a difference.

But troubled ERP programs rarely have a pure headcount problem. More often, priorities are unclear, decisions are stalled, workstreams are misaligned, or teams are building against assumptions no one has validated.

Add people into that environment, and you usually get more coordination, more onboarding, more meetings, and more pressure on the people who are already stretched.

More people can help once the recovery plan is clear. Until then, more people usually just means more noise.

6. “We picked the wrong ERP system.”

System fit matters. Sometimes the software really is the wrong choice. When that is the case, call it out.

But in troubled ERP projects, the system often becomes the easiest thing to blame.

More often, the real issues are data, testing, change management, governance, or basic execution discipline — problems that would have surfaced with almost any system.

A 70% fit ERP solution implemented well will outperform a perfect-fit system implemented badly.

Before blaming the software, make sure the project structure around it is strong enough to give it a fair chance.

Start With the Right Diagnosis

If your ERP project is showing signs of trouble, the first step is not to push harder. It is to get clear on what is actually broken.

The ERP Project Recovery Playbook goes deeper into the five-phase recovery roadmap and the seven dimensions of the ERP Audit Framework, with a practical structure for assessing where the program stands and what needs to happen next.

Use it to pressure-test your project, challenge the usual assumptions, and decide whether the issue is execution, governance, resourcing, system fit, or something more fundamental.

Download the playbook before making the next big move.