The Proof After Go-Live: Making Post-Implementation Review a Working Control

Most change programmes have a clear beginning and a formal end. The beginning is the business case; the end, too often, is go-live. Once the system is live, the process is launched or the restructure is completed, attention moves to the next priority. The benefits register is archived, the programme board disbands, and the promised improvements in service levels, cost or adoption are left to be inferred from routine reporting. That is a weak position for any UK organisation to be in. A change has been delivered, but its value has not been proved.

A post-implementation review is not a retrospective comfort exercise. It is the control that connects the approval case to operational reality. It should establish whether the change has been adopted, whether the expected benefit is materialising, and whether any residual risk needs active management. Without that discipline, organisations learn very little from their change spend and repeat the same optimistic assumptions in the next business case.

Go-live is a handover, not a verdict

Go-live marks the point at which delivery risk shifts towards operations. It does not mark the point at which benefits are proven. Many benefits depend on behaviour: managers using the new process, teams following the revised standard, customers receiving a faster response, or support functions operating within the new service model. Those outcomes take time to settle and are rarely visible in the first week of live running.

Treating go-live as the finish line creates a predictable gap. Delivery teams measure milestones; operations measure performance. Unless someone is explicitly tasked with checking the benefit case after transition, the two perspectives never meet. The result is a programme that can be reported as successful while the operational evidence remains inconclusive.

Why reviews lose their edge

Post-implementation reviews often fail for ordinary reasons. They are commissioned too late, when the people with the deepest knowledge have moved on. They are owned by the delivery team, which has an understandable interest in confirming that the change worked. They focus on process compliance rather than outcomes. Or they produce a document with no route into decision-making.

The review also competes with live pressure. Once a change is in operation, the operational owner is dealing with demand, exceptions and service continuity. A review can feel like an additional burden rather than a management tool. To be useful, it must be light enough to run consistently and specific enough to answer the questions that matter.

A 30-day check: adoption and early signals

The first review point should come at around 30 days after go-live. Its purpose is not to deliver a final verdict on benefits, but to confirm that the change is being used as intended and that early warning signs are being addressed.

Useful measures at this stage include:

• actual usage or process adoption against the expected population;
• the volume and nature of workarounds, exceptions and manual interventions;
• service desk tickets, error rates or rework levels linked to the change;
• training completion and manager confidence in supporting the new way of working;
• whether the operational owner has the information and authority needed to manage the change.

The 30-day check should be short and evidence-based. It should confirm whether the change is stable enough to continue, whether additional support is required, and whether any early disbenefits are being monitored. It should not become a general audit of the programme.

A 90-day review: benefit and stabilisation

The 90-day review is where the benefits case starts to meet operational evidence. By this point, the organisation should be able to compare the original assumptions with actual performance. The measures will depend on the change, but they typically fall into four groups:

• financial impact, such as cost-to-serve, avoided expenditure or capacity released;
• service impact, such as cycle time, service levels, quality or customer outcomes;
• workforce impact, such as adoption, capability, workload and retention signals;
• risk impact, including residual risks, control weaknesses and unintended consequences.

This is not simply a finance calculation. A benefit that appears in the accounts but depends on unsustainable overtime is not a durable benefit. A service improvement that is achieved only through constant escalation is not embedded. The 90-day review should therefore test whether the benefit is repeatable and owned by the operational line, rather than sustained by programme effort.

Who owns the review

Ownership is the deciding factor. The review should be accountable to the executive sponsor or the relevant operational director, with the operational owner responsible for providing evidence and agreeing actions. A finance business partner can validate the benefit calculation, while the change or PMO function can provide a consistent template and facilitation. The programme manager should contribute, but should not be the sole judge of whether the programme succeeded.

This separation matters. Delivery teams are rightly focused on completion; operational leaders are accountable for performance after transition. The review should sit with the latter, supported by the former. It should also have a named chair who is independent enough to challenge optimistic reporting and senior enough to secure action when the evidence is uncomfortable.

Making findings useful beyond the file

A review that ends in a filing cabinet has failed. Findings should feed three practical outputs. First, an action log for the operational owner, with dates and named owners. Second, an update to the benefits ledger, showing what has been realised, what has been deferred and what has been written off. Third, a short lessons note for the next business case, covering assumptions, costing, capability and transition risk.

The lessons note is particularly important. UK organisations often approve change on the basis of confident forecasts and then close the loop without testing those forecasts. A consistent review discipline creates a body of evidence about what tends to happen after go-live: where adoption is slower than expected, where support costs persist, and where benefits depend on management capacity that was never resourced.

A light governance rhythm

Post-implementation review should be built into the change lifecycle, not added as an afterthought. A simple rhythm works well: a 30-day adoption check, a 90-day benefits and stabilisation review, and an annual portfolio look-back that draws out cross-programme lessons. The review should be proportionate to the scale of the change, with a short template for smaller initiatives and a more structured assessment for major transformation.

Benefits realisation is an operational discipline, not a finance formality. It requires named ownership, a small set of credible measures and a willingness to act on what the evidence shows. When that discipline is in place, go-live stops being the moment the organisation stops looking. It becomes the point at which the organisation starts proving that the change was worth making.