An ERP can go live while the finance team continues preparing reports in spreadsheets. A procurement platform can be operational while purchases still bypass agreed contracts. A service-management system can process tickets without improving how quickly customers receive a useful resolution.
In each case, the technology may be functioning. The expected business improvement remains a separate question.
For executive sponsors, that creates an important distinction: delivery progress and value delivery are connected, but they are not interchangeable.
PearsonGoldman’s position is that benefits should remain part of management decisions after the implementation milestones are complete. They should not become a retrospective exercise undertaken only when somebody asks whether the business case was achieved.
What transformation benefits realisation actually means
The Association for Project Management describes benefits management as the discipline of identifying, defining, planning, tracking and realising benefits. It distinguishes benefits realisation from simply delivering outputs. [1]
An output is something delivered, such as a configured platform or a redesigned process. An outcome is the resulting change in how work or services operate. A benefit is the improvement that matters to the organisation or its stakeholders.
For example, a purchasing workflow is an output. More purchases following the approved commercial route is an outcome. Lower comparable purchasing costs, stronger control or less avoidable rework may be benefits, provided the evidence supports the claim.
The connection needs to be designed:
Delivered capability → change in everyday work → measurable outcome → evidenced benefit.
Go-live is not necessarily the beginning of that sequence. Government Project Delivery guidance explicitly recognises that benefits can arise during development and implementation as well as during operational use. [2]
The management task is to establish when each benefit should emerge, what enables it and who remains responsible for making it happen.
Define benefits so they can be tested
“Improve efficiency” is an ambition, not a complete benefit definition.
For each material benefit, PearsonGoldman recommends recording the intended improvement, affected population, measurement method, accountable owner, expected timing and conditions required for success.
State the operational change that should produce the result. A reduction in invoice-handling effort may depend on accurate supplier records, purchase-order compliance, reliable integrations and users following the new process.
Those dependencies belong in the delivery plan, with owners and completion evidence.
Also establish what would invalidate the claim. A shorter handling time should not be celebrated without checking whether errors, repeat contacts or work elsewhere have increased.
A benefit record should be useful enough to support a decision. It does not need to become a large document maintained separately from the programme’s normal controls.
The practical test is whether someone outside the workstream can understand what was promised, what must change and what evidence would demonstrate progress.
Preserve the baseline and test the explanation
Keep four things distinct: the starting performance, the originally approved target, the latest forecast and the observed result.
They answer different questions.
A lower forecast may be realistic after a scope change. It should not silently replace the original commitment and make the programme appear to have delivered everything first promised.
Retain the change history, reason and approval. Explain whether the difference represents delay, reduced scope, an incorrect assumption or value that is no longer expected.
Where a credible pre-change baseline is missing, reconstruct it from dependable historical evidence where possible. Document the limitations. Do not present a retrospective estimate as a measurement that was taken before implementation.
Observed improvement also needs interpretation. A lower backlog may reflect reduced demand, additional temporary staff or a seasonal change rather than the transformation alone.
HM Treasury’s Magenta Book distinguishes monitoring from evaluation and explains the role of considering what might have happened without the intervention. It also recognises approaches that examine contribution where simple attribution is difficult. [3]
Our recommendation is to make the strength of the explanation visible. Use proportionate comparisons, operational evidence and specialist analysis where needed. Do not invent a precise attribution percentage simply because a report requires a number.
Time released is not automatically cash saved
The Government Efficiency Framework distinguishes cash-releasing efficiencies from benefits that improve productivity without directly reducing spending. Its reporting principles also address costs and double counting. Those are government reporting requirements within their stated scope, not an accounting rule imposed here on every organisation. [4]
For transformation leaders, the practical lesson is to be precise about the type of value being claimed.
Consider an illustrative calculation, not a client result or benchmark.
Assume an organisation processes 10,000 invoices each month. A redesigned process reduces hands-on work by three minutes on the 60 per cent of invoices that actually follow it.
That represents 300 hours of gross monthly capacity:
10,000 × 60% × 3 minutes ÷ 60 = 300 hours.
If additional review and rework consume 100 hours, the simplified net capacity improvement is 200 hours before any other effects are considered.
That does not automatically establish a cash saving. The organisation needs to demonstrate what happened to the released capacity: additional productive activity, lower overtime, reduced external support or another evidenced outcome.
Multiplying hours by a salary rate may help value capacity. It does not prove expenditure has fallen.
Similarly, distinguish cost avoidance from an actual spending reduction, and a working-capital improvement from recurring profit. Agree the classification and validation approach with Finance.
Do not annualise one unusually good month without examining whether the result is representative and sustainable.
Measure the whole effect, including new costs
A benefit claim should not exclude the work required to produce it.
For an automation initiative, examine ongoing licence charges, integration support, exception handling and monitoring. For an operating-model change, include the transition effort and any continuing coordination or specialist support it introduces.
Present one-off implementation costs and recurring operating effects separately so the comparison remains understandable.
Look across organisational boundaries. Reducing work in Finance while transferring more work to operational managers is not the same as reducing total effort. A faster service that increases avoidable errors needs a balanced assessment.
Record adverse effects alongside intended improvements. These may include additional workload, reduced accessibility, greater supplier dependency or deterioration in service quality.
Where several programmes support the same outcome, agree how the contribution will be reported. One reduction in invoice rework should not become three additive savings because ERP, Procurement and Automation each contributed to it.
The portfolio should show a coherent value story, not the sum of competing claims.
Give ownership to people who can influence the result
A benefit owner needs more than responsibility for updating a status field.
They need authority over the process, resources or decisions that determine whether the improvement can be achieved. Where a benefit crosses functions, name an accountable owner and make the contributing responsibilities explicit.
PearsonGoldman recommends separating business ownership from measurement administration.
The operational owner drives the change and performance. Finance validates financial claims and their classification. Appropriate service, quality or risk specialists assess non-financial outcomes. The PMO coordinates the record, dependencies and escalation.
The sponsor resolves decisions that exceed the owner’s authority.
These roles can be combined in a smaller organisation. The essential point is that collecting the data should not be mistaken for owning the outcome.
Government Project Delivery guidance similarly assigns benefits to named individuals and emphasises clear operational ownership as work transitions and closes. [2]
Do not allow ownership to disappear when a programme manager leaves or the programme board stops meeting. Transfer it explicitly and confirm the receiving person has accepted it.
Measure adoption through work, not attendance
Training attendance shows that somebody attended training. It does not establish that they can perform the revised process correctly or that they use it consistently.
For change management, measure the behaviour that enables each benefit.
In procurement, that might be the proportion of relevant transactions following approved buying channels. In Finance, it might be completion of reconciliations through the intended controlled process. In service management, it might be successful resolution without avoidable reassignment or repeat contact.
Use appropriate quality measures alongside adoption measures. Logins and transaction counts alone can conceal workarounds.
Ask why people are not using the intended process. They may lack permissions, encounter poor data, face an impractical approval route or receive conflicting instructions from their managers.
Treat those as operating-model and delivery questions rather than automatically labelling them resistance to change.
Managers also need time and authority to reinforce new ways of working. Communications cannot compensate for a process that makes the correct action unnecessarily difficult.
Retire old methods through a controlled decision once the replacement is dependable. Do not remove necessary continuity arrangements merely to improve the adoption dashboard.
Follow the dependencies that can prevent value
For ERP transformation, benefits may depend on decisions outside the technical deployment.
A legacy-system saving cannot be fully realised while the organisation still needs the old application and its contract remains active. Faster reporting may depend on data ownership and reconciliation changes that were deferred from the initial release.
A purchasing benefit may depend on supplier onboarding, contract coverage and managers changing how they buy.
These are not simply items for a lessons-learned log. They are remaining value-delivery work.
Connect each material dependency to the affected benefit, the owner who can resolve it, the required funding and the consequence of delay.
Be precise about the gap. A benefit may be delayed, reduced, no longer relevant, or genuinely unknown because measurement has failed. Those situations require different decisions.
Calling them all “value leakage” can obscure the cause.
The response should address the actual barrier. Another dashboard is not the answer when a contract termination decision, a missing interface or an unresolved process ownership dispute is blocking the result.
Separate stabilisation, benefits and programme closure
Stabilisation asks whether the new operation is dependable and supportable.
Benefits realisation asks whether the intended improvements are occurring.
Programme closure asks whether delivery obligations have been completed or explicitly transferred and whether the remaining responsibilities can be managed appropriately.
Those decisions should inform each other without being collapsed into one sign-off.
A service may be stable while benefits remain below forecast. A benefit may be improving while a material control issue still needs resolution. Neither result cancels the other.
Before closing the programme, confirm that remaining benefits have accepted owners, a measurement approach, resources for necessary follow-on work and a management forum able to intervene.
It is not necessary to keep every programme open until the last long-term benefit is realised. It is necessary to avoid closing the governance gap by assumption.
NISTA publishes specific guidance on examining benefits realisation through the assurance review process. [5]
Within programme assurance, the question should therefore extend beyond whether a benefits register exists. Does the evidence support the claim, and can the organisation continue managing the value after the delivery team leaves?
Give the board a view that supports decisions
A benefits report should not simply reproduce the programme milestone dashboard.
PearsonGoldman recommends a concise view that preserves the distinction between commitments, forecasts, results and management action.
On smaller screens, scroll this table horizontally to read all columns.
| Reporting element | What leadership should be able to see |
|---|---|
| Original commitment | The approved benefit, target, measurement basis and expected timing |
| Latest forecast | The current expectation, variance from the original and explanation |
| Observed result | The measured outcome, reporting period, population and evidence source |
| Validation | What has been checked, by whom, and what remains uncertain |
| Net effect | Relevant costs, adverse effects and treatment of overlapping claims |
| Remaining dependency | The action, accountable owner, funding and consequence of delay |
| Required decision | What leadership must approve, resolve, stop or reassess, and by when |
Report actual results for the completed period separately from projected future performance. Do not present an annual run rate as though it has already been realised.
Use a small set of measures that explain whether the operating model is changing in the intended way. Keep the supporting detail available for challenge.
Where evidence is incomplete, label it incomplete. An unverified claim is neither a confirmed success nor proof that no benefit exists.
The purpose of the review is to decide what should happen next, not to protect a previously reported colour.
Already live? Use a focused benefits reset
An organisation does not need to restart its whole transformation because benefits reporting is weak.
The following is an indicative sequence for a bounded review and recovery effort. It is not a promise that every benefit can be realised within 90 days.
First 30 days: establish a defensible position
Select the most material benefits and recover the original assumptions, commitments and available evidence.
Confirm owners, classify the claims and separate measurement gaps from performance gaps. Identify whether new costs, incomplete adoption or unfinished dependencies change the picture.
The output should be an agreed current position, including uncertainty, rather than a retrospectively improved business case.
Days 31-60: resolve the highest-value barriers
Prioritise the actions most likely to improve the outcome.
That may involve fixing a data problem, changing an approval route, completing an integration, improving operational capability or making a delayed commercial decision.
Assign owners and resources. Define the evidence that will demonstrate whether the intervention helped.
Do not approve remediation solely because the original programme has already consumed significant investment. Consider the remaining cost, risk and achievable value.
Days 61-90: test the result and establish ongoing ownership
Review representative performance after the corrective work.
Confirm which improvements are supported by evidence, which need longer observation and which assumptions should be revised.
Transfer continuing measurement and action into normal management arrangements. Set future review dates according to the benefit’s actual timing, not an arbitrary programme anniversary.
Some outcomes require several operating cycles or a longer observation period. Keep that limitation explicit rather than manufacturing an early success claim.
Make the approach proportionate
Not every change needs a separate benefits team, specialist platform or extensive measurement exercise.
A small improvement may need a clear owner, a reliable starting measure and a scheduled review. A multi-programme transformation may need integrated benefit profiles, financial validation, dependency management and independent challenge.
The effort should reflect the value at stake, uncertainty, complexity and consequences of getting the decision wrong.
Not every important benefit can be credibly reduced to a monetary figure either. Service quality, accessibility, resilience and control can matter even where a cash valuation would be speculative.
For those outcomes, agree suitable evidence and acceptance criteria. Do not replace an uncertain monetary estimate with an unsupported claim of certainty.
The question that should survive go-live
The central question is not simply, “Did we deliver the system?”
It is, “What changed in the business, what value followed, and what evidence supports that conclusion?”
PearsonGoldman’s approach connects transformation delivery with operating-model decisions, adoption, accountable ownership and measurable outcomes.
That connection should be established before implementation and maintained after the launch celebrations, the end of hypercare and the closure report.
A successful go-live is an important achievement. The investment case still needs to be tested in operation.
Examples and calculations are illustrative, not PearsonGoldman client results or performance benchmarks. Government sources are referenced within their stated scope. The practical approach described here is adaptable guidance, not an accounting treatment, assurance opinion or guarantee of financial return.
Related reading
Sources
- Association for Project ManagementWhat is benefits management and project success?
- Government Project DeliveryThe Teal Book, Chapter 19: Benefits management
- HM TreasuryMagenta Book: Central Government guidance on evaluation
- Government Finance Function and HM TreasuryThe Government Efficiency Framework
- National Infrastructure and Service Transformation AuthorityAssurance of benefits realisation in major projects