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 |
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.

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.
Sources and scope
Reviewed 1 November 2026. The examples and worksheets are my suggested working methods, not measured client results or official standards.

