A useful Benefit Realisation Approach

One of the big topics for every project organisation (and IT in particular) is benefit realisation. Whenever I think about benefits then I think about the approach from Peppard, Ward, and Daniel that I found a few years back. Ever since am I working on making it happen and at the time of writing (Jan 2017) I might be able to get a first version implemented within a few weeks.

The basic ideas of the article are captured in this mind map.

A B&W version is also available.

Advantages of the Approach

Why am I liking this so much? Because it combines several elements that I know to be true:

• People need to be accountable if you want to succeed. Too many projects have nobody being accountable for benefits as benefit realisation starts often after the end of the project. The project enables the benefits, but it takes a while to get new processes running smoothly in order to realise benefits. And at that time the project team might no longer exists. This approach makes the right people accountable. And those are normally not within the project team. Btw, this is a good argument for the fail fast concept.
• Start with the end in mind: most projects are supposed to fix an issue or improve some specific processes. When we know this then we can start with analysing the intended benefits and then simply plan backwards: what needs to change in order to create these benefits? The other way around, that you have a new technology and then try to make use of it, is much more rare.
• If you care about something then you need to track and monitor it. If you care about benefits then it's simply not enough to define benefits in the business case for the project. Instead you need to use the benefits as the guiding principle throughout the project. I therefore started looking at the BDN (Benefit Dependency Network) suggested by the authors as a "Benefit Breakdown Structure" as replacement for the "Product Breakdown Structure" or "Work Breakdown Structure". It's not a perfect fit as the BDN is not a tree structure but you can easily match it.
• Projects benefit (no pun intended) if key stakeholder participate and are actively involved. This approach turns the benefit owners into project stakeholders. If you do it right then their accountability will turn them into valuable assets that have a keen interest in the project to succeed. However, see my comment further below regarding politics involved.

Considerations for Implementation

If you are looking into this then you need to ensure that you understand what is a portfolio activity (maintaining a Benefit Registry) and what is a project activity (identifying benefits, adjusting project plan to change of benefits).

I am wondering for some time now why this concept is not yet in use everywhere. I believe that the problem is of political nature. Not everybody likes to be accountable. And it can be of dis-benefit for a benefit owner not to have a project to blame for non-realisation of benefits. It might therefore not be in the interest of middle management to follow this approach.

Clearly, if you are just wondering about work breakdown structures after reading this article, then there are many implementation tools readily available. I found this guide which made a good impression on me.

[Update 25/9/2017]: I found this interesting article. Triggered by the Managing Successful Programs (MSP) course did I realise that Benefit Maps are quite well known. At least much better than I thought. Ward et. al. have "just" honed the idea from the IT perspective (not sure in which order these ideas were introduced, I will need to research this).

Steven is touching on another interesting and related topic: Impact Mapping! It fits quite nicely together as impact mapping is clearly overlapping with benefit mapping. How? I will explain in a later update.