Benefits Management

Goal

The UK government's Infrastructure and Projects Authority (IPA) defines benefits management as the identification, definition, tracking, realisation and optimisation of benefits. A benefit is a measurable improvement that at least one stakeholder sees as an advantage and that contributes to an organisational objective. The technique turns the promise of a business case into a benefit measured in the organisation's daily work.

The benefit follows from what the project delivers without being the same thing. An online counter is a deliverable; the visits it saves at the counter are the benefit. Peppard, Ward and Daniel derive the technique's principle from this: a technology has no value in itself. Benefits appear when people work differently. Only business managers and users can realise them. The three authors study IT investments. The reasoning holds for any change that alters the way people work.

The technique answers the question the business case leaves open: does the funded change produce what it promised? The business case and cost-benefit analysis appraise the change before the funding decision. Benefits management continues after the project's technical closure until each benefit is achieved or abandoned. The IPA names the opposite error: the widespread belief that benefits management starts and ends with appraising the business case.

The deliverable is a set of documents kept up to date: the benefits register, a profile per benefit, the realisation plan, the handover certificate and the benefit reports. The PMBOK Guide describes a single document: the benefits management plan. It files the plan among the business documents beside the business case because both are created before the project and remain in use after its closure.

Usage

When to use it

• Approved business case: turn each promised benefit into a named, measured and dated commitment.
• Change whose value depends on use: a new system, a new process or a reorganisation that the teams must adopt.
• Benefits that arrive after closure: organise the handover to the business managers and the measurement in the months after closure.
• End of phase: check that the expected benefits still justify the next phase. In HERMES, the project sponsor decides every phase release.
• Programme or portfolio: track benefits that several projects produce together for the same objective.
• Disputed benefits: a measured baseline shows whether the problem exists before the budget is committed.

When not to use it

• Low-value change: tracking costs more than the gap it would detect; acceptance criteria checked at acceptance testing are enough.
• Compliance or like-for-like replacement: nobody changes the way they work; track the service level with metrics and KPIs.

Description

Benefit, disbenefit, owner

Peppard, Ward and Daniel cite a bank that delivered a USD 10 million customer relationship management system on time and on budget. The system produced no immediate benefit. The bank had not identified the changes to working practices that those benefits required. It had concentrated on deploying the technology.

A benefit that cannot be measured cannot be claimed. "Better resident satisfaction" becomes a benefit once you know which indicator measures it, from which source and how often.

A disbenefit is a measurable decline that a stakeholder sees as negative. The IPA asks for it to be managed like a benefit, with a measure and an owner. It distinguishes the disbenefit from a risk: the disbenefit is expected; the risk is uncertain. The same change can be a benefit for one group and a disbenefit for another. A counter that closes on Saturdays saves staff hours. Residents who work during the week lose hours in return. A disbenefit left out of the business case resurfaces in complaints.

Each benefit has an owner: the business manager who will have to bring about the changes to working practices. Peppard, Ward and Daniel write that this owner is accountable for the value the business case attributes to the benefit. A benefit assigned to the project manager or to IT has no owner: neither manages the people who must work differently. According to the IPA, the sponsor is accountable for the business case and the benefits. The guide calls this role the Senior Responsible Owner; HERMES calls it the project sponsor. The benefits owners realise the benefits. A benefits manager runs the process, keeps the documents and prepares the reports. A RACI matrix records this split for each activity.

The cycle

The IPA describes six practices. They do not necessarily follow one another in order. The guide repeats them at every stage of the project. Its cycle is aligned with the one in the APMG's Managing Benefits. The IPA states that its guide is not prescriptive: each organisation scales the documents to what is at stake.

Define success

Before looking for benefits, the sponsor and senior management tie the change to the organisation's objectives and say how they will recognise success. Peppard, Ward and Daniel ask the questions that lead from there to the plan:

1. Why do we need to improve?
2. What improvements are necessary or possible?
3. What benefits does each stakeholder gain from them and how will they be measured?
4. Who owns each benefit?
5. What changes to working practices are needed to realise the benefits?
6. Who is responsible for each change?
7. How and when can these changes be made?

The last three questions separate the technique from an investment appraisal. They link each benefit to the changes that produce it. The benefits dependency network starts from the objectives and draws this link from right to left.

Identify and quantify

The team identifies the benefits in a workshop with the key stakeholders. Each benefit gets a unique identifier that follows it from the register to the reports. The team prioritises the benefits, then sorts them into the categories the organisation uses, for example financial or non-financial, budget saving or capacity gain. The IPA's categories are specific to the UK government; a Swiss organisation uses its own.

Each measure gets a baseline. It is taken at initiation, before the project changes the level being measured. It confirms that the problem exists and gives the starting point of the gain. A value taken after work has started measures a situation the project has already disturbed: a team that trains its staff on the new system produces less during the training. The gain measured later then looks bigger than it is.

Each benefit gets a numeric, dated target. Until the option is chosen, the IPA accepts "to be confirmed". The prospective owners are named at this stage.

Value and appraise

The team converts quantified benefits into Swiss francs wherever the gain has a known price. These amounts feed the cost-benefit analysis and the business case. A freed hour becomes a budget saving only if the organisation cuts the post or drops an expense. Reassigned to other tasks, it remains a capacity gain, which the register records as such.

The trap in this practice is overstatement. Peppard, Ward and Daniel cite a survey of the 200 largest UK companies: 47% of respondents admitted to overstating benefits to obtain approval. The owner who signs the target defuses this trap because the owner will be accountable for it after closure.

Plan to realise

For each benefit, the realisation plan sets who measures, with which source, how often and to which body the results are reported. The data needed goes into the system requirements and into the supplier contracts. An indicator that nobody planned to extract cannot be measured after go-live. Benefit dependencies go into the project's risks, actions, issues and decisions (RAID) log. Risks to a benefit enter risk analysis and management like any other risk.

Before handover, the body that approves the final business case also approves the plan with the cost of measurement, the roles and the governance. If much time has passed since initiation, the baselines are taken again.

The PMBOK Guide's benefits management plan contains the target benefits, strategic alignment, the timeframe for realisation, the benefit owner, the metrics, the assumptions and the risks. The PMBOK Guide states that the plan is developed and updated iteratively.

Work to realise

At handover, the sponsor and each owner sign the handover certificate. Responsibility for the benefits then passes from the project to the business managers. The project disbands afterwards. Without this signature, the register has no reader left.

A partial delivery sometimes produces benefits during the project; these are tracked with the costs and milestones. The others are measured as soon as possible after delivery. When the change alters the way people work, the IPA advises waiting at least six months before the first measurements. A measurement taken too early captures the learning period. It concludes that a change has failed when it has not yet taken hold.

The reports go to a body that can confirm a realised benefit and fund corrective action. A committee with no power to act notes the figures and changes nothing. Each report pairs the data with a commentary: why the gap, what action, what next measurement. The project status report carries these figures for as long as the project exists.

Review performance

Reporting continues until each benefit is achieved or abandoned. A post-implementation review answers the IPA's questions. Was the business case delivered? Was the benefits management process effective? Was its effort proportionate? Were the models and assumptions accurate? What lessons can be drawn? The measured values then replace the estimates in the benefits models, which feed the next business cases.

In Switzerland, HERMES 2022 provides for this check. The final project evaluation sets the content and deadlines for project success monitoring. Some time after closure, the user organisation can check whether the impact the sponsor expected has occurred.

The trap in the review is the ticked box. The IPA cites Openreach, whose business case template requires citing two earlier cases as lessons learned. The team writing the next case must read the earlier reviews. The review then stops being a formality.

AI considerations

A language model speeds up the documentation work. From a business case and workshop notes it extracts a first list of benefits, separates them from deliverables and proposes an indicator and a data source for each. It reads the register and flags lines with no owner, no baseline or no date. It drafts a report's commentary from the month's figures and groups the findings of several post-implementation reviews.

It sets neither a target nor an owner. The target is a commitment that the owner signs; a value proposed by a model commits nobody. Nor does it decide whether a gap comes from the project or from another factor such as population growth or a change in the law. That attribution requires local knowledge. A model also picks up the optimism of the text it is given and formats it. Finally, measurement data often concerns people: residents' files, processing times per employee. A company or the federal administration applies the Federal Act on Data Protection (FADP). A municipality or a canton applies cantonal law; in the canton of Vaud, this is the LPrD. Either one sets the conditions for sending data to a hosted service.

Examples

After the project ends, the owner keeps the benefit profile up to date and compares each measurement in it with the baseline and the target. A municipality in the canton of Vaud puts the arrival and departure notification for residents online. The fictitious profile of benefit B-03 covers the first year after go-live.

The profile files the freed hours as a capacity gain. They only become francs if the municipality cuts a post or drops an expense. The business case did not plan for that. The disbenefit exceeded its ceiling at six months and then fell back below it: without this line, the committee would only have seen the drop in visits.

Visualisations

The cycle places the practices before, during and after the project. In it, the handover certificate marks the moment when responsibility changes hands. The example's curve shows the lag between go-live and the benefit. It places the monthly counter visits between the baseline and the target.

Cost

Tooling

A spreadsheet is enough for the register and profiles of a medium-sized project: one line per benefit, one column per dated measurement. A shared list in SharePoint or a similar tool keeps the register accessible to the owners after the project team disbands. Project portfolio management tools hold benefits registers linked to projects and programmes; they help when several projects feed the same benefits. At closure, the team transfers the register held in the portfolio tool to the business managers. Without this transfer, the register leaves with the team.

The measurements come from business applications: queue management, ERP, request management. A dashboard tool such as Power BI or Tableau reads these sources and produces the curves in the reports.

Sources

• HM Government, Infrastructure and Projects Authority, Guide for Effective Benefits Management in Major Projects, October 2017: the definitions of benefit, disbenefit and benefits management (§3); the six practices of the cycle, their repetition at every stage, the baseline, the target, the plan, the handover, the six-month wait before measurement and the post-implementation review (§7); the roles (§8); the documents (§9); the Openreach case.
• Joe Peppard, John Ward and Elizabeth Daniel, "Managing the Realization of Business Benefits from IT Investments", MIS Quarterly Executive, 6(1), 2007: the principles of benefits management, the responsibility of business managers, the seven planning questions, the bank case and the survey on overstated benefits (Ward, Taylor and Bond, 1996, cited by the authors).
• PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th ed., section 4 Inputs and Outputs: the benefits management plan, its elements, its iterative nature and its status as a business document beside the business case.
• Swiss Confederation, Federal Chancellery, HERMES 2022, Project management reference manual: the task 5.4.3.35 Prepare project closure for the success check after closure; the outcome 4.4.1.35 Final project evaluation for its content and deadlines; the sponsor's decisions (5.1.2.2 and 7.4.1) for phase release.