The technology is live. Which promised benefits have actually arrived?

The launch report says the new workflow is in use across the business. The investment case promised faster decisions and lower operating cost. Those statements can all be true descriptions of different things, yet only the first may have been demonstrated.

As programme sponsor, your post-launch benefits review should establish which part of the original promise has materialised and what decision follows. It should be possible to retain a useful system while rejecting an unsupported savings claim, or to stop an expansion even though the implementation team delivered what it was asked to build.

Recover the promise without rewriting it

Start with the approved investment case and the assumptions behind each material benefit. Identify the starting position, the intended operating change, the measure, the expected timing and the person responsible for making it happen. Keep the original version visible when assumptions change. Otherwise a review can gradually redefine success to match whatever the new system happens to produce.

Government Project Delivery’s benefits guide, published on 29 July 2026, assigns individual benefits to owners who often sit in operations and calls for continued ownership and review after project closure. The useful principle for a technology sponsor is continuity: completing delivery does not remove the need for someone to realise and measure the operating benefit.

Give that owner enough authority to change the relevant process. The software delivery manager may control the application, while the accounts-payable lead controls invoice handling and approval rules. A benefit dependent on the latter cannot be delivered simply by assigning another reporting task to the former.

If no credible baseline was recorded, reconstruct what can be supported from dated operational records and describe the gaps. Avoid asking people to produce a precise historical estimate from recollection. Where evidence is weak, a narrower claim and a new forward measurement period are more useful than a confident percentage.

Follow one benefit through three kinds of evidence

Consider a hypothetical invoice-workflow programme. It promised to reduce manual handling and shorten the wait for approval. Most invoices now enter through the new system, but managers still approve them in batches and the approval backlog remains.

Adoption evidence shows whether the intended population uses the process. Count the eligible invoices, the proportion following the new route and the exceptions still handled elsewhere. Licence assignments or logins alone would not establish that the relevant work has moved.

Operational evidence shows whether the work changed. Compare hands-on processing time, elapsed approval time, error rates and rework for comparable invoice types. In this example, data entry might improve while approval waiting does not. Report those as separate findings rather than giving the whole programme one success label.

Financial evidence shows how an operating improvement affects cost or value. Suppose comparable observations support a one-minute reduction in handling time across 6,000 invoices a month. That represents 100 hours of processing capacity. It is not automatically 100 hours of cash savings: the result depends on what happens to staffing, overtime, contractor cost or useful work completed with the capacity.

If the team uses that time to clear a backlog, record the capacity benefit and the additional completed work. If paid overtime actually falls, finance can validate that financial effect. Do not count the same released time both as a full cash saving and as wholly additional productive capacity without explaining the allocation.

The remaining approval delay needs a different response. The sponsor might fund a focused change to approval ownership or delegation, rather than commission more workflow features. Define the expected effect and review it after enough comparable work has passed through. The finding should change the next action.

Make the comparison strong enough for the decision

Before attributing an improvement to the programme, examine other changes. Lower demand may have reduced queues. A staffing increase may have accelerated handling. Easier cases may now dominate the workload. A supplier or policy change could have removed an entire approval step. These explanations do not invalidate every benefit, but they change how much credit the technology can defensibly receive.

Compare like periods and material case types where records permit. An unaffected business unit or a phased rollout can provide a useful comparison, provided you account for differences between groups. Where that is unavailable, combine the operational trend with evidence that the intended mechanism changed, and state the attribution limit. A benefits review need not pretend to be a controlled experiment to improve the decision.

Include the cost of sustaining the outcome: ongoing licences, support, training, exception handling and any manual work moved elsewhere. A reduction in one department’s effort may be offset by additional work in another. Equally, a valuable reliability or service-quality improvement deserves recognition even when it does not produce a near-term cash reduction.

End each material benefit with a decision. Continue where the mechanism works and the remaining investment is justified. Adapt where a specific dependency prevents the outcome. Stop an expansion where the evidence no longer supports the case. Give any corrective action an owner and review point, and preserve the unresolved benefit as unresolved.

Feed those findings into the next technology investment decision. The strongest review changes how the organisation allocates money and effort; it does more than add a reassuring page to the project closure pack.