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.