When an ERP implementation is in the red, the answer is rarely to sprint harder toward the go-live date. Structural problems do not yield to execution speed. The better path is a controlled, time-boxed stabilization period, agreed to by every party, that finishes the foundational work and sets a new go-live date only when the organization is actually ready.
Here is how I put it in a recent Start at Zero episode:
“Pushing forward with structural issues unresolved and hoping execution velocity can outrun organizational gravity is how you get to a go-live that fails and you end up in the newspapers.”
The situation
The case I walked through was a public authority 741 days into an ERP implementation. As I described it on the show: “Finance red, procurement red, treasury red, integrations red, conversions red, security and controls red, change management red.” Six of ten boundary systems were not connected. Role mapping was less than fifty percent complete. The go-live date had already slipped three months.
The team was working hard. The consultants were working hard. None of this was the result of lazy effort. The problem was structural, and it was baked in before implementation began. That is frustrating, but it is also useful, because structural problems have structural solutions.
Three options for a project in the red
When a project gets here, leadership usually has three paths.
1. Accelerate. Commit fully to the current date and marshal every resource to hit it. The risk is that you can sprint and still miss if the structural dependencies never resolve. A failed go-live attempt does more damage than a proactive delay, because it burns the organizational goodwill you need for the recovery.
2. Stabilize. Take a controlled slip with a scope lock. Accept a deliberate delay in exchange for resolving the dependencies that are still open: connect the boundary systems before exiting testing, finish role mapping completely, and freeze scope for real.
3. Reset. Pause and do the phase zero work that was skipped before the project started. In my words: “This is not starting over.” It means finishing readiness work before committing to a date you can hold.
The recommendation: stabilize, with elements of a reset
My recommendation in this case was option two, with elements of option three built in: “A controlled, time-boxed stabilization period used productively to complete the foundational work that wasn’t done before.”
Two conditions make that work.
Everyone has to agree. Executives, the project team, the systems integrator, and the software provider all need to sign on. A stabilization that only one party believes in becomes another slipped date.
It has a boundary. This is not an indefinite delay. It is a deliberate reset of the foundations, with a new go-live commitment made only when the organization can honestly answer the five Start at Zero questions in the affirmative.
Why a deliberate slip is not a failure
Public leaders often feel that moving a date is the worst possible headline. It is not. The worst headline is the failed go-live that everyone could see coming. A slip that is announced early, communicated well, and managed transparently shows that leadership understands its risks. Pushing ahead on hope shows the opposite.
If your program is showing red across several workstreams, ask three questions before you approve another sprint:
- Are the problems we are seeing about effort, or about decisions that were never made?
- Which dependencies, such as integrations, security roles, conversions, or scope, have to be resolved before testing can honestly exit?
- Do all parties agree on what “ready” means, and on who decides?
If the answers point to structure, more speed will not help. Stabilize, finish the foundations, and then recommit.
Related reading
The five Start at Zero questions, and the playbook behind them, are in the book. Read Chapter 1 of Start at Zero free.