ERP Project Recovery

Why ERP implementations stall

ERP projects rarely fail because of one dramatic mistake. They drift into trouble through a series of reasonable-looking decisions that add up. Understanding which of these applies to your project is the first step to recovering it.

• Thin requirements. The project started from a short feature list or a vendor demo, so real processes, exceptions and reports were discovered during build or testing.
• Unrealistic timeline. The go-live date was fixed before the scope was understood, leaving no room for the inevitable surprises.
• Unclear ownership. Nobody on the business side had the authority or time to make decisions, so questions waited and assumptions filled the gaps.
• Scope creep. New requests were accepted without changing time or budget, until the plan no longer reflected reality.
• Data problems. Legacy data turned out to be messier than expected, and migration consumed time meant for testing.
• Over-customization. Standard features were replaced with custom code to replicate old ways of working, adding complexity and defects.

None of these is unusual, and none is purely the fault of one party. Both the client and the implementation partner usually contributed. That is why I keep recovery conversations focused on facts and next steps rather than blame. A calm, shared understanding of what went wrong is far more useful than a contest over who caused it. If your project has not stalled yet but you are worried, an ERP health check can catch the warning signs earlier.

An ERP second opinion: what it covers

When leadership loses confidence in a project, the first need is an independent, factual picture. An ERP second opinion answers a few direct questions: where does the project really stand, what are the biggest risks, and what are the realistic options?

To answer them, I:

1. Interview sponsors, process owners, key users, the internal project manager and the implementation partner, separately, so each can speak openly.
2. Review documents such as the contract scope, requirements or BRD, design documents, project plan, change log, test results and issue lists.
3. Look at the system itself, checking what has been configured, what works end to end and how far data migration has progressed.
4. Compare what was agreed, what was built and what the business actually needs, using a simple fit-gap view.

The result is a short, plain-English readout covering the project's real status, the root causes of delay, the critical gaps, and options ranging from continuing with adjustments to a more fundamental reset. Each option includes the main trade-offs and cost drivers, without invented figures. Because I am not tied to any vendor and have no interest in selling a replacement, I can tell you honestly whether the current platform and partner can get you there.

Resetting scope with your vendor or implementation partner

Most recoveries succeed with the existing implementation partner, provided both sides agree on a new baseline. That conversation can be difficult when relationships are strained, which is where an independent facilitator helps.

I prepare for the reset by building a clear, shared view of the work:

In the reset workshop, we work through each category, agree responsibilities and acceptance criteria, and settle on a revised plan with realistic milestones. Disputed items are resolved by reference to the original scope documents and the business impact, not by who argues hardest. Where requirements were genuinely unclear, I help rewrite them properly, often using the same approach as ERP requirements gathering and BRD consulting.

Occasionally, the evidence shows that the platform or partner cannot deliver what the business needs. In that case I help you plan a controlled transition, including a fresh vendor selection, protecting the work that can be reused.

Building and running the recovery plan

A recovery plan is only useful if it changes how the project runs day to day. Alongside the revised scope and timeline, I put in place the governance that was often missing the first time:

• Clear decision rights, with named business owners for each process area and a sponsor who resolves escalations quickly.
• A single integrated plan covering configuration, data migration, integrations, testing, training and cutover.
• A risk and issue log reviewed weekly, with owners and due dates.
• A change control process so new requests are assessed for impact before they are accepted.
• Short, honest status reporting to leadership, highlighting what is off track rather than hiding it.

A frequent recovery tactic is a smaller first go-live: a core set of processes, entities or locations that can go live safely, with the rest following in planned phases. This restores momentum, gets the business benefiting sooner and rebuilds trust between teams.

As the project moves toward go-live, structured testing and UAT and disciplined go-live support make sure the recovered project lands well. If your ERP implementation is stuck and you would like a calm, independent view, get in touch. The first conversation is simply about understanding where things stand.