Seven deadly sins of benefits management

This article is about the new British standard on benefits management: applying benefits management on portfolios, programmes and projects — A guide. There’s also a launch video recording.

There are ways to do benefits management correctly, and there are common practices that are toxic. As you read these, the Seven Deadly Sins, consider whether you have seen them in practice and comment below with your experiences — without naming the organisation, of course!

1. Shoot first, then name your target

Many projects start with a good idea. Sometimes it really is good, but often the decision is taken, investment is committed, and only then do the project team assemble the benefits team to try to justify the decision. Because of commercial considerations, the deliverable or project specification might be changed to the point where the big benefit isn’t going to happen.

As a benefits manager, your task is:

To try to find the real reason behind projects, and then to make sure that it’s visible when there are decisions to be made about committing or changing the investment. Why you are doing it will change how you deliver the project, and how you communicate.

2. And then a miracle occurs

Perhaps the most common of the deadly sins: the business case is a list of wonderful benefits that everyone wants, and a list of activities that need investment, but limited or absent explanations of how the activities will cause the benefits.

As a benefits manager, your task is:

To show (usually via a benefits map), where the gaps are that mean benefits are unlikely, and the likely consequences (in benefits and dis-benefits) of the currently proposed activities. You’re there to inform the specification.

3. “Mandatory” programmes don’t need benefits

How often have you heard this; “My programme has to be done anyway, so there’s no point in benefits management”? How much of their programme needs to be done, how much is gold plating, extra things they want, and besides, how important is “mandatory”?

Every regulatory requirement has a value (how much it would cost not to meet that target) and a cost to make the changes. If missing a regulatory requirement means that your organisation would have to cease trading in a particular marketplace, there’s a decision to be made. If it will result in a fine, there’s a price of the benefit to weigh up against the cost.

As a benefits manager, your task is twofold:

Put a number on “mandatory”, so a sensible decision can be made whether to comply or accept the consequences.
Use a benefits map to show which activities in the project contribute to the mandatory requirements, and which do not.

4. Count every benefit, forever

With enough time, and enough benefits, anything can be justified. And if anything can be justified, how do you know what to do?

The British standard tackles this conundrum (and you should too):

Benefits are valuable in the context of the portfolio, so there’s no point in overperforming on one benefit and underperforming on another. Which project gets resources should be revised in the light of performance.
Set a time guillotine for when the change will be replaced with another. Benefits don’t count after this guillotine. If a project is delayed, then benefits get pushed past the guillotine, and the overall benefits that the project delivers before the guillotine will be less.
Prioritise a few big benefits; if an investment can’t be justified with a few big benefits, then it probably doesn’t solve a definite problem.
No double-counting; attribute a single benefit across the projects that contribute (by percentage) and accept that some projects won’t get funded.

5. No Consequences

It's not enough to name a benefits owner, they have to pull the necessary strings and direct the necessary changes in processes and behaviours that realise benefits. This only happens if there are consequences, if failure or success to realise a benefit is measured and reported, and makes a difference to people’s careers and reputation.

It cannot be emphasised enough that benefits are the why of projects, and if we don’t answer why, then we’re just dreaming and imagining.

As a benefits manager, you should:

Ensure that lead and lag measures are in place for each of the biggest benefits.
Report the results and forecasts along with the rest of project reporting.

6. Money is the top priority

Direct financial return is rarely the reason why we do things — and that applies to major investments too. Non-financial returns can be valued with a financial equivalent and British Standard BS8950, on Social Value, explains this. When the project team has tunnel vision on financial goals alone, it misses the nuances that make-or-break success.

The benefits manager should:

Ensure that non-financial benefits and non-cashable benefits can be measured and reported.
Measure and report them.

7. My project is the only thing that matters

Many successful project managers owe their success to their brutal focus on achieving their goals at a cost to everyone else. Have you ever had resources and skills taken from your project even though they have failed, but they have a loud voice?

On the other hand, organisations are successful because of their portfolio of projects (as well as the way they execute day-to-day activities, of course). A project is just a small cog in a big machine.

The benefits manager should:

Return the focus to realising portfolio benefits as a result of a balanced realisation of individual project benefits.
Ensure that individual project teams are held to account where their benefits disrupt activities across the portfolio, and where remedial action needs to be taken by other projects.

I wonder how many of these seven deadly sins you see in your own organisation? Do you have a complete bingo card — all seven? Write and let me know!