Last week was the Project Challenge event in London and the were some really good talks. Among them was a talk by David Walton of Bestoutcome on benefits realization. This is an area I am often asked about when supporting clients in their project prioritization and selection process so I thought I'd share...
Tracking through to benefits doesn't have to be hard, but it does take focus and the discipline to never give up, a bit like The Terminator - the good one in T2, of course; we don't want any nasty robo-PMOs running around gunning down project sponsors... even if you do sometimes feel like it!
Very few organizations track projects all the way through to benefit and David gave a simple framework to help you get there, but he missed one of the most important steps out; prioritization.
So, let me share with you my interpretation of the talk, but I'll add what I think is missing.
Why benefits realization matters
Your project portfolio is the vehicle through which your organization turns strategic intent into action. Projects are how you change "things" from where they are today to where the executive team wants them to be. If you never achieve the strategic intent of a project, then that project has failed.
This matters far beyond PMO statistics and bragging rights. If your projects fail to deliver their intended benefits, your organization can not achieve its strategic goals. In extreme cases, this can even lead to organizations going bust or being taken over.
In short, delivering business benefit, not delivering projects, is what really matters.
The benefit roadmap
David outlined a very simple set of ideas that is immensely valuable – there are other ways to tackle this as well, but I thought David’s approach was quite practical. Essentially the idea is to map out a set of milestones along the way to delivering the business benefit and then make sure you’re hitting them.
For example, imagine we want to grow revenue through improved customer retention and are going to implement a new CRM system to help do that. Now, if we take a non-benefit-centric view when delivering the project, we can say we delivered the project successfully once the software has been deployed, but that's not true.
Let’s start at the end, at the benefit, and work backwards. To achieve cost savings, we need to reduce churn. To do that, we need our staff to be "saving" customers. To allow that, we need to match the right "offers" to the right customer, and that's why we need a new CRM system.
Putting the system in does not deliver the business value. It’s the end result (lower churn), that delivers value (more revenue).
Of course, I've simplified this example and, at some level, this is just mapping out the whole project right up to benefits realization (not just “my bit of it”).
The power of this simple technique is that it lets you review your project at each stage. It gives you a chance to make sure you still believe the benefit is realistically achievable: each milestone is a natural point in the project to make sure we’re still on track.
Ownership and the business case
For each Project, it's a good idea to clearly document the following as part of the business case:
- the expected benefit and time line
- a list of any dis-benefits of the project (E. G. If a service level somewhere else might fall)
- the person ultimately responsible for delivering the benefit
- the probability of achieving the benefit (and associated risk factors)
- a description of how the benefit is going to be measured
All of these factors should be part of the project selection process. It sounds simple and within TransparentChoice, for example, we let you capture all of this data as part of the evaluation process making sure you have what you need before a project gets the green light.
Ownership-with-teeth can be good way to encourage good results. For example, if a project promises a specific cost saving it might be a good idea to reduce the sponsoring executive's budget by that amount the following year. This provides a real incentive to follow the benefit through to the end. Not all benefits are financial, of course, but putting some kind of incentive in place can really drive real ownership.
Notice I'm talking about ownership rather than sponsorship. They are kind of the same thing, but in this context I use "ownership" to imply much more active participation and commitment, and this is key. Ownership means you never, ever stop until the benefit is realized... it's The Terminator again.
Do you even understand the business benefit?
In his talk, David didn't really address this (there's only so much you can do in half an hour), but it is absolutely vital.
Pretty much every organisation has far more projects ideas than they can cope with. Picking the right projects in the first place is critical, and having an evaluation process that let's you quickly weed out the weaker projects is vital for an efficient (E)PMO. That's why it's so important to have clear stage-gates for documenting and evaluating projects requests.
That is a fairly mechanical process. Much more difficult is getting agreement on what the organization's goals and drivers are in the first place. You simply can't evaluate which projects deliver maximum benefit unless you know how to value different benefits (e.g. increase in net promoter score vs. cost reduction).
This is the foundation on which everything else is built.
I'm not going to talk about it in detail here as I've covered it elsewhere. What I will say is that there is definitely a "right" way (and a lot of "wrong" ways) to do this “weighting of benefits”. Needless to say, we built our prioritization software based on the "right way".
The journey to full benefits realization can be long and difficult.... in fact, it's a project on its own!
Prioritization can be a quick and easy first step and is a great way to get people into the "benefits mindset". But the most important message for you, for your executives, for your PMs and for your project delivery resources is that projects are pointless without realising benefit, so put those benefits at the heart of everything.