Delivered Is Not the Same as Beneficial

A programme replaces a support inbox with a customer portal. The delivery team closes the migration plan, transfers the runbook and celebrates the launch. Three months later, nobody can say whether customers are resolving problems more easily.

The portal exists. The expected benefit still needs to be measured and managed.

This fictional example focuses on the period after handover. Investment appraisal belongs in the business case; operational transfer belongs in the handover plan. Benefits realisation asks whether the intended improvement is appearing in practice, who owns it and what happens when the evidence points elsewhere.

Carry the benefit beyond the project boundary

A project team can deliver a usable portal without controlling every condition needed for a better support outcome. Content may need regular maintenance. Staff may need to change how they route requests. Customers may need accessible alternatives when the portal does not fit their situation.

The Northern Ireland Department of Finance describes benefits management as a lifecycle that continues through realisation and assigns responsibilities across programme and business roles. That is public-sector guidance, but it illustrates why the outcome cannot simply disappear when the delivery team closes. Benefits-management introduction

For the proposed service, name an operational benefit owner who can influence the relevant process after launch. Give that person a measure, access to the evidence and a route to request changes. A name on a register without time, authority or data is weak ownership.

Keep the delivery team available for the agreed transition obligations, but do not leave the programme manager as the permanent owner of a support outcome they cannot operate.

Translate the promise into an observable result

“Reduce support workload” is too broad to review on its own. Fewer tickets could mean customers solve their problems, or that they cannot reach the team. Define the result the programme actually wants.

For this example, the proposed benefit is that customers resolve eligible routine requests without avoidable repeat contact, while customers needing help still receive it. Eligibility needs a stable definition. A complex complaint should not be relabeled routine merely to improve the denominator.

The UK government's benefits-assurance guide discusses ownership, measures, baselines and disbenefits in major projects. The relevant sections support keeping these assumptions explicit; they do not supply a universal success threshold for this private support service. Benefits assurance guide, V2.1, August 2026

Record what must remain acceptable alongside the intended gain. Repeat contacts, unresolved complaints and staff maintenance effort may reveal costs hidden by a lower incoming-ticket count.

Preserve a baseline that someone else can interpret

Suppose the fictional baseline period contains 1,000 eligible routine requests, of which 600 are resolved without avoidable repeat contact. The observed rate is 60%. A later period contains 1,200 eligible requests with 780 such resolutions, a rate of 65%.

The count of successful resolutions rose by 180 and the observed rate rose by five percentage points. Neither calculation alone proves that the portal caused the improvement. The later period may contain easier cases, more experienced staff or a separate process change.

Keep the case definition, observation window, data source and known gaps with the numbers. Record changes in volume and case mix rather than treating them as noise to remove from the report. If the source system changed during migration, establish which fields remain comparable.

The Magenta Book distinguishes benefits monitoring from wider evaluation of effects, including attribution and unintended outcomes. Its evaluation context is government policy and programmes. Applied here, the useful limit is that monitoring an improvement does not automatically identify its cause. Magenta Book, section 1.7.1

A programme may need a stronger evaluation design to support an investment decision. Choose that design with appropriate analytical expertise rather than implying that a before-and-after chart supplies a counterfactual.

Give each benefit a practical review record

This is a proposed review aid, not a mandated template. Keep it small enough that the operational owner can use it during a normal service review. Link to detailed evidence rather than copying a programme's entire business case into every meeting pack.

Transfer the outcome obligation

Name the operational owner, measure, baseline, dependencies and review date.

Collect evidence under the agreed definition

Is the measurement usable and comparable?

Check coverage, case mix, missing data and changes in definitions.

Missing or non-comparable evidence

Investigate the measurement gap. Preserve the limitation and repeat the assessment when evidence is usable.

Reassess comparability when the measurement gap is addressed

Usable evidence continues to interpretation

Assess improvement, costs and alternative explanations

Separate observed change from causal attribution and capacity from cash savings.

Bring the result to the responsible decision-maker

Continue, adapt or revise the benefit claim

Record the decision, operating action and next review. Delivery closure does not remove ownership.

Operational handover leaves the benefit owner responsible for measurement and action. An observed improvement alone does not establish causation or cash savings.

Separate released capacity from cash savings

Imagine the support team estimates that the portal avoids 80 hours of routine handling during a review period. That estimate needs a method and evidence. Even if credible, it does not mean the budget has fallen by the salary value of 80 hours.

Staff may use the time to clear a backlog, handle more complex cases or improve service quality. Those can be valuable outcomes. Record them as such. A cash-saving claim needs evidence of an actual financial change, with the relevant costs and timing included.

Also account for work that moved elsewhere. If specialists now spend more time maintaining answers or resolving portal exceptions, the gross handling reduction is not the whole result. Avoid counting the same released time once as a support saving and again as a separate programme benefit without explaining the relationship.

The business-case guide covers appraisal and benefit assumptions before investment. The post-handover review should test those assumptions against operating evidence, preserving differences rather than editing the original promise to match the result.

Respond when the benefit does not appear

A weak result should lead to a specific investigation. Are customers finding the relevant content? Are staff still asking them to repeat information? Is a different case mix obscuring a useful effect? Is the measure incapable of answering the original question?

Assign the investigation and retain its conclusion. The response might be a service change, more targeted research or a correction to the expected benefit. It may also be a decision to stop investing in a feature whose cost is not justified by observed use.

Keep the operational owner involved in that decision. Benefits reporting becomes detached from delivery when a programme office repeatedly updates a scorecard but the service team cannot act on what it shows.

Close delivery without closing the question

At handover, transfer the benefit record alongside the service responsibilities. Confirm who can access the data, how often it is reviewed and who decides what happens when a dependency fails. The operational handover guide addresses the wider transfer; this benefit obligation should survive it.

The portal launch can remain a legitimate delivery achievement. The later review should state what changed for customers, what costs appeared and how strongly the evidence supports the explanation. That gives the business a basis for the next decision instead of a permanent green label attached to a finished project.