Demystifying project benefits

I’ve been looking at a number of public sector organisations’ program and project plans recently, as well as some business case documents, and a recurring theme is that claimed ‘benefits’ really are not benefits at all in many cases.

What do you think of these ‘benefits’?

• Options designed and tested
• Projects implemented
• Building construction completed [by date]
• Equipment installed and working [by date]
• An understanding of front-line staff views on the service they deliver
• Key stakeholders have ‘bought into’ the project

None of these, in my view, are benefits. Some definitions of benefits I have come across include:

“A real source of value to the business” [Gartner 2005]

“A term used to indicate an advantage, profit or gain attained by an individual or an organisation” [Remenyi, Bannister & Money 2007]

However, the most useful model I’ve come across is OpenStrategies’ PRUB-thinking. This basically says: “Organisations run Projects that create Results; if those project results are Used, there should be a Benefit to the user.” Or, put another way: unless somebody wants and uses the results of an organisation’s projects there can be no benefits.

So, going back to the list of six ‘benefits’ above, in PRUB language they are all results, not benefits.

The OpenStrategy Structure

The OpenStrategy Information Structure is very simple and is made up of four sets of information which are at the heart of PRUB-thinking.

Organisations run Projects that produce Results, which citizens or communities Use to create Benefits. So, it’s ideally suited as a framework and way of thinking to help with benefits realisation in any project or program.

For example, a Local Authority might initiate a program to improve the health of young people in a city. Within this program, there might be several projects that collectively contribute to the overall objective.

You’ll notice that some of the Projects create Results that are used by other Projects. That’s fine, as long as they are used. Otherwise, they are ‘Abandoned Orphan Results’ and you’ve wasted time and money in creating them. Far too many public sector projects produce Abandoned Orphan Results: nobody wants them and nobody can use them, so they cannot contribute to Benefits. (Lots of cost-savings to be had there then!)

Features versus benefits

In the world of sales, the language of benefits is at the heart of selling skills. Sales and marketing people are taught to differentiate between ‘features’ and ‘benefits’.

All too often sales people bore potential customers with long lists of features e.g. “has a 300GB hard drive”; “has an intelligent 4-wheel drive system”; “has interchangeable coloured panels”. Features need to be translated into benefits and you do that by adding a Use—“which means that”—to the end of the sentence.

So, “has a 300GB hard drive which means that you will be able to store at least 50 hours of music (= Use) so you will always have the music you want, at your fingertips (= Benefit)”.

The same thinking needs to be applied to benefits of projects and program. From my list of six so-called ‘benefits’ above you could say, for example, “building completed by [date] which means that we won’t have to renew the lease on the existing building (= Use) and will save at least $2.5 million this year (= Benefit)”.

Or, “key stakeholders have bought into the project which means that financial approvals will happen on time (= Use) and we will avoid delays to projects. which will produce assets that can be used to create benefits for end-users (= Benefit)”.

PRUB-thinking highlights the fact that often there is a cause and effect chain leading to ultimate business benefits, for example, “more motivated staff, leading to more creative working, leading to happier customers” (and even this chain could be extended).

The main point to remember though is that the Results (deliverables) of a Project can NEVER be Benefits. There are no short-cuts from Projects to Benefits, or from Results to Benefits – every Project MUST link via Results through Uses to Benefits.

Benefits realisation

So many benefits maps and benefits realisation plans that I see are either overly complex, or total flights of fantasy. The PRUB-thinking structure provides a uniquely simple, but powerful, way to cut through the ambiguity, confusion and complexity of benefits realisation.

A PRUB diagnostic will determine, explicitly, which of many different reasons why a Benefit will not be achieved:

• There are inadequate, or insufficient, Projects producing Results directly linked to the required Benefit.
• The Results of Projects are of no Use, or cannot be Used.
• There are potentially Useful Results that aren’t being Used, again for various reasons.

A PRUB diagnostic will also determine, explicitly, which of many different reasons why a project or program should be stopped:

• It’s producing a non-adoptable Orphan Result.
• It’s producing a potentially Adoptable Orphan Result.
• It’s producing a potentially Useful Result that isn’t being Used, again for various reasons.
• It’s producing a Useful Result that is being Used but the value of the Benefits is less than the cost of the associated Project(s).

So, in summary, if you want to ensure your projects and programs really do deliver measurable benefits, all you need to know is:

• What Results (deliverables) will your Project/Program create?
• Does anyone want these?
• Will they use them when they get them?
• What Benefit will they get from using them?

However, you shouldn’t start a project or program by dreaming up deliverables. You have to start planning a project from the benefits end: define what you are trying to achieve, for whom. Or as Stephen Covey wrote in 7 Habits of Highly Effective People: “Begin with the end in mind.”

The reality for many organisations is that they already have numerous Projects underway and these are inadequately linked, through Results and Uses to Benefits. These Projects would certainly be amenable to a PRUB diagnostic, which will either sharpen them up, or convince you to stop wasting time and money on them.

Every successful activity or project should lead to Benefits that are more valuable than the costs of getting to the Benefits.

Co-authored by Ian Seath. Seath is an independent consultant who works with private, public and third sector clients to improve their approaches to performance management and project management.

If you would like to review Validating Strategies: Linking Projects and Results to Uses and Benefits by Phil Driver, please contact editor Adeline Teoh. The book is available for sale online.