Topic 6.2 — Benefits Realization & Value Management

A benefit that is promised in a business case but never named, owned, baselined, and tracked to the point of banking is a benefit that will quietly evaporate — and in health and care that lost value is measured in clinician hours, patient outcomes, and public money that could have gone elsewhere.

Why this matters in health and care#

Every digital investment in health and care is justified by a promise: fewer missed appointments, faster diagnosis, safer prescribing, less time on the phone, better population health. These promises are the currency of business cases, board approvals, and public trust. Yet the sobering pattern across the public sector is that benefits are enthusiastically forecast, delivery is celebrated at go-live, and then the team disperses before anyone confirms the promised value ever arrived. The gap between "the system is live" and "the value has landed" is where most digital investment silently leaks.

In health and care this gap is not merely a financial embarrassment. When you tell an integrated care board (ICB) that an e-referral system will release 12,000 clinician hours a year, and those hours never materialize because clinicians now do double-keying instead, you have not just wasted money — you have consumed scarce workforce capacity, eroded frontline trust in "digital", and told a story to the public that turned out to be false. Benefits realization is therefore an accountability and public-trust discipline as much as a financial one. It is how you prove that the opportunity cost of choosing this investment over a hip operation, a nurse, or a care package was worth paying.

This topic is deliberately distinct from its neighbors. Topic 6.0 — Financial Management & Business Cases is about appraising and funding an investment up front. Topic 6.1 — Health Economics is about valuing health outcomes and cost-effectiveness with methods like quality-adjusted life years. This topic is about the discipline that comes after the sign-off and often long after delivery: naming the benefits, tracking them over time, and actually banking the value that was promised.

Core concepts#

Benefits realization management (BRM) is the discipline of identifying, planning, measuring, and tracking the benefits of an investment from initial idea through to their eventual capture — and then confirming they were achieved. It treats benefits as things to be actively managed, not automatic by-products of delivering a system.

A benefit is a measurable improvement resulting from an outcome that is perceived as positive by one or more stakeholders. Benefits are classified along several axes. Cashable benefits release money that can be removed from a budget and spent elsewhere; non-cashable benefits release capacity or improve quality without a line you can literally cut (for example, freeing 30 minutes of a nurse's shift that is immediately reabsorbed into more care). Financial benefits can be expressed in money; non-financial benefits — safety, patient experience, equity, staff wellbeing — matter enormously in health and care but resist a simple currency value. A disbenefit is a measurable decline attributable to the change: the alert fatigue, the new manual workaround, the digitally excluded cohort. Disbenefits are real benefits with a minus sign and must be tracked with equal honesty.

A benefits map or benefits dependency network links the capabilities a project delivers to the enabling changes people must make, to the business outcomes, and finally to the strategic objectives. It is closely related to a logic model and a theory of change: each shows the causal chain from "what we build" to "why it matters". Reading the map backwards forces a hard question — which capability actually causes this outcome, and what else has to be true?

Benefits are measured with indicators. Leading indicators are early, predictive signals you can act on (adoption rate, percentage of referrals sent digitally); lagging indicators confirm the outcome after the fact (reduction in did-not-attend rates, waiting-time change). You need both: leading indicators tell you whether value is on track while you can still intervene; lagging indicators tell you whether it actually landed.

Value management — a cousin of value engineering — is the wider practice of maximizing the ratio of benefit to resource across the whole life of an investment, deliberately trading scope, cost, and benefit rather than treating any one as fixed. It links directly to the business case, whose benefits sit downstream of the up-front cost–benefit analysis, and to the wider project portfolio, where benefits from many investments are aggregated — carefully, to avoid double-counting the same saving twice. The UK reference frameworks are HM Treasury's Green Book (the appraisal and evaluation guidance behind every public business case) and Managing Successful Programmes (MSP), which places benefits management at the heart of program delivery.

Best practices#

1. Make benefits realization a named discipline, not a business-case appendix. Too often benefits are written once to win approval and never revisited. Establish benefits management as an ongoing activity with its own cadence, artifacts, and reporting line into the portfolio and the board. The test is simple: if the only place your benefits live is a spreadsheet inside the approved business case, you do not yet have benefits realization — you have benefits forecasting.

2. Assign a named benefit owner for every benefit, in the operational line — not the project. Each benefit needs a single accountable person who runs the part of the organization where the value will actually land: a clinical director, an operations manager, a service lead. Projects and their senior responsible owners (SROs) exist to hand over; the benefit owner remains after the team disperses. If you cannot name the person who will be measured on a benefit two years from now, that benefit is orphaned and will not be realized.

3. Map benefits to capabilities before you build anything. Draw the benefits dependency network from strategic objective back to the specific capability the investment delivers, and expose the enabling changes — training, process redesign, decommissioning the old system — without which the benefit cannot flow. This map is your early-warning system: if a capability has no line to any outcome, question the scope; if an outcome depends on a change nobody owns, the benefit is at risk. Revisit the map at every stage gate, not just at the start.

4. Profile each benefit: when, how much, and how measured. A benefit profile states the baseline, the target, the measurement method and data source, the owner, the dependencies, and — critically — the expected timing. Many health and care benefits land months or years after delivery ends: a shared care record's reduction in duplicate testing accrues as clinicians change habits, not on go-live day. Profiling the trajectory stops you from declaring failure too early or success too soon.

5. Baseline before you change anything, and protect that baseline. You cannot claim a reduction in did-not-attend rates if you never measured them beforehand, and a baseline captured after go-live is worthless. Agree the baseline, its data source, and its definition with the benefit owner and finance before deployment, and freeze it. Where seasonality or a rising demand trend would distort a naïve before-and-after comparison, agree the counterfactual up front so your later claim survives scrutiny.

6. Track leading and lagging indicators together, and report them honestly. Watch adoption and usage as leading indicators from day one, because a benefit that depends on a system nobody uses is already dead. Confirm outcomes with lagging indicators over the profiled timeline. Report actuals against forecast on a fixed cadence to the portfolio board, including benefits that are behind or lost — a benefits report that only ever shows green is a fiction that will eventually cost you your credibility.

7. Track disbenefits and unintended consequences with the same rigor as benefits. Every worthwhile change produces some negative effects: new workarounds, alert fatigue, cohorts excluded by a digital-first channel, extra load shifted to another team. Name the anticipated disbenefits in the same register as the benefits, measure them, and act to reduce them. Hiding disbenefits does not make them disappear; it just means a clinician, a patient, or an auditor discovers them for you (see Topic 1.9 — Digital Inclusion & Accessibility).

8. Guard relentlessly against double-counting. The same released nursing hour cannot be banked by three different projects, and two systems cannot each claim the whole reduction in duplicate tests. Aggregate benefits at portfolio level with a deduplication check, attribute shared benefits transparently, and be especially skeptical of large workforce-time savings that never show up in the actual staffing budget. Double-counted benefits are how a portfolio's paper value drifts far above anything the organization ever banks.

9. Distinguish cashable from non-cashable and be honest about which you are promising. Boards and finance directors care intensely whether a benefit will actually reduce a budget line or merely release capacity that gets reabsorbed. Non-cashable time savings are genuinely valuable — they let you meet rising demand without more staff — but they are not the same as money you can redirect. Label each benefit clearly, and never let a non-cashable efficiency be counted as a cash saving in a savings program.

10. Hand over benefits ownership formally, and keep tracking after the program closes. Program and project closure is the single most dangerous moment for benefits, because the people who cared about them leave. Build an explicit benefits handover into closure: the benefit owner signs for each remaining benefit, the tracking mechanism is confirmed as operational, and the portfolio office assumes reporting responsibility. Schedule post-implementation reviews at the points where benefits are actually profiled to land — often 6, 12, and 24 months after go-live — and feed the results back into how you forecast the next investment.

Questions to discuss with your team#

1. Who will still be accountable for each of these benefits in two years, when the project team, the SRO, and half the leadership have moved on? This is the defining weakness of public-sector benefits management: the accountability chain is built around delivery, and delivery structures dissolve at go-live. Walk through your benefits register and try to name, for each line, the operational post-holder who will be measured on it long after the program closes — not the person, who may leave, but the role. Debate whether those owners have accepted the benefit, have the levers to realize it, and have it written into their own objectives and their service's plan. Consider the awkward cases: benefits that span two organizations in an integrated care system, or that depend on a national system your ICB does not control. A good, honest answer names a real operational owner for every benefit, admits which benefits are currently orphaned, and produces a concrete plan to re-home them before delivery ends rather than after.

2. How would we know if a benefit we declared as realized had quietly evaporated six months later? Many digital benefits are real at go-live and gone by the next winter: the workaround creeps back, a reorganization changes the process, staff turnover erases the training, demand rises and reabsorbs the released time. Discuss which of your claimed benefits are genuinely sticky and which depend on behaviors or conditions that could silently reverse. Examine whether you are still measuring anything after the celebratory go-live report, or whether tracking stopped the moment the money was released. Consider the difference between a one-off benefit (a decommissioned license) and a recurring one that must be continuously earned (a sustained reduction in duplicate testing). A strong answer distinguishes durable from fragile benefits, keeps lagging indicators running past closure, and treats a benefit as provisional until it has survived a full operational cycle — not banked the day the system went live.

3. Are we being honest about disbenefits, non-cashable savings, and double-counting — or are we telling the board the story it wants to hear? Benefits reporting is under constant pressure to look positive, because green boards approve funding and amber ones invite scrutiny. Challenge your own numbers: which "cash savings" are actually reabsorbed capacity that will never reduce a budget line? Where might the same released hour or avoided test be counted by more than one project across the portfolio? Which disbenefits — the excluded digital cohort, the alert fatigue, the extra load on a downstream team — have you left out of the register because they spoil the case? Discuss how your incentives push towards optimism and what independent check (finance, audit, a portfolio office) could hold the numbers honest. A good answer accepts that a smaller, credible, and independently verifiable benefit is worth more than a large one nobody believes, and it reports disbenefits and shortfalls as a matter of routine rather than confession.

4. Did we baseline the right thing, and would our before-and-after claim survive an auditor who assumes the world would have changed anyway? A benefit is only as trustworthy as the counterfactual behind it, yet most benefits claims are naïve before-and-after comparisons that quietly attribute every improvement to the system. Interrogate each headline benefit: what else was changing at the same time — a service reconfiguration, a new national target, a seasonal swing in demand, a workforce initiative — that could explain part or all of the movement? Discuss whether your baseline was captured before any change touched the process, frozen with an agreed definition, and paired with an explicit counterfactual rather than an assumption that the past would have simply continued flat. Consider the awkward cases where demand is rising, so holding a metric steady is itself a benefit, or where a comparator site or a segmented cohort would strengthen the claim. An honest answer can point to the specific baseline data, name the confounders it considered, and state plainly how much of the change it can and cannot defensibly attribute to the investment.

5. What is the total value picture across benefits, disbenefits, and the cost of realizing them — not just the headline savings we quote upstairs? It is easy to report a single large number and quietly ignore the resources and side-effects that number rests on. Value management asks you to weigh the whole ledger: the benefits, the disbenefits with a minus sign, and the often-unbudgeted cost of actually banking the value — the change management, the training, the decommissioning, the ongoing measurement effort itself. Discuss whether the effort of tracking a marginal benefit exceeds what the benefit is worth, and whether you are deliberately trading scope, cost, and benefit rather than treating the original business case as fixed. Consider benefits that are non-financial but real — safety, equity, staff wellbeing — and how you weigh them against cashable ones without pretending they share a currency. A strong answer treats value as a managed ratio across the whole investment life, is willing to descope a benefit that costs more to chase than it returns, and does not let an impressive gross figure hide a thin net one.

6. When a benefit depends on people across several organizations working differently, who owns the enabling change — and what happens if it never lands? In an integrated care system most benefits do not flow from the technology alone; they flow from clinicians, administrators, and social-care staff in separate organizations changing long-standing habits. This is where benefits realization and change management become inseparable, and where accountability is easiest to lose across organizational boundaries. Walk each significant benefit back to the specific behavioral or process change it depends on, and ask who — in which organization — owns making that change happen, and whether they have agreed to it. Discuss the failure cases: the trust that keeps the old system running "just in case", the partner organization whose staff have no logins, the process redesign that no single leader can mandate across the system. A good answer exposes every benefit whose enabling change is unowned or spans a boundary nobody controls, and it treats those as the real delivery risk rather than assuming go-live will carry the change for you.

In practice: a health & care example#

An integrated care system approves a £4.2m investment in a shared care record spanning three acute trusts, community services, and adult social care. The outline business case promises three headline benefits: a reduction in duplicate diagnostic tests worth £1.1m a year, 40,000 clinician and administrator hours released annually from chasing records, and improved patient safety from clinicians seeing a complete medication history at the point of care.

Rather than filing these in the business case and moving on, the program builds a benefits dependency network. It shows that the £1.1m in avoided duplicate tests depends not on the record existing but on clinicians actually checking it before ordering a test — an enabling behavioral change owned by each trust's clinical director, not the program. The 40,000 hours depend on decommissioning the old fax-and-phone process, which depends in turn on a records team being redeployed rather than quietly kept "just in case". Reading the map exposes that the safety benefit has no baseline: nobody currently measures medication-history-related incidents in a way that could later demonstrate improvement.

The program therefore does three things before go-live. It agrees a baseline for duplicate testing rates and medication incidents with each trust's finance and clinical-governance leads, freezing the definitions. It assigns named operational benefit owners — clinical directors for the testing and safety benefits, the ICS chief operating officer for the released-time benefit — each of whom signs a benefit profile with baseline, target, timing, and measurement method. And it agrees leading indicators (percentage of clinicians accessing the record, decommissioning of the fax line) to watch from week one.

Twelve months after go-live, the picture is honest and mixed. Adoption is strong and the fax line is gone, so the released-time benefit is broadly on track — but the ICS reports it as non-cashable capacity, not cash, because the hours were reabsorbed into clearing the elective backlog. Duplicate testing has fallen, though by £0.7m rather than £1.1m, and the program reports the shortfall alongside a plan to improve clinical prompting. A disbenefit has emerged: social care staff without trust logins are excluded, creating a new phone workaround, which is now on the register with an owner and a remediation date. The safety benefit is tracking but will not be confirmable until 24 months. The board trusts the report precisely because it is not all green.

Sector lenses#

Startup#

A digital-health startup lives or dies on demonstrating value fast, usually to a single trust or ICS running a pilot. Benefits realization is your commercial evidence base: the case study that wins the next contract is built on baselined, tracked benefits from the last deployment, so instrument value capture into the product from day one. Your risk is overclaiming — a slick dashboard showing a benefit the customer's finance director cannot reconcile will end the relationship faster than a modest, verifiable one. Agree the baseline and the measurement method jointly with the customer before go-live, and be willing to report a benefit that landed at 70% of forecast, because credibility compounds across sales cycles.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, or a single-site clinic — carries the same duty to show that a digital investment paid off, but with no portfolio office, no analyst, and a partner or manager doing benefits tracking on top of the day job. Keep the discipline proportionate: pick the two or three benefits that actually matter to your operation (released reception time, fewer duplicate tests, safer medicines reconciliation), baseline them with data you already collect, and track them simply rather than building a register you cannot sustain. Your realistic risk is not double-counting across a large portfolio but never measuring at all — declaring the system a success because it went live and the supplier's brochure promised savings. Because cash is tight and staff are few, be especially honest about cashable versus non-cashable: a freed half-hour only helps if it is reabsorbed into work you were struggling to do, and a subscription only pays for itself if a benefit you can name actually materializes. Where a supplier claims benefits for their product, ask them to help you baseline and measure on your own site rather than accepting the generic figure.

Enterprise#

A large NHS trust or ICS runs many concurrent investments, so its central challenge is aggregation without double-counting and sustaining benefits after each program closes. You need a portfolio office (see Topic 5.3 — Enterprise Project Portfolio Management) that maintains a single benefits register, deduplicates overlapping claims, and holds named operational owners to account through post-implementation reviews long after delivery teams disband. The organizational-change dependency is acute at this scale: most enterprise benefits require people to work differently across many services, which is why benefits realization and change management are inseparable (see Topic 8.1 — Change Management). Guard particularly against the workforce-time-saving that never appears in the staffing budget, because at enterprise scale those phantom savings add up to numbers the board will one day be asked to defend.

Government#

A national body — NHS England, DHSC, or a devolved government — operates under HM Treasury's Green Book, which mandates benefits appraisal, monitoring, and evaluation for every major program, with the Infrastructure and Projects Authority scrutinizing delivery. Here benefits realization is a matter of public accountability: benefits are stated to Parliament and the National Audit Office, and unrealized benefits become the subject of Public Accounts Committee hearings. The distinctive difficulty is scale and attribution — a national platform enables benefits that are actually realized by hundreds of local organizations you do not control, so your framework must distinguish the benefits you can bank centrally from those you can only enable and must ask others to track. Build evaluation and real-world data collection into the program from the outset (see Topic 8.6 — Research & Real-World Evaluation), because at national scale "we believe it worked" is not an acceptable answer.

Common failure modes#

• Benefits by assertion. The business case claims large savings with no baseline, no owner, and no measurement plan; the numbers were reverse-engineered to clear the approval threshold and were never meant to be tracked.
• Orphaned benefits. Every benefit is "owned" by the project, so when the project closes, ownership evaporates and no operational post-holder is accountable for realizing anything.
• The go-live fallacy. Success is declared the day the system goes live, tracking stops, and the benefit — which was profiled to land 18 months later — is neither confirmed nor chased.
• Double-counting across the portfolio. The same released hour or avoided test is banked by several projects, inflating the portfolio's paper value far above what the organization ever actually captures.
• Cashable/non-cashable confusion. Reabsorbed capacity is reported as cash savings, a savings program is built on it, and the money it assumed never appears in any budget.
• Ignored disbenefits. The excluded cohort, the new workaround, the alert fatigue are left off the register because they weaken the case — until a serious incident or an audit surfaces them.
• Optimism-only reporting. Benefits reports are permanently green, so the board loses the ability to distinguish a genuinely healthy investment from a failing one, and trust in all benefits reporting decays.

Maturity model#

Checklist#

• Every benefit in the business case has a named operational owner who has accepted it and has it in their objectives.
• Each benefit is profiled with a baseline, target, measurement method, data source, and expected timing.
• A benefits dependency network links each delivered capability to enabling changes, outcomes, and strategic objectives.
• Baselines are agreed with finance and the benefit owner and frozen before any change is deployed.
• Each benefit is classified as cashable or non-cashable and as financial or non-financial, with no reabsorbed capacity mislabeled as cash.
• Leading indicators (adoption, usage, decommissioning) are tracked from day one alongside lagging outcome indicators.
• Anticipated and emerging disbenefits are on the register with owners and remediation dates.
• Portfolio-level aggregation includes an explicit deduplication check against double-counting.
• A formal benefits handover occurs at program or project closure, with the portfolio office assuming reporting responsibility.
• Post-implementation reviews are scheduled at the points benefits are profiled to land (e.g. 6, 12, 24 months), and results feed back into future forecasting.
• Benefits reports to the board show actuals against forecast, including shortfalls, lost benefits, and disbenefits.

Key sources#

• HM Treasury, The Green Book: appraisal and evaluation in central government — the mandatory UK basis for benefits appraisal, monitoring, and evaluation.
• HM Treasury / Infrastructure and Projects Authority, Guide for Effective Benefits Management in Major Projects — practical public-sector benefits management guidance.
• Managing Successful Programmes (MSP), PeopleCert/AXELOS — the UK programme framework that places benefits management at its core.
• Management of Portfolios (MoP) and the APM Body of Knowledge — portfolio-level benefits aggregation and value management.
• NHS England guidance on benefits management and evaluation for digital programmes, and the What Good Looks Like framework.
• National Audit Office and Public Accounts Committee reports on realising benefits from government digital programmes.

References#

1. Benefits realisation management — Wikipedia — https://en.wikipedia.org/wiki/Benefits_realisation_management
2. Program management — Wikipedia — https://en.wikipedia.org/wiki/Program_management
3. Business case — Wikipedia — https://en.wikipedia.org/wiki/Business_case
4. Cost–benefit analysis — Wikipedia — https://en.wikipedia.org/wiki/Cost%E2%80%93benefit_analysis
5. Performance indicator — Wikipedia — https://en.wikipedia.org/wiki/Performance_indicator
6. Value engineering — Wikipedia — https://en.wikipedia.org/wiki/Value_engineering
7. Logic model — Wikipedia — https://en.wikipedia.org/wiki/Logic_model
8. Theory of change — Wikipedia — https://en.wikipedia.org/wiki/Theory_of_change
9. Unintended consequences — Wikipedia — https://en.wikipedia.org/wiki/Unintended_consequences
10. Project portfolio management — Wikipedia — https://en.wikipedia.org/wiki/Project_portfolio_management
11. The Green Book: appraisal and evaluation in central government — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government
12. Guide for Effective Benefits Management in Major Projects — Infrastructure and Projects Authority / HM Treasury — https://www.gov.uk/government/publications/guide-for-effective-benefits-management-in-major-projects
13. Managing Successful Programmes (MSP) — PeopleCert / AXELOS — https://www.axelos.com/certifications/propath/msp-programme-management
14. What Good Looks Like framework — NHS England — https://www.england.nhs.uk/digitalhealth/what-good-looks-like/