Adoption Under Inspection: A Thirty-Day Review for Changes That Must Hold

Go-live is a date, not a destination. Yet in many UK change programmes, the weeks immediately after launch are treated as a victory lap rather than a period of evidence gathering. The project team disperses, the sponsor turns to the next item on the portfolio, and the new process is left to settle—or drift—without structured examination. By the time adoption problems surface in performance reports, the change has lost the plasticity of its early days. Correcting it is harder, slower and more expensive than it needed to be.

The case for a thirty-day review is not that launch is unimportant. It is that launch is the point at which the organisation begins to reveal what it actually thinks of the change. The month that follows is when workarounds form, when team managers absorb pressure, and when the gap between the designed process and the lived process becomes visible. A short, disciplined review at that point is not bureaucracy. It is the difference between managing adoption and hoping for it.

Why the post-launch month deserves the same rigour as the build

During design and build, change teams are accustomed to evidence: requirements, test scripts, readiness checks, sign-off. After go-live, the evidentiary standard often collapses into anecdote. A few cheerful comments in a corridor, a quiet first week, and the programme is declared successful. But early quiet can mean many things. It can mean the process is working. It can also mean people have not yet encountered the cases that will break it, or that they are quietly routing work around it.

The thirty-day review exists to distinguish between those possibilities. It should be scheduled before launch, owned by someone with operational credibility, and treated as a working session rather than a post-mortem. Its purpose is not to judge the programme team. It is to establish what is genuinely happening in the business, what needs correction, and what can be safely left alone.

A practical review agenda

The agenda below is deliberately narrow. It is not a full benefits review, nor a substitute for formal assurance. It is a structured check on adoption at the point when intervention is still cheap.

1. Evidence of use, not evidence of training

Training completion rates are an input, not an outcome. The review should ask for evidence that the new process is being used in the ordinary course of work: transaction volumes, queue movements, exception logs, system audit trails, or sampled case reviews. Where the process involves human judgement, a small sample of recent decisions can be more revealing than any dashboard. The question is simple: can we show that the new way is the default way, not an optional extra?

2. The workaround inventory

Workarounds are not necessarily failures. Sometimes they are sensible local adaptations that reveal a design gap. But they need to be known, assessed and either adopted or closed. The review should ask team managers and frontline supervisors to name the shortcuts currently in use, however minor. A spreadsheet kept alongside the new system, a verbal approval that bypasses the workflow, a recurring email that duplicates a system notification—each is a signal. The output should be a short register with owners and decisions, not a blame exercise.

3. What team managers are absorbing

The layer that decides adoption is usually the team manager. If the new process creates extra checking, more escalation, or unclear exceptions, managers absorb the friction personally. That absorption can look like success at programme level while quietly exhausting the people who make the change work. The review should ask managers what has become harder, what they are repeatedly explaining, and where they are making judgement calls the process did not anticipate. Their answers are often the most useful design feedback the programme will ever receive.

4. Defect and friction triage

Not every post-launch issue is a defect. Some are training gaps, some are process design choices, and some are simply unfamiliarity. The review should separate them. A short triage session with operations, technology and the business can categorise issues into fix now, fix next, and accept. The discipline lies in assigning an owner and a date to each item that matters, and in resisting the temptation to label every friction point as a training issue.

5. Decision latency and escalation

New processes often change decision rights without saying so explicitly. The review should trace a handful of recent decisions through the new route. Where did they wait? Who was unsure whether they had authority? Which exceptions required escalation that the design assumed would be routine? Decision latency is an early indicator of adoption strain, and it is usually easier to correct in week four than in quarter two.

6. A benefits baseline, not a benefits claim

The thirty-day review is too early to prove benefits, but it is the right time to establish a baseline against which benefits can later be assessed. Record the current volumes, cycle times, error rates or service levels. This prevents the familiar problem of a programme claiming success against a baseline nobody can reconstruct.

Making the review stick

The review should be chaired by someone with operational standing, not solely by the programme manager. It should involve team managers, a representative from the receiving business area, and the relevant technology or process owner. It should produce three outputs: a short evidence summary, a prioritised action list with owners, and a decision on when the next check will take place. That final point matters. A single review can become a ritual; a scheduled follow-up makes it a control.

None of this needs to be elaborate. A half-day session, a focused evidence pack and a clear action log are sufficient for most changes. The value lies in the timing and the honesty of the questions, not in the weight of the documentation.

The month that protects the investment

UK organisations invest considerable energy in building and launching change. The thirty-day review protects that investment by treating adoption as a managed outcome rather than an assumed consequence. It gives change and operations leads a structured way to see what is really happening, to correct course while correction is still inexpensive, and to hand over a change that has been examined rather than merely announced.

For more insights on change management and operational improvement, explore the Jenesys Associates editorial library.