Benefits management

A business case is a promise about benefits. Benefits management is how the organization keeps that promise: by defining each benefit precisely, assigning an owner, planning how and when it will be measured, and checking after the project whether it has been realized. PRINCE2 records this in a management product called the benefits management approach, which is created during initiation and used during and after the project. Earlier editions used the name benefits review plan for a similar product. This lesson explains how benefits are defined, mapped, measured and reviewed, and what happens when they fall short.

Benefits management sits awkwardly with the idea of a temporary project. Most benefits appear only after the project has closed and its team has dispersed. That is precisely why PRINCE2 makes the senior user accountable for benefits and requires the benefits management approach to continue beyond closure, with responsibility passing to the business layer. A project that delivers its outputs perfectly but leaves no one responsible for the benefits has done only half its job.

Defining a benefit well

A benefit is a measurable improvement resulting from an outcome, perceived as an advantage by one or more stakeholders, which contributes towards one or more organizational objectives. A well-defined benefit has a description, an owner, a measure, a baseline, a target, a timescale and a note of the outcome it depends on. Vague benefits such as improved efficiency cannot be measured and therefore cannot be managed.

The dependent outcome is easy to overlook and often decisive. Ridgeline Water's leak saving depends entirely on customers acting on alerts. If alerts are ignored, the meters can work perfectly and the benefit still fails. The benefit definition therefore points straight at a change management activity: designing alerts that customers understand and follow up, which belongs in the plans as products such as customer communication materials and a follow-up process.

Benefits maps

A benefits map traces the links from the project's outputs, through the outcomes that people achieve by using them, to the benefits and the organizational objectives they support. Maps help in three ways: they check that every benefit has a credible causal path, they show which outputs matter most, and they expose benefits that depend on the same outcome, so that a single failure would affect several.

The map shows that two benefits, less water lost and lower pumping energy, both depend on customers fixing leaks. Together they make up about 890 thousand of the 1,420 thousand annual gross benefit, so this single outcome carries nearly two thirds of the case. A good map makes that concentration of dependence obvious, which in turn tells the board where to direct assurance.

Benefit profiles and tolerance

Benefits rarely arrive all at once. A benefit profile shows the expected value over time, often rising as the change beds in. The business case should use realistic profiles, not the full annual value from the first day. PRIN-110 introduced benefits tolerance: the permissible deviation in expected benefits before the matter must be escalated. Benefits tolerance is set by the business layer for the project as a whole and is usually expressed as a range or a minimum level.

# expected annual leak saving ($000) as districts go live, and actuals measured so far
expected = {1: 160, 2: 420, 3: 640, 4: 640, 5: 640}
actual = {1: 150, 2: 330}
tolerance = 0.15          # benefits may fall 15 % below expected before escalation
for year, exp in expected.items():
    if year in actual:
        a = actual[year]
        shortfall = (exp - a) / exp
        flag = "ESCALATE" if shortfall > tolerance else "within tolerance"
        print(f"year {year}: expected {exp:4}  actual {a:4}  shortfall {shortfall:5.1%}  {flag}")
    else:
        print(f"year {year}: expected {exp:4}  (not yet measured)")
# simple forecast: assume the year-2 realization rate continues
rate = actual[2] / expected[2]
forecast = sum(expected[y] * (actual[y] / expected[y] if y in actual else rate) for y in expected)
print(f"five-year forecast {forecast:.0f} vs plan {sum(expected.values())}")

year 1: expected  160  actual  150  shortfall  6.2%  within tolerance
year 2: expected  420  actual  330  shortfall 21.4%  ESCALATE
year 3: expected  640  (not yet measured)
year 4: expected  640  (not yet measured)
year 5: expected  640  (not yet measured)
five-year forecast 1989 vs plan 2500

In year 1 the shortfall is about 6 %, within tolerance. In year 2 it is about 21 %, outside the 15 % tolerance, so the matter must be escalated: during the project, the project manager raises it with the board; after closure, the senior user reports it to the business layer. If the year-2 realization rate continued, the five-year total would be about 1,990 thousand against a plan of 2,500 thousand. The point of the calculation is not precision but early warning: a forecast shortfall triggers investigation while there is still time to act.

The benefits management approach

The benefits management approach describes how the benefits will be measured and reviewed, by whom and when. It covers the scope of benefits to be reviewed, the accountability for each, how and when each will be measured, the resources needed for measurement, the baselines against which improvement will be judged and how the performance of the outputs in operation will be reviewed. In plain terms, it is the plan for proving that the business case came true.

Two points deserve emphasis. First, baselines must be measured before the change; once the change starts, the before picture is gone. Many organizations discover too late that they cannot prove a benefit because nobody recorded the starting position. Second, measurement costs money and staff time, which must be included in the plans and the business case. A benefit that would cost more to measure than it is worth may be better described qualitatively.

Benefits during the project

Some benefits begin during the project, especially when a project delivers in stages or districts. Ridgeline Water's rollout goes live district by district, so leak and reading savings start before the project closes. Benefits realized during the project should be measured and reported at stage boundaries. They are valuable evidence for the board: if early districts show lower savings than forecast, the business case for the remaining districts may need revisiting before more money is spent.

Benefits after the project

When the project closes, responsibility for benefits passes from the project board to the business layer, usually through the senior user's line management. The benefits management approach should be handed over with named owners and review dates. Post-project benefits reviews compare measured benefits with the business case, look at whether outputs are performing as expected in operation, and identify any further action needed to realize benefits. They also feed lessons into future business cases, which helps organizations calibrate their optimism.

Optimism bias is a well-documented tendency for planners to overestimate benefits and underestimate costs and durations. Post-project reviews are one of the few ways to correct it, by giving organizations real evidence of how their past forecasts turned out. An organization that never reviews benefits will repeat the same optimistic assumptions in every business case.

Dis-benefits and side effects

Dis-benefits are managed in the same way as benefits: defined, owned, measured and reviewed. Ridgeline Water has two. Some customers object to detailed consumption data, and billing errors may rise briefly during cutover. Naming them allows the project to plan responses, such as a clear privacy notice and a temporary billing support team, and allows the board to judge whether they are acceptable. Hiding dis-benefits makes a business case look better but leaves the organization unprepared.

For Ridgeline Water, privacy concerns are not only a reputational matter. Detailed consumption data are personal information, and Canadian privacy law applies: public bodies are typically covered by provincial public-sector privacy legislation, and private organizations by PIPEDA or substantially similar provincial laws. The project's products should therefore include a privacy impact assessment and a privacy notice, which belong in the plans.