The reluctant benefits manager: Doing just enough, properly

Someone's tasked you with the benefits documentation for a programme. No background, no training, no interest in acquiring either 鈥� you're back to normal duties the moment it's done. You want the minimum viable version, good enough to pass scrutiny.

Good benefits management means talking to stakeholders, those done-to, those who'll benefit, however, we don't always have that luxury.

The two things that matter

Basic benefits management comes down to two things: a Benefits Dependency Network (鈥淏DN鈥�) and a benefits register. Apply the defined approach, don't invent a new one.

A BDN is a logic chain read in two directions. Right to left, from Objectives, it answers 鈥渨hat has to be in place to get this?鈥� Left to right, from what the project delivers, it answers 鈥渨hat does that produce?鈥� Draw it correctly and a steering group can interrogate it in moments, rather than take a narrative on trust.

Get the vocabulary right before you do anything

The single most common failure is calling the wrong things 鈥渂enefits鈥�. Project documentation usually labels whatever it delivers as 鈥渂enefits鈥�: those are Outputs. Use a consistent set (BS 202002's is as good as any): Activities (what we do), Outputs (what we produce), Outcomes (how the organisation changes), Benefits (what improves, and what that's worth 鈥� or costs, if it goes wrong), Objectives (why we're doing this). Get this right first. Everything else follows from it.

There's flexibility, but the recommended minimum is four columns: Outputs, Outcomes, Benefits, Objectives. Add a Change column between them only if you can't see how to get from one to the other without it.

Leave Activities off

Your project plan already lists activities and outputs, so adding them to the BDN too is usually just duplication. There's a less flattering reason: activities is the column where volume looks like virtue 鈥� list forty activities and everyone can show how busy they are, at the cost of a readable BDN. Leaving the Activities column off removes a busy but unhelpful bit.

Drivers and Enablers: know what they are before adding them

Some people add these as columns. I鈥檇 argue they don鈥檛 belong on a BDN.

A Driver isn't another rung between Benefits and Objectives 鈥� it's the reason the objective exists: the regulatory deadline, the competitive pressure, the ministerial commitment. Nothing flows from a Driver into a Benefit, so giving it a column implies a causal step that doesn't exist. Treat it as an annotation on Objectives, not a link in the chain.

Enabler could mean two unrelated things depending on who's using it. Ask 鈥渆nabler of what?鈥� It's either an Activity by a fancier name, and I recommend not including Activities on the BDN 鈥� or an external dependency or assumption, outside the project's control. If it鈥檚 external, flag the dependent Outcome rather than showing the dependency itself.

Avoid making a cat's cradle

A logic map only means something if it shows causal connections 鈥� but it's tempting to draw too many. Only draw a link from Output to Outcome, from Outcome to Benefit and so on where the contribution is critical or substantial: 鈥渋t contributes a bit鈥� is noise, and noise makes a BDN unreadable. Then read the map for two failure patterns:

An orphan: Something on the right with nothing feeding it 鈥� a benefit or outcome with no credible route to it. The 鈥渕iracle鈥� business case, in diagram form.
A dead end: Something on the left contributing to nothing 鈥� wasted effort, scope creep, or a benefit nobody's found yet.

Either way, finding these before your steering group does is where the value of the BDN lies.

Your first attempt is probably wrong

Expect it 鈥� you probably put Outputs and Outcomes into Benefits. Restart the top-level programme BDN until it holds together, before you start drawing theme-level ones. Don't draw one BDN per workstream 鈥� workstreams typically serve several benefits at once; themes relate to specific use cases.

The benefits register

The high-level BDN lists summary benefits, often too high-level to measure directly. For something you can report, you need component benefits (also called specific or child benefits), the ones you can actually track.

The register is where component benefits live, one row each, detailed enough for someone else to pick up. At minimum: name, description, category (financial/non-financial, cashable/non-cashable, qualitative), baseline and target, lead and lag measures (lead gives early warning; lag confirms it happened), review date, and owner. The Government Project Delivery Function template is as good a start as any.

Owner is the column people often get wrong. Every benefit needs someone accountable for realising it, although someone else might do the actual work. Ideally the owner is someone with real standing in the user base, whom the people who need to change will actually listen to. Doing the minimum, you likely won't have recruited them yet: default to the sponsor as interim owner, explicitly 鈥� they've the seniority to hand over once the right person's found. No named owner, or one never told they own it, is why benefits don't happen.

There you have it 鈥� Minimum Viable Product benefits management. Minimum viable Benefits Dependency Network, minimum viable Benefits Register. Not how it engages stakeholders, breaks down barriers, or supports scope-change decisions, but the minimum documentation that works.

Partly AI supported; human-validated