You're reading...
OpenStrategies, Project Management

Defining the Benefits from your project? Mind your language!

Over the past few months I’ve been working with several clients and helping them to think through exactly what benefits they expect to achieve from their projects and programmes. I’ve written many times about the value of the OpenStrategies PRUB-thinking approach which I believe brings real clarity to benefits identification.

If you’ve read Dr. Phil Driver’s book “Validating Strategies” you’ll know how much emphasis Phil puts on using clear, simple and consistent language when describing Projects, Results, Uses and Benefits. I try to carry that discipline over into conversations with clients as they define their benefits.

Benefits_languageBenefits capture the “why” of a project. Something should be measurably better. Therefore benefits statements should use language such as:

  • Improved…
  • Increased…
  • Reduced…

Validating Strategies argues that benefits generally represent one or more of the “four well-beings”:

  • Economic (e.g. income, costs, cashflows, ROIs)
  • Social (happiness, satisfaction, health, education, employability)
  • Environmental (e.g. energy, water, waste, carbon footprint, recycling)
  • Cultural (community, values, heritage)

In practice, in a business context, benefits are often likely to be categorised as either financial or non-financial, with the latter covering such aspects as brand/reputation, creativity/innovation and risk/compliance.

You do, of course, have to be careful to define benefits in relation to the end-point of your project because there is often a potential chain of “why” questions you could ask. For example, you might claim a benefit such as “reduced customer complaints”, but a chain of “why” questions might also lead you to identify “reduced failure costs” or “increased sales/income” as additional benefits. In this case, you might be better re-writing “reduced complaints” as a Use statement like “customers using our service don’t complain”. Uses (in PRUB) are clearly different from Benefits; they are the actions of people (customers, users, audiences) that lead to Benefits.

Another advantage of using clear and precise language is that it enables you to identify inconsistencies on your benefits model. For example, it’s not unusual to see senior managers claiming that their project’s deliverable is “a £50k cost saving”. When you rewrite this as “costs reduced by £50k” it is clearly a benefit statement. If you expect to see someone turn up at the end of your project with a bag containing £50k, then it would be a deliverable (from a Bank Robbery project?). Another example of a “Use” that’s often written as a benefit is “a 20% increase in customer sign-ups”. On its own, there is no benefit. Additional sales, or reduced transaction costs might be the associated benefits.

So, mind your language and remember:

  • A deliverable can never be a benefit
  • Someone using your deliverables is not (yet) a benefit
  • Benefits only arise from the use of deliverables

.

.

.

.

.

.

.

.

..

..

.

 

Advertisements

Discussion

Comments are closed.

Connect with Ian Seath

Find us on Facebook Improvement Skills Consulting Ltd. on LinkedIn Follow IanJSeath on Twitter

Archives

Copyright Notice

© Improvement Skills Consulting Ltd. and Ian Seath, 2007-17. Unauthorised use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Improvement Skills Consulting Ltd. and Ian Seath with appropriate and specific direction to the original content.
%d bloggers like this: