If your digital transformation is in trouble, the first thing to know is that you are not alone. The vast majority of transformations run into serious problems at some point, and many of the most successful organizations we work with have been through a recovery at least once. The good news is that proven recovery methods exist. The first and most difficult step in any recovery is realizing the project is in trouble. The horror stories you read about in the news almost always come from organizations that did not recognize the problems early enough. If you are reading this, you have already taken the most important step. This post lays out a structured approach for getting a struggling transformation back on track.
Step 1: Run an Honest Assessment
Before you can fix anything, you need to understand exactly what is broken. The temptation is to jump straight into solutions, but skipping the diagnostic phase almost always leads to applying the wrong fix to the wrong problem.
A thorough assessment looks at every dimension of the transformation:
- Business processes: Are current and future-state processes well defined? Are they aligned with how the system is configured?
- Technology: Is the system functioning as designed? Are integrations stable? Is data migrating cleanly?
- People and adoption: Are users completing training? Can they perform end-to-end processes? Is leadership engaged?
- Governance: Is the steering committee active? Are decisions being made and documented? Is the project management office functioning?
- Budget and timeline: Where are we against original commitments? What is the projected variance at completion?
Document your findings in detail. If business processes are not aligned with system design, capture specific examples. If data fields are not transferring correctly, note the specifics. Vague observations are not actionable. Specific evidence is.
In our experience, this diagnostic phase typically takes two to four weeks and is best conducted with an outside perspective that is not invested in defending past decisions.
Step 2: Identify the Root Cause
Symptoms are not causes. Failed user acceptance testing might point to a system design problem, an ineffective testing process, an inadequate change management structure, or all three. Identifying the surface issue is easy. Tracing it back to its true root cause is where the work gets difficult.
Look for patterns across the documentation from your assessment. If you are finding too many separate causes for the same set of symptoms, keep digging. The real root cause is usually deeper than the first one you identify, and it is often surprisingly small relative to the magnitude of the problems it created.
The two root causes we encounter most often are:
Inadequate Budget
If the original budget did not account for the full scope of work, every downstream issue compounds the problem. Recovery is not possible within the existing budget because the budget was wrong from the start. This is uncomfortable to admit, but pretending the budget is sufficient when it is not just delays the inevitable conversation.
Misaligned Executive Leadership
If the executive team is not aligned on goals, scope, or governance, every project decision becomes contested. Competing initiatives override sound technical decisions. Resources get pulled away. Failure becomes inevitable until alignment is restored. When we work with clients on organizational change management recovery, restoring executive alignment is almost always the first priority.
Step 3: Create a Recovery Plan
If you are heading toward failure, you need to change direction. This is the hardest step for most organizations because it requires acknowledging that the original plan is no longer valid.
A real recovery plan typically requires:
- Replanning from the point of failure: Not just adjusting the timeline, but rebuilding the project plan from where you actually are today.
- Resetting the budget: The existing budget is no longer valid. Period. CFOs may not love hearing this, but throwing more money at a broken plan is rarely the answer either. The path forward needs to be a clear-eyed projection of what real recovery actually costs.
- Replacing resources where needed: Some team members may not have the right skills or experience for recovery work. Some external partners may not be the right fit going forward. These changes are uncomfortable, but often necessary.
- Adjusting scope: Sometimes recovery requires reducing scope to focus on the most critical capabilities first, with secondary items deferred to a future phase.
- Pausing if necessary: If funding or capacity is genuinely not available for proper recovery, stalling is better than continuing to spend money on a failing project. Good money after bad never works.
The recovery plan needs steering committee approval and should be communicated clearly to the broader organization. Half-measures and quiet adjustments rarely produce the change in trajectory that recovery requires.
Step 4: Take Action
Planning a recovery is one thing. Executing it is another. The most well-designed recovery plans fail when they are not actively driven through the organization.
Effective execution typically requires:
- Clear ownership: Someone needs to be accountable for the recovery, ideally with executive authority and the bandwidth to focus on it full time.
- Renewed change management: Recovery often involves significant changes to processes, roles, and timelines. The communication and training that goes with those changes needs as much investment as the original transformation, sometimes more.
- Tighter governance: Real-time visibility, faster decision cycles, and more disciplined steering committee oversight than the original project had.
- External support: Recovery work is often the right time to bring in independent ERP project recovery expertise. Outside advisors can identify what internal teams cannot see and bring methodology that has been proven across other recoveries.
The hardest part of execution is maintaining momentum when progress feels slow. Recovery is a marathon, not a sprint, and organizations that lose patience often slip back into the same patterns that caused the original failure.
Learn From the Experience
The final and most important step is learning from what happened. Every failed transformation has lessons embedded in it. Organizations that capture those lessons and apply them to future initiatives are significantly less likely to fail again. Organizations that do not often repeat the same mistakes on the next major project.
We recently spoke with a company that had failed three times implementing new technology and is now attempting their fourth. Each previous attempt produced lessons, but none of them were captured systematically or used to inform the next attempt. If you keep falling off the horse, you should absolutely get back on. But also hire a trainer so you stop falling off.
For more detailed guidance on transformation recovery, including frameworks and checklists, our ERP Project Recovery Guide walks through the recovery process step by step.
Questions We Hear Most
How Do You Know If Your Transformation Is in Trouble?
Common warning signs include consistent budget overruns, slipping milestones, growing defect counts, low user acceptance test pass rates, declining steering committee attendance, executives publicly distancing themselves from the project, and increased reliance on workarounds during testing. If you are seeing two or three of these signals, the project is likely already in trouble. The earlier you act, the easier recovery becomes.
When we advise clients on ERP implementation oversight, we recommend regular health checks even when projects appear to be on track. The cost of an honest external assessment is small compared to the cost of recovering from a problem that went undetected.
How Long Does a Transformation Recovery Take?
It depends on how far off track the project has drifted and how decisive the recovery actions are. Smaller course corrections can sometimes be completed in 60 to 90 days. Major recoveries often take 6 to 12 months on top of the original project timeline. The variable that matters most is how quickly leadership accepts the situation and commits to a new plan. Organizations that delay decisions extend the recovery exponentially.
Should You Replace the System Integrator During Recovery?
Sometimes, but not always. If the system integrator is genuinely incapable of delivering or has lost the trust of the organization, replacement may be necessary. More often, the better answer is to add independent oversight that keeps the existing partner accountable while bringing methodology and experience the partner does not have. This is a common pattern in our digital transformation recovery work.
If your transformation is in trouble and you want guidance on getting back on track, contact us at eric.kimberling@thirdstage-consulting.com.
