Picking ‘Good’ Benefits
Rather than concentrate on the methodology, this page describes the output of Benefits Management. The processes, tools and forms are there to help you produce good benefits. They are not ends in themselves. Instead of getting bogged down in the paperwork we must understand what we actually want to achieve.
First, we have to agree what a benefit is.
A benefit is a result that a stakeholder perceives to be of value.
The key points are stakeholder and perception. Who is the specific stakeholder under consideration? Is it patients in general or a Hospital Trust’s Finance Director? What sort of things do they perceive as valuable, improved clinical outcome, a better experience or hard cash in the bank?
The programme’s objectives can be viewed as the SRO’s benefits. The SRO is the programme’s primary stakeholder. Their objectives are the results they perceive to be of value, the reasons why the programme must go ahead.
Within the programme, good benefits start from good objectives.
Good Objectives
The purpose behind any course of action has a direct and significant effect on the way it is undertaken. The reasons why affect the ways we go about things. The objectives we choose validate the action we take so it’s vital we start with the right objectives:
Programme / project objectives must relate clearly to the organisation’s business drivers and strategic objectives
Objectives should be SMART and stretching, don’t de-scope into something short-term or easily measured
Objectives must be strategic. “We will implement on time” or “We will work well together” are given statements of how the programme will operate, not valid descriptions of what it will achieve
Keep to a few key objectives. Too many are unmanageable and will conflict with each other.
Good Benefits
Benefits provide the evidence that our objectives are being met and our programme justifies its existence:
Benefits are identified up-front (at least in high-level terms). They are why you are doing the programme, not why you did it.
Benefits are tightly linked to objectives, if not then the programme is being run for the wrong reasons
Benefits are not simply treats to win stakeholders’ commitment
Describe the benefit in verbs; improve, reduce, stop. It gets us away from picking project deliverables and functionality
Each benefit has an Owner who is responsible for its delivery
Each benefit has one Recipient, the stakeholder or stakeholder group who can say that the benefit has been realised. You can’t prove a benefit that is spread over multiple stakeholders
Benefits should be SMART and stretching, don’t de-scope into something short-term or easily measured. Set a target or predict the value for a successful benefit
Set a baseline. If you don’t know where you started from then you can’t say how far you got and you can’t prove it was worth the effort
Keep to a few key benefits. Each one will have a significant amount of work behind it. A hundred benefits may look good in a business case but they’ll never happen.
If you’re not sure of a benefit, keep asking the ‘so what?’ questions until you know who it’s for and why it’s important
Look out for the ‘usual suspects’. Make sure the benefits are appropriate for your programme. Not every project has to improve patient care.
Iteration works, the third pass will look much better than the first one.
