Terminology, what's in a name?

Over the course of today I will be expected to speak in many different languages.  Technically I can only speak English (my French and Welsh aren't great) with any degree of fluency, however I am not talking about changing from English, but about dialects of BRM speak.

One customer we work with insists that all benefit maps are drawn from the left to the right, with their "benefits" on the left and the "initiatives" on the right.  All of our other customers want the "benefits" on the right, and the "initiatives" on the left.  In Realisor we've implemented a switch that allows maps to simply be reversed, however the visual appearance isn't the only difference, and a simple switch to allow maps to be shared doesn't bridge this language gulf as easily.

BRM Dialects (Methodologies)

There are many different methodologies, however luckily while people get very heated about the words used in their dialect and the correctness of it, there are some fairly simple common rules. Lets have a quick look at three ways of mapping.

Benefits dependency networks (BDN)

The benefits dependency network is well described in Benefits Management: Delivering Value from IS and IT Investments by John Ward and Elizabeth Daniel.  As usual maps are built from right to left, starting with what we're trying to do (here called Investment Objectives or Objectives), into Business Benefits (the advantage stakeholders get).  The bits to the left of this then are changes required in the business, the one off enabling changes, plus the technology required to get those changes.

Benefits Dependency Map (BDM)

A thorough description of the Benefits Dependency Map can be found in Gerald Bradley's Benefit Realisation Management.  As with the benefits dependency network mapping occurs from right to left, covering what you're trying to achieve, the benefits of getting there, the changes required to get those benefits, and then what is needed for those benefits to be obtained.

Results Chain

Results chains are covered in more detail in John Thorpe's book The Information Paradox.  As with the previous two methodologies the concepts are similar, however the shapes and words are different.

Are they really that different?

One thing that I found in academia is that it is very important when writing a paper / book to make clear how different (and better) your work is to that of other teams.  I also found that the differences and improvements while heavily hyped and published were far more likely to be incremental changes to the body of knowledge.  This is true for both BRM and BRD, and really for most mapping styles dealing with benefits.  Yes there are small differences, however you can break the mapping down into:

Things you'd like to get

•     Objectives (Strategic outcomes, strategic benefits) - These are your very top level "things you'd like to get".  They often appear in strategic documents as little diagrams and are the actual focus of the programme.
•     Outcomes / Benefits - Often viewed as something valuable for a stakeholder and measurable (can be negative).  These tend to appear in documents as aims, or are hidden in the text description of doing something as doing this will ...  OutcomeJogger is an excellent free resource to get you used to how these things tend to be phrased, but it boils down to you have a word describing a thing (Education, Energy, Margin), and attribute of that thing you wish to change (relevance, time to, scale), and a type of change (increased, decreased, happier, do less of).

Things you're doing / need

•     Initiatives (changes) - A something that delivers change (We are going to build this, alter this)
•     Capabilities - Something we need to have to make our change (A call center, a learning portal, a ship hull)

Why does this matter?

In many ways it doesn't as with experience you learn to speak all the dialects, however if you're following our foundation course you'll be expected to deconstruct documents following our methodology and make maps out of them.  Just remember the terminology we use can easily be converted into the terminology your customer wants you to use, and unless you have a very good reason use something that is familiar to them as that way they'll be engaged rather than trying to figure out your odd looking map with different shaped blobs on it.