Realising the benefits

First session this morning was about Benefits Realisation Management. Something we all aspire to do, but difficult to do well. Of course, it's not just an IT issue, but the IT department is usually involved in many different and difficult change projects. It can also be easy for people to put the blame on IT, if a project fails.

Some interesting observations and techniques outlined in the presentation. Will try to give a flavour, without reproducing the whole talk. A recent CIO survey looking at how often a technique was used, and how effective is it was in  ensuring benefits are achieved showed an unusual correlation  - the things we use the  most (eg project and programme management, business cases), are the  least effective. The most effective tools such as benefit audits, harvesting reviews, baking benefits in (had not heard of this one, it means reflecting the benefits to be achieved in things like budgets, headcounts etc) are the least used. We tend to opt for the techniques which are less politically sensitive and more under our control, the things that we know how to do.

So, what do we need to do? Some suggestions:

Shift from project focus to benefit focus. 
Implement  joined up governance throughout benefits life cycle from planning to execution to harvesting. Sponsors and team members must commit to it.
Have a value model, used for all projects which is simple so that everyone understands it and it's consistently used.
Introduce accountability. Make everyone in the enterprise cares and ensure that every change/ benefit has an accountable owner. 
Carry out reviews, not just project post-implementation, but harvesting reviews, get someone from outside to do a benefits audit, look at remedial action if expected benefits not materialising. learn lessons, and share best practice. 
All very sensible stuff, but it can become an overhead, so you have to use judgement  as to which projects to apply it to. You can use the size of the project, the risk to the enterprise of it failing, or how many people it touches to determine how much formal BR technique to use.

One technique outlined was the benefits dependency network where you start with the main objectives of the university and the benefits you are trying to achieve to align with them. You then identify the IT/IS changes you need to make, but more importantly, the  business changes and enabling changes which need to be put in place to make the IT changes work. If younfocus too much on It, and not enough on business, culture and enabling changes, then you will never realise the benefits.

A couple of final points. As well as an intrinsic value, these tools have a signalling value. They confirm to the university that it's not just about IT, and hopefully get people thinking wider.

Also, in project management and execution terms, the biggest risk is often big projects. But often the biggest risk to benefits realisation is in small projects.


- Posted using BlogPress from my iPad