It's all about the why: the benefits manager's role in practical project delivery

Have you delivered a project on time and on budget, but nothing changes in the operations of the organisation? I've seen it happen more times than I care to count. The project team celebrates a job well done, but the business never gets the value it was promised. The output (what the project does) is delivered, but the outcome (change in the business) never materialises, and ultimately, there’s no return on investment. So, what went wrong, and how do we fix it?

The missing piece is often benefits management. Without benefits, why did we do the project in the first place? Yes, I know we might have to meet a regulatory requirement but failing to meet that requirement has a price and avoiding the need to pay that price is the benefit (which allows us to do a Cost Benefit Analysis and decide if the benefit is worth the cost of the project). I know that we have this concept called “enabling projects” but this can be used as an excuse to push a project through without proper scrutiny. If it enables other projects, then what is the total benefit and how does the total CBA stack up? Projects are only worth doing if they deliver benefits.

And that's where the benefits manager comes in. We're not just a person who presents some numbers; we're the bridge between a project's technical delivery and its ultimate purpose.

I see the benefits manager as an ambassador. One part of our job is working with stakeholders – the people who will be using the project's output every day, or who are impacted by it. The benefits manager needs to help these teams prepare for the change, helping them understand what they need to do differently to get the most out of the project. This includes embedding new ways of working and might involve a significant lead up time where new roles have to be defined, recruited to and trained.

The other part of our job is to act as a reality check for the project team. We understand what the stakeholders want—especially those contributing to the investment—and recognise that their expectations may change as they gain a better understanding of what they’re going to receive.

We, the benefits managers, support the project leadership in adjusting the specification to deliver an optimal solution—optimal in the sense that it provides the maximum benefits (i.e. what stakeholders can effectively use) for the available investment, or makes a case for a different investment based on potential benefits.

We keep a close eye on the project as it progresses to ensure it hasn’t gone off course. I like to use benefits “lead measures,” which some people refer to as intermediate benefits. These give us early indicators of whether we’re on the right track—early enough that we still have time to adjust the project specification or scope if needed.

For example, if we're building a new system to reduce customer complaints, an early lead measure would be a causal chain (what causes customer complaints, and what changes might make a difference to customer complaints) agreed by stakeholders, and a later lead measure would be the success or otherwise of a pilot deployment. If things go as you predict they will, it’s a good sign. If you don't, you know you need to adjust something before it’s too late and you’re trying to hand over something that doesn’t meet anyone’s needs or justify the investment.

Who should the benefits manager report to? 

Now, who should this benefits manager report to? The major courses (MSP, MoP, PMI courses on programmes and portfolios) argue that they should report to the project manager, but I don't believe that's the best approach. The project manager is rightly focused on the 'what', 'when' and ‘how’ of delivery. The sponsor, on the other hand, is the person accountable for the 'why'—the benefits. The benefits manager is the sponsor's secret weapon, the doing person for their job. The sponsor presses the flesh, but someone still needs to go and talk to people, to challenge the rest of the project leadership team, to inform the sponsor if the stakeholders aren’t happy but the project is to time and to budget. 

I’ve had project managers complain about benefits management. The complaints seem to fall into two categories:  

1. Why don’t they just give me the money and leave me alone to get on with it? (because we know you will rescope until it’s easy to claim success, but it won’t be what’s actually needed); and  
2. This is just causing extra work (but failing to plan is planning to fail).  

The benefits manager needs the authority to challenge the project leadership, and to hold stakeholders to account so they change their processes and behaviours. Whilst this authority is rightly in the purview of the sponsor, the sponsor is a senior (strategic) role rather than a doing role. The benefits manager is a pragmatic and powerful way to align project work with business objectives. 

How might you (as benefits manager) apply this on your next project?  

1. Instead of just creating a list of benefits and putting a hypothetical value, work with your stakeholders to build a benefits map, starting with finding agreement on objectives (how it contributes to the organisation’s success) and outcomes (what needs to change in the business) and benefits these outcomes will create. The project outputs come out of the required changes.  
2. Assign someone (maybe yourself) to keep an eye on the lead measures and be prepared to challenge project leadership if the stakeholders aren’t going to get benefits.  
3. Use the sponsor for leverage. 

It's a simple change, but it's one that can shift your focus from simply finishing a project to truly helping the organisation to succeed. 

You may also be interested in:

• What is benefits management and project success?
• APM Benefits and Value Interest Network
• How to close projects successfully