The system went live on Friday. By Monday, someone had put the forecast savings into a presentation as though the money had already arrived.

Delivery is an event. Benefits need rather more evidence.

The short answer: a benefits realisation plan records the outcome, accountable business owner, baseline, target, measurement method and changes needed to achieve it. A delivered output is not proof that the promised benefit happened.

Distinguish output, outcome and benefit

A new onboarding system is an output. Staff using a revised process is a change in operation. Reduced onboarding delay may be a benefit if it improves something the organisation values and can measure.

The chain matters because technology can be delivered while the old process continues around it. If users maintain parallel spreadsheets and approvals remain unchanged, the expected saving may never appear.

The UK government’s benefits-management guide, hosted by APM is a useful primary reference. The worksheet here is a simpler working aid, not a substitute for an organisation’s required investment process.

Build the benefit record

Field What to specify
Benefit The valuable change, stated plainly
Owner Business person accountable after delivery
Baseline Current performance, period and evidence
Target Intended change and date, with assumptions
Measure Definition, source, frequency and reviewer
Enablers Process, adoption, staffing or policy changes
Disbenefits Costs or adverse effects to monitor
Attribution Other factors that could explain the change

Download the editable worksheet (CSV) ↓

Work through an onboarding example

Suppose the objective is to reduce the time between a complete application and activation. Define those two events precisely and collect a baseline over a representative period. Record the distribution as well as a summary if a few long delays matter.

The enabling changes might include removing duplicate entry, clarifying approval authority and training the team. The system launch is one milestone in that chain, not the benefit itself.

After implementation, measure the same interval using the same definition. Check whether the mix or volume of applications changed. A quieter month can improve the figures without the programme causing the improvement.

Desk with calculator, notebook, pencil, and plant
Illustrative photograph. Photo: Cht Gsml / Unsplash.

Be careful with time savings

Minutes released do not automatically become cash savings. They may become extra capacity, faster service, less overtime or simply a less frantic working day. Each can have value, but they are different claims.

If the business case assumes a financial saving, identify the mechanism that converts time into money and the owner able to make that change. Do not multiply theoretical minutes by salaries and call the result realised profit.

For UK and UAE operations, keep currencies and measurement definitions explicit. Avoid combining figures from different teams without checking whether the work and accounting basis are comparable.

Keep disbenefits visible

A new process may reduce delay while increasing staff checking effort or excluding users who need assistance. Record these effects alongside the headline benefit.

Check for double-counting across projects. If a portal, an integration and a process redesign all contribute to shorter onboarding, give the combined benefit one ID and one accountable owner. Record each contribution, but report the consolidated improvement once. Do not add three claims for the same released capacity.

Agree guardrails before reviewing results. A speed improvement that materially worsens accuracy or accessibility may not be an acceptable success. Give the business owner a balanced picture, not a selective victory chart.

Review after the project team leaves

Assign review dates and data ownership before closure. Confirm who will investigate a missed target and who can authorise further process changes. Benefits often depend on operational teams long after the delivery team has moved on.

Use the programme governance framework to connect benefit decisions to authority and funding. Stop reporting benefits that no longer have a credible basis; revise the business case transparently.

A benefit owner needs the ability to change the operation, not just the obligation to report a number. Without that authority, the plan is mostly a reminder of what everyone hoped would happen.

Put this to work

Sources and scope

Reviewed 1 November 2026. The examples and worksheets are my suggested working methods, not measured client results or official standards.