The hardest decision in enterprise transformation is not whether to start a programme. It is whether to delay one that has already announced its go-live date.
By the time a board is openly considering a pause, the cost of pausing feels enormous. Marketing has been told. The business has been prepared. Suppliers have been re-papered. Investor expectations have been set. The political cost of delay feels far greater than the operational cost of going live with a programme that is not ready.
This is almost always the wrong way around.
The framework, not the feeling
Boards facing a contested go-live tend to want a clear answer. The team delivering the programme wants to launch. The independent voice wants more time. The executive sponsor wants the decision made. Everyone is operating from incomplete information — and the absence of a framework means the loudest voice tends to win.
The framework below is the one TRC uses with boards in this position. It does not produce the answer. It produces the evidence the board needs to decide.
Test 1 — The defect backlog trajectory
A shrinking backlog suggests the programme is converging on readiness. A stable backlog suggests it is being managed but not resolved. A growing backlog in the final thirty days is, by itself, sufficient evidence to pause. No amount of hypercare planning compensates for entering go-live with an accelerating defect curve.
Test 2 — The critical-path integration tests
Not unit tests. Not isolated module tests. End-to-end execution of the processes the business actually depends on. If these have not been completed successfully — or if “successfully” has been redefined to exclude the failures — the system has not been tested. It has been demonstrated.
Test 3 — The business’s readiness to operate
A go-live that depends on the SI’s hypercare team to keep the business operating is not a go-live. It is an extended UAT with consequences. If users still cannot complete their daily work independently in week one, the readiness gap is operational, not technical — and operational gaps are not closed by going live.
Test 4 — The rollback plan that is actually rehearsable
Many programmes have a documented rollback plan. Few have one that has been rehearsed against production-equivalent conditions. A rollback that exists only on paper is not a rollback. It is reassurance. If the worst-case path has not been walked, the programme is not ready to risk go-live.
How to read the four tests together
The four tests are not weighted equally. Failing any single test on its own does not necessarily require a pause. But the relationship between them matters.
One test failing is a focused remediation problem — close the gap and proceed. Two tests failing is a structural problem — the programme is not ready and a short pause is almost certainly the right call. Three or four tests failing means the go-live date was always aspirational — pausing is no longer the decision. The decision is how long the pause needs to be.
What pausing actually costs
The argument against pausing is almost always financial: the cost of delay, the cost of extended SI engagement, the cost of business disruption. These costs are real. They are also, in almost every case, an order of magnitude smaller than the cost of an unsafe go-live.
Revlon’s $64M in lost sales did not result from pausing. Zimmer Biomet’s $172M lawsuit did not result from pausing. Both resulted from going live when the four tests above had not been honestly answered.
The pause is not the failure
The hardest cultural shift inside a programme approaching an unsafe go-live is reframing the pause itself. A pause is not a programme failure. A pause is the one mechanism the board has to prevent the programme from becoming a business failure.
If the four tests above have not been honestly passed, the board’s job is not to approve the date. The board’s job is to make sure the date approved is one the programme can actually meet.
