There’s always a risk when you’re working on projects that you invest the detail of the process with a spurious, level of authority. Let’s take the example of benefit mapping. Ostensibly a wonderful tool for demonstrating causality and providing sponsors and stakeholders with a tangible picture of what you are going to deliver.
The trouble is that you need an experienced and sophisticated sponsor to be able to interpret and question the map, rather than take it at face value.
For other, less sophisticated sponsors, I suggest there are just three questions you need to ask and answer to make sense of benefits.
1. Benefits are dependent on people changing their behaviours (Bradley, 2010). So you need to spend time understanding what the desired behaviours are and how your project will encourage users to adopt these behaviours. This is true whether you are creating a new product or service; whether you are developing Government policy or simply trying to introduce new software to your business.
Ask yourself: ‘what am I expecting people to do as a result of my project? How am I expecting them to behave?’
2. Only users (customers, citizens, employees) can realise benefits (Driver, 2014). This means that you need to be rigorous demonstrating the logic behind your benefits map. For example, imagine you are mapping out a project to reduce the pressure on hospital accident and emergency departments. You have two choices: you can accept that patients want to use accident and emergency and divert resources to increase capacity. Alternatively you can develop information, services and model behaviours that encourage them to other healthcare solutions. In both cases, your benefits hinge on what patients choose to do.
Ask yourself: ‘why will people change their behaviour as a result of my project and what happens if they don’t’.
3. Project Sponsors are responsible for benefits (West 2010). Your sponsor needs to be asking the project team the kind of questions, I have indicated above. If you hold your sponsors to their responsibility, it makes project governance considerably easier. Rather than defining how and at what stages the sponsor should interact with the project team, giving them a responsibility for benefits means they need to be confident that the project, as designed, will encourage the kind of user-behaviours needed to realise the benefits. They need to work with the project team in whatever way is appropriate to assure this result.
By extension, they also need to ensure the project has the requisite resources to deliver what is needed. Any budget cuts, changes to the project or indeed, the decision to continue or close the project, should be assessed against these fundamental questions.
Ask yourself, as sponsor, as a result of this project, do I understand:
- What we are expecting people to do?
- How and why the project will enable and encourage them to do it?
- What will happen if they don’t do it?
- What the project needs in order achieve these outcomes?
- Whether and how the value of these behaviours or our ability to influence them is changing through the project?
Don’t get me wrong. Benefits mapping is extremely useful, particularly in large and complicated projects where different individuals and different users may influence different behaviours. And these apparently simple questions won’t necessarily help you with the process, technology, raw materials and cost of your project but they are very useful check questions to help you avoid over-scoping your project, delivering outcomes without benefits and understanding whether you are still on course.
- Bradley, G. 2010. Benefit Realisation Management: A Practical Guide to Achieving Benefits Through Change. Farnham: Gower Publishing
- Driver, P. 2014. Validating Strategies: Linking Projects and Results to Uses and Benefits. Farnham: Gower Publishing
- West, D. 2010. Project Sponsorship: An Essential Guide for Those Sponsoring Projects Within Their Organizations. Farnham: Gower Publishing