Program Recovery
The program did not look like it was in crisis.
Teams were busy. Meetings were full. Status reports were being produced. Individual workstreams were reporting progress.
But the major milestones kept moving.
The problem became clear when we stopped measuring activity and started measuring whether the program was ready to move from one stage to the next.
Here is what was going wrong.
The functional, data, integration, testing and technology teams were each working from their own plans. Those plans contained activities, but they did not form one reliable, integrated program schedule.
Important dependencies were not visible.
Interfaces were still being discovered. Data ownership and cleansing responsibilities were unclear. Business decisions were taking too long. Key resources were divided across the ERP program and their operational responsibilities.
At the same time, testing dates remained on the calendar even though the solution, data, integrations and environments were not going to be ready.
The program was not suffering from a lack of effort.
It was suffering from a lack of integration, prioritization and timely decision-making.
What I assessed first
I did not begin by asking everyone to work harder or by immediately changing the delivery date.
I first assessed four things:
- What was the true critical path to the next major milestone?
- Which scope items were genuinely required for go-live?
- Did we have the right people, with enough capacity, assigned to the critical work?
- Were decisions being made quickly enough to keep delivery moving?
This assessment showed that the original plan was no longer credible.
Some activities were marked as substantially complete even though the dependencies needed to finish them remained unresolved. The program was tracking progress by tasks performed rather than by outcomes achieved.
We then implemented three corrective actions.
1. Rebuilt the plan around the real critical path
We created one integrated plan connecting functional design, configuration, development, data migration, integrations, environments, security, testing, training and cutover.
Every critical activity had an accountable owner, a required completion date and clearly identified predecessors and successors.
We also challenged assumptions such as:
“Testing can start while the remaining integrations are completed.”
“The business can validate the data later.”
“We can make up the time during UAT.”
Those assumptions may make a schedule look better, but they do not make the program more executable.
The revised plan showed leadership where delays were occurring, and which decisions were affecting the target date.
2. Reduced and sequenced the scope
The program had accumulated requirements, reports, interfaces and enhancements that were important, but not all were essential for the initial release.
We separated the scope into three categories:
- Required for operational readiness and go-live
- Required soon after go-live
- Valuable, but appropriate for a later optimization release
This was not arbitrary scope cutting.
Each decision considered business continuity, regulatory requirements, financial controls, operational risk, customer impact and the availability of a reasonable workaround.
The change-control process was also strengthened. New requirements could no longer enter delivery without an assessment of their cost, capacity, testing and schedule impact.
3. Introduced recovery governance and readiness gates
We replaced broad status discussions with focused decision and delivery forums.
Each critical issue had one owner, one due date and a clearly stated consequence if it remained unresolved.
Leadership received a concise view of:
- Decisions required
- Critical-path progress
- Scope changes
- Resource constraints
- Data and integration readiness
- Testing readiness
- Risks to the next milestone
We also established measurable entry and exit criteria for each major stage.
SIT, for example, could not begin simply because the planned date had arrived. The required solution components, environments, test data, integrations and test cases first had to meet an agreed level of readiness.
What improved
The program did not recover because everyone suddenly worked longer hours.
It recovered because the work became more focused and the leadership team gained a more accurate view of reality.
Scope became manageable.
Decisions were made faster.
Critical resources were directed toward the work that mattered most.
Testing began from a stronger position.
Most importantly, the program stopped moving from one optimistic plan to another. It regained delivery discipline, predictability and stakeholder confidence.
One of the most important lessons I have learned from ERP recovery is this:
A program cannot be recovered until everyone is willing to work from the same version of the truth.
Have you seen an ERP program appear busy and productive while its most important milestones continued to slip?