By Ritvars Mētra, Founder of ReadinessCompassTwo weeks before go-live, a steering committee is shown a slide with a lot of green on it. Defect counts are inside tolerance. The final data migration reconciled. Interfaces passed end-to-end testing. Performance testing held at twice expected volume. The recommendation is to proceed, and the committee proceeds.
Six weeks later the same committee is looking at a different slide. Order entry is taking three times longer than it did on the legacy system. The month-end close has slipped. Two people in finance are doing the work of nine because everyone else is waiting for them. Nothing on the original slide was wrong.
The slide answered a question about the software. The problem was never about the software.
Two questions that sound like one
Technical readiness asks whether the system will do what it was built to do. Business readiness asks whether the organisation can produce its normal output using it, from the first working day, at the volume the business actually runs at.
These are not two views of the same thing. A system can be entirely defect-free and still be operated by people who take four minutes to do what used to take forty seconds, by a team that has lost its two most capable users to the project, in a month where the close is already compressed. Each of those is a genuine reason not to go live, and none of them will appear on a test report.
| Technical readiness | Business readiness | |
|---|---|---|
| The question | Does the system behave correctly? | Can the organisation produce its normal output using it? |
| Evidence | Test results, defect counts, reconciliation reports, performance runs | Who can do the work, how long it takes them, what happens when it goes wrong |
| Owner | Delivery and IT | The operational business owner who inherits the process |
| Failure mode | Defects surface in production | Output falls and stays down while everything technically works |
| When it is felt | Immediately, and it is visible | Over weeks, and it is usually attributed to something else |
The last row is the one that causes lasting damage. A technical failure announces itself. A business readiness failure looks like a team that has become slow, and slow teams get explained away as resistance, as poor training, or as people needing more time.
Why the distinction collapses under pressure
It is not that programmes do not know the difference. It is that the two questions come with very different evidence, and decisions drift towards whichever evidence is easiest to put in front of a committee.
Technical evidence is abundant, numeric and generated automatically. There were 412 defects, 9 remain open, none are severity one. Nobody argues with it.
Business readiness evidence has to be deliberately created, and every number in it is contestable. Ninety-four per cent training completion means ninety-four per cent of people clicked through a module. It is not a claim that anyone can do their job. When the only available evidence is attendance, attendance becomes the readiness measure, and the gate quietly changes from “can they work” to “were they told”.
This is also why user acceptance testing is a better readiness signal than most programmes use it as. UAT is usually read as a defect-finding exercise, but it is the one moment before go-live when real people attempt real work in the real system, and it will tell you who needed help, which scenarios nobody could complete, and whose confidence was borrowed from the expert sitting next to them.
The phase you are actually deciding about
The most useful framing of this problem is twenty-five years old. In The Enterprise System Experience — From Adoption to Success, M. Lynne Markus and Cornelis Tanis divide the enterprise system journey into four phases: chartering, project, shakedown, and onward and upward. Go-live is not the end of the project phase in any meaningful sense. It is the entrance to shakedown, which the authors define as the organisation’s “coming to grips with the enterprise system”, ending only when normal operations have been achieved.
Their description of what happens in that phase is the most accurate account of a difficult go-live in the literature. It is, they write, largely the phase in which the errors of prior phases are felt — as reduced productivity or business disruption. The problems they list are not technical: business disruption, excessive dependence on a handful of key users, maintenance of old manual workarounds, data input errors, and no growth in end-user skill after initial training.
Two of those deserve naming, because both are now well documented on their own. Markus and Tanis observe that operational staff adopt workarounds to cope with early problems and then fail to abandon them once the problems are fixed — which is exactly why spreadsheets outlive the go-live that was supposed to eliminate them. They also note the tendency to lean on knowledgeable project team members instead of building capability across all operational staff, which is the mechanism behind expert overload.
The sharpest idea in the chapter is what they call unresolved experience risk. Problems that are not detected and corrected in one phase do not disappear; the next phase inherits them. And the cost of fixing a problem rises with the delay in recognising it. A business readiness gap that could have been closed with two weeks of practice in September becomes, in December, a productivity deficit that requires contractors, overtime and a recovery plan.
That is what a go/no-go decision is really doing. It is deciding how much unresolved risk to carry across the line.
What a formal readiness gate actually asks
Private-sector programmes tend to invent their go/no-go criteria from scratch. There is no need to. Government assurance regimes have had a formal gate for this exact decision for two decades, and the questions are public.
In the Gateway process — developed by the UK Office of Government Commerce and still published in workbook form, for example as Queensland Treasury’s Gate 4: Readiness for service — the review sits after all testing, including business integration testing, and before release into production. Its stated purpose includes confirming “that the business has the necessary resources and that it is ready to implement the services and the business change”.
Three of its probe questions are worth stealing outright.
- “Is the organisation ready for business change?” The evidence expected is not a training completion figure. It is agreed plans for business preparation and transition, a documented communications plan, staff trained and informed, and a clearly defined service management function already in place.
- “Can the organisation implement the new services and maintain existing services?” This is the question almost nobody asks. Running the new process is not the whole job. Running it while continuing to serve customers, close the books and answer the phone is the job. The evidence expected is a resource plan showing capacity and capability, not intent.
- “If there are unresolved issues, what are the risks of implementing rather than delaying?” Note the framing. Delay is treated as a live option with its own risk profile, requiring a documented evaluation of cancelling, delaying or proceeding, and a board that ratifies the recommendation either way.
The workbook also expects “feasible and tested business contingency, continuity and reversion arrangements”. Tested, and reversion. Most commercial go/no-go packs contain neither. The rollback plan, where one exists at all, is usually a paragraph asserting that rollback is possible.
How a well-run programme actually made the call
In December 2025 the UK National Audit Office reported on the Bank of England’s renewal of the Real-Time Gross Settlement system — the infrastructure that settles around £790 billion of sterling payments a day. It launched in April 2025 at a cost of £431 million, and the NAO judged it a success. Three details of how it handled readiness are worth copying.
First, the governance split. The Renewal Executive Board gave overall approval for go-live using set readiness criteria, then delegated the final decision to the programme’s senior owner and technical director — explicitly, in the NAO’s words, so that decisions were made by those with detailed knowledge of the programme’s readiness. The board owned the criteria; the people closest to the evidence made the call. That is the opposite of the common arrangement, where a committee with no operational visibility makes a decision on a summary slide.
Second, how readiness was evidenced. The Bank prepared its users through user testing, dress rehearsals, and monitoring industry readiness. Not a completion percentage — rehearsal, and an active view of whether the people outside the programme were ready to receive it.
Third, and most striking, one of the four replans was triggered by nothing technical at all. The European Central Bank moved its own migration date close to the Bank’s, which, as the NAO puts it, created too high a level of change for users to manage safely. A programme that was technically capable of proceeding delayed because the people who had to absorb the change could not absorb that much of it at once. That is a saturation judgement, made by a central bank, and recorded by a national audit body as sound practice. It is worth remembering the next time the amount of concurrent change on your own users is treated as somebody else’s problem.
Who signs what
The practical fix is unglamorous: stop treating go-live as one signature. Business readiness is a set of separate claims, each owned by someone who will personally live with the consequences.
| The claim | Evidence that settles it | Signed by |
|---|---|---|
| People can do the work | Named individuals completing real scenarios unaided, at realistic volume — not attendance | Process owner for each affected process |
| There is enough capacity | A resource plan covering the new process and continuing operations through the dip | Line manager of the receiving team |
| Exceptions are covered | Documented handling for the top failure cases, with a named person for each | Operational business owner |
| Support is staffed | A support model with rotas, escalation paths and hours agreed, in place before day one | Service owner |
| We can revert | A rehearsed reversion or contingency plan, with a decision point and a decision-maker | Sponsor |
Two things change when it is structured this way. Sign-off stops being a formality, because a named manager is being asked to assert something about their own team that they will be held to in six weeks. And the shape of the gap becomes visible: it is normally not five weak claims but one, in one function, that everyone privately knew about.
This is also where line manager readiness stops being an abstraction. A manager who cannot answer the capacity question about their own team is not being obstructive; they usually have not been given the information to answer it.
If you are six weeks out and cannot answer these
This is the common situation, and the answer is not to build a readiness programme you no longer have time for.
- Pick the three processes that would hurt most if they slowed by half. Not the most changed — the most consequential. Order entry, invoicing, dispatch, the close.
- Watch four real people attempt each one, unaided, and time them. Half a day of observation produces more usable readiness evidence than a month of survey work, and it is the only method that reveals borrowed confidence.
- Ask each receiving manager one question in writing: what will you stop doing in the first three weeks? An answer of “nothing” is a finding.
- Write down what you are choosing to carry. If you proceed with a known gap — and programmes reasonably do — record it, resource the mitigation, and name its owner. Carried risk with a name attached is manageable. Carried risk that was never written down becomes the thing nobody predicted.
None of this requires you to have run a full change impact assessment earlier in the programme, though it is considerably easier if you did.
The decision you are actually making
Organisational readiness is not a mood, and it is not a completion percentage. In the most widely cited theoretical account of it, Bryan Weiner’s A theory of organizational readiness for change, readiness has two facets: change commitment — whether people are willing — and change efficacy, the shared judgement that they are collectively capable of executing it, given the task demands, the resources available and the situation they are in. Willingness without capability is not readiness, and most go-live gates measure neither.
Technical readiness tells you the system will not fail. Business readiness tells you the organisation will not. They are different claims, they need different evidence, and they should carry different signatures. When a programme collapses them into a single green slide, it has not made a decision about risk — it has made a decision about which risk it was willing to look at.
The programmes that get this right are rarely the ones with the best test coverage. They are the ones where somebody was willing to say, in front of the steering committee, that the software was ready and the warehouse was not — and where the weeks after go-live were planned as a phase in their own right rather than as a gap before the project closes.
More on evidence-led ERP go-lives in the ERP Readiness Hub, or see how a Readiness Diagnostic Sprint produces this evidence in two to three weeks when the gate is already close.