Finding Outcomes and Initiatives in Documents

Part of the Realisor methodology for BRM involves breaking documents down into benefits maps, and I thought it might be useful to break down a small piece of text, partially to show the process being done with UK Government documents rather than our documents as shown in Jennys blog, but also to focus on what is missing when you do this.

The following text is part of the UK Government ICT Strategy

11. The Government is committed to improving the way it delivers ICT-enabled business change so that investments in ICT support business needs and deliver expected benefits. To do this, government will adopt the right methods and policies and develop a skilled workforce in order to improve and exploit its ICT. By reforming its approach to ICT, government will also help to stimulate economic growth by creating a fairer and more competitive marketplace, with greater direct opportunities for small and medium-sized enterprises (SMEs).

We will keep our definitions simple and say we are looking for what the Government is hoping to get, and what they are intending to do (outcomes and initiatives respectively).  We should also be looking for assumptions, risks, capabilities, projects and processes etc, but here will will just focus on outcomes and initiatives.

The section consists of three sentences and we will consider the first two of them.  When Jenny suggested coffee and post it notes she wasn’t kidding, in this blog post we are looking at part of one section out of 63 sections in this document, and of course the document is related to numerous other documents…

The Government is committed to improving the way it delivers ICT-enabled business change so that investments in ICT support business needs and deliver expected benefits

I’ve picked three things out from the first sentence.  If we remember the definition of an outcome according to OutcomeJogger, an outcome is where we are changing an attribute of something.  What we have isolated here is

1. Improve delivery of ICT-Enabled business change
2. So that investments in ICT support business needs
3. Investments in ICT deliver expected benefits

Now we wouldn’t write these up as outcomes at this point.  For a start we don’t know that they are separate outcomes, or if when we go through the rest of the documents overlapping post it notes will be created.  What we do need to do though is note where these came from on the three separate post it notes (I use GICT for this document, o for them being potential outcomes, and then number them according to section and number in that section), and also that there is a belief implied in the document that 1 leads to 2, leads to 3, or GICTo1.11.1 -> GICTo1.11.2 -> GICTo1.11.3.

Another reason to not write them up as outcomes is that the wording is not what we’d want it to be.  For number 1 the word improved is quite generic, improved can mean different things to different people.  When we classify the post it notes at the end of the process there will be numerous “outcomes” that are very similar.  These should be put together where possible and well named outcomes used to represent the groups.

To do this, government will adopt the right methods and policies and develop a skilled workforce in order to improve and exploit its ICT.

Now we could view these as outcomes (Increase adoption of policies, workforce skill increased, exploitation of ICT raised), however the wording suggests that these first two are things the Government is going to do to achieve the three proto outcomes from the first sentence.  As such I’d write these up as initiatives, but when pulling the post it notes together at the end if it seems that there is no support for the idea that there are things we are going to do I’d change them into outcomes and flag that up for a workshop.

So now we have 4 outcomes and two initiatives.  If we link them the way that the document suggests (note I’ve tidied the names up a bit, they should be cleaned up by the stakeholders in a workshop)

When you look at this map it doesn’t seem to make sense.  Increasing the success of business change doesn’t align investment with business need, however investing where there is a real business need increases the chance of success.  Moving this around gives us

And I’m fairly happy with this.  Our strategic outcome is a placeholder, we don't really know what it should be from the bit of the document we've processed.  The next step is to take this set of assumptions into a stakeholder workshop and beat it up, assuming that you've done the whole set of documents of course.

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.

Benefit Identification

One of the murkier areas of Benefits Realisation Management (BRM) is the process of actually identifying benefits to be able to create benefit maps.  It is clear that people know how to do this, and in fact that people are doing it.  Opening Gerald Bradleys practical guide "Benefit Realisation Management" and turning to 9.3 Benefit Identification doesn't really give a process to follow other than by discussing with stakeholders then using techniques to vet those benefits.  John Thorpe in The Information Paradox suggests you keep asking "so what", and then benefits are defined.

I'm not suggesting that there is anything wrong with either of these books, however for a beginner working with benefits it is very difficult to simply walk into a workshop with relevant stakeholders and identify benefits on the fly.  Simply identifying the relevant stakeholders and getting them all together is enough of a challenge, doing that and then having a productive workshop cold is no easy task.  Also lets remember that the stakeholder sessions aren't just about benefit identification, we're also using BRM to try to answer (and get agreement on) some important questions:

1. What does measurable success look like for the programme (i.e. what is it trying to achieve)?
2. What activities will the programme conduct, what will those activities cost and how will they each contribute to success?
3. How will the programme measure success through-life, spot problems and act to ensure success?

For us prior to stakeholder workshops, the process that we use involves deconstructing any documentation that can be found and using this to build a "straw man" model to take apart in the stakeholder sessions.  An explanation of this process can be found in Jennys blog. 

The strength of this process if done well is that:

1. you begin your workshops with a map people can immediately engage with and correct, rather than having to try to explain benefits and create something to discuss during the session. 
2. the map shows where weaknesses lie in the documentation and currently written expectations (benefits with nothing to create or sustain them etc.).
3. You can reference the benefits, outcomes, strategic objectives (insert terminology of choice) against the strategic documentation to show where you "created" them from.

The process also gives a lot more than just benefit identification, it gives a linked, supportable, in context view of the entire programme.  To help you get started with identifying benefits BRM Fusion have produced OutcomeJogger, which is free to download.  You can also use Realisor to create your maps and hold information against the benefits / outcomes.