A benefits realisation plan explains the improvement a project is expected to create, who owns it and how the organisation will know it happened. For each benefit, record the starting point, target, evidence source, review dates and changes needed in everyday work. Agree who will act on the findings before the project hands over.

This matters when the project is nearly finished but the business still cannot answer a simple question: what will be better once people use what we have built?

Separate the delivery from the improvement

Consider a new management dashboard. There are three different things to check:

  • Delivered: the dashboard is available and its data has been checked.
  • Used: managers use it in the review and stop preparing the old pack alongside it.
  • Improved: preparation takes less effort or decisions happen sooner, with acceptable accuracy.

Each needs its own evidence. A completed dashboard does not establish how much preparation effort has changed.

APM’s guidance on benefits management distinguishes the successful delivery of a project from the benefits that may emerge after handover. Keep that distinction visible in your plan.

Our portfolio dashboard KPI guide covers the executive view across projects. This guide explains the working record behind an individual benefit.

Choose a benefit that someone can influence

“Improve efficiency” gives the owner very little to work with. Describe whose work should improve and what should change.

For example: “Reduce the effort the finance team spends preparing the monthly management pack while maintaining the agreed checks.” That statement suggests a measure, an owner and a quality condition.

Be explicit about the intended use of any time released. It might create capacity to analyse performance or serve more customers. Treat a cash saving as a separate claim that needs evidence of an actual reduction in expenditure.

What to put in the plan

Start with one record per material benefit. A small improvement project may need only a few records. Use these fields:

  1. Improvement sought. State the operational change in plain language, including who should benefit.
  2. Accountable owner. Name the person who controls the work that must change and will remain responsible after delivery.
  3. Baseline. Record the current measure, observation period and scope. Note any missing data or unusual conditions.
  4. Target and timing. Agree the intended improvement and when it could reasonably be observed. Keep the target separate from the actual result.
  5. Measure and evidence. Define the calculation, data source, collection method and person preparing the update.
  6. Required changes. List the routines, decisions or dependencies that must be in place for the benefit to happen.
  7. Quality and cost checks. Record what must not deteriorate, including rework, service quality or effort transferred to another team.
  8. Review and action. Set the review dates, decision forum and response if the evidence shows the benefit is at risk.

The Australian Capital Territory’s benefits realisation planning guidance treats the plan as ongoing work linked to the business case. The fields above are a practical starting point for a smaller business project, rather than a claim that every project needs the same governance process.

Give the business owner a real role

The project manager coordinates delivery and handover. The benefit owner needs authority over the operational changes that produce the result. The PMO can maintain a consistent register, challenge unsupported claims and bring decisions to the right meeting.

For a reporting improvement, the owner might be the finance leader responsible for the reporting cycle. The analyst can prepare the evidence without becoming accountable for whether managers retire the old process.

The Australian Digital Transformation Agency’s benefits management guidance places benefit ownership within the business and calls for reviews beyond project delivery. This is useful even where the organisation has no formal PMO: the person receiving the change must accept the continuing responsibility.

If responsibility sits between teams, resolve the decision rights before approving the plan. A name in a spreadsheet is insufficient when that person cannot change the process. The decision-rights guide explains how to make that authority clearer.

Worked example: a monthly reporting change

The following is an illustrative planning example, not a client result.

Benefit sought: release preparation capacity within the finance team without weakening the management pack’s accuracy.

Owner: the finance leader responsible for the monthly reporting cycle.

Starting evidence: preparation and checking effort from comparable recent cycles, including corrections and time spent maintaining parallel reports. Record which activities are included.

Measure: baseline preparation hours minus current preparation hours per cycle. Also show the volume of work, material corrections and any effort transferred to other teams. Those checks help explain whether the comparison is fair.

Changes required: agree metric definitions, validate the new reporting view, assign data owners and decide when the previous pack can be retired.

Target: agree it after reviewing the baseline and required changes. Record it as an expectation until actual observations support it.

Review: compare the first complete cycles after transition with the baseline. Investigate poor data, continued parallel reporting or additional checking before declaring the benefit achieved.

Decision: if preparation capacity has been released, agree how the team will use it. If the evidence is incomplete, record the uncertainty and assign the next action.

This is enough to start a useful conversation. It exposes the work that must happen between installing a dashboard and improving the reporting cycle.

What to check before project closure

Before the project team leaves, ask the benefit owner to confirm:

  • the baseline can still be retrieved and the comparison is understood
  • someone has access to the evidence and time to prepare it
  • the required operational changes have owners
  • review dates and the escalation route are in the normal management calendar
  • another project is not claiming the same benefit in full
  • outstanding assumptions and risks are visible to the sponsor

Set reviews around when a result can be observed. A monthly reporting benefit needs complete reporting cycles; a customer-service change may need a different observation period. A standard review date for every project can create activity without useful evidence.

What if the project has already gone live?

Start with the evidence that is available. Earlier reports, service records or a documented sample may provide a usable comparison. Explain its limits. Do not turn a recollection into a precise baseline or report a forecast as a realised saving.

Separate adoption problems from measurement problems. If the old process is still running, the change may need implementation support. If the process has changed but nobody has collected evidence, fix the measurement responsibility. Our guide to measuring change adoption covers the first question.

For shared benefits, agree one consolidated claim and record how the contributing projects support it. Keep the original forecast visible when it changes so leadership can understand what has happened.

Make the next review useful

A useful benefits review ends with a decision: continue, correct the operating setup, revise the forecast or stop counting a benefit that no longer has a credible route to delivery.

LUKiN’s Dolby Customer Service transformation case describes a related piece of groundwork: assessing maturity, identifying capability gaps and turning them into practical next steps. Those are documented outputs of that engagement; they are not presented as measured financial benefits.

If your portfolio reports delivery dates but nobody owns what should improve afterwards, LUKiN’s PMO consulting and portfolio governance support can help define the ownership, evidence and review routine. If it is still unclear where progress is breaking down, start with an Operational Performance Diagnostic.

Sources

Sources reviewed on 23 October 2026.