When an ERP Implementation Stalls: How Program Recovery Works
Most stalled ERP implementations are recovered rather than restarted, and the recovery is usually about how the program is run, not about the software. This article describes what an independent program leader does in the first sixty days, drawn from a recent reset of a partner-led Microsoft Dynamics 365 program at a national distributor with hundreds of locations.
The signs
Programs rarely fail loudly. They drift. The signs a sponsor should act on:
Milestones move more than once without a re-baselined plan behind them.
The partner proposes a "methodology reset" and the business cannot say what was wrong with the old one.
Functional teams stop attending, or attend and stop deciding.
Nobody can produce a single list of open issues, risks and decisions that everyone uses.
The sponsor learns about problems in steering meetings rather than before them.
Change orders arrive faster than deliverables.
None of these means the platform is wrong or the partner is bad. They mean the program has lost its operating rhythm.
Why independent leadership
The partner cannot lead the recovery of its own program, however competent, because every recommendation it makes is also a commercial decision. The internal team is usually too close, too stretched, or new to programs of this size. An independent program leader answers to the sponsor, has seen the pattern before, and can say things to both sides that neither can say to each other.
The first sixty days
Days 1–10: Understand before changing anything - Six questions, asked on day one: What is the detailed history and what has actually been completed? What is the next milestone and how are we tracking to it? Who is on the internal team, mapped against the couple of dozen roles a program of this size needs, whatever they are called here? Which partner and ISV people actually show up each week? Where do requirements, RAID items and assigned work live, and can I see them? What meetings and groups already exist? The answers usually explain the stall.
Days 10–30: Read the reset independently - If the partner has proposed a new structure or methodology, review it from a process-based standpoint rather than a contractual one. Is the move to milestone-based delivery real or cosmetic? Are the roles staffed? Does the plan reflect the client's own guiding principles for the system? Give the sponsor an honest read, join the partner's planning sessions, and negotiate the plan rather than accept it.
Days 30–45: Rebuild the operating rhythm - One RAID log the whole program uses. A decision-owner map so every open item has a name. Weekly status the sponsor can read in five minutes. Business-process owners re-engaged with a clear ask and a clear forum. Escalation paths that get used before things are late.
Days 45–60: Re-baseline and widen the lens - With the rhythm restored, re-baseline the plan against the partner's capacity and the business's real availability. Then look past the immediate milestone: is the program's scope still the right scope? At the distributor, this became a seven-week diagnostic of the company-wide "one ERP" direction, covering functional scope validation, reporting and integration strategy, phasing and resource plan, and the commercial assumptions for the next statement of work, ending in an on-site leadership readout.
What recovery is not
It is not replacing the partner by default. It is not a parallel shadow team. It is not a new tool. Restarts are expensive and rarely justified by problems a reset can fix. In the distributor's case, the platform and partner stayed; the way the program was run changed, and the client's own project managers now run day-to-day delivery with independent program leadership above them.
Frequently asked questions
What does an ERP implementation project manager do that the partner's PM does not? Represent the client. The partner's project manager is accountable for the partner's scope and margin; the client-side program leader is accountable for the business outcome, the internal team's capacity and the decisions the partner needs from the business.
How much time does program recovery take? It starts at ten to twenty hours a week for the assessment and typically grows to a full-time role, with additional consultants on specific workstreams, through re-baselining. The goal is to hand day-to-day delivery back to the client's team.
Can the program be recovered without changing the partner? Usually yes, and usually it should be. The partner's people and knowledge are sunk investment; what needs to change is governance, plan realism and the business's engagement.
When is a restart the right answer? When the platform cannot meet a core requirement that was missed in selection, or when the partner cannot staff the program. Both are rarer than they feel in a bad month.
If your program looks like this, talk to John about your ERP program.
