StratNav

Over the last few years of using visual tools to build understanding we have created a lot of maps. Benefit maps, process maps, mind maps, visual plans, buglists and links between user stories and features. The problem we’ve always had with this is how do we share these large and often quite complex maps (print to pdf and email?), how do we show how they interrelate (make an even bigger single map?), and how do we collaborate to make them using normal mapping tools.

One of the companies I work with called Reachal created the application StratNav to overcome the first two problems of sharing and visualising interdependencies. This allowed us to show our complex content in a clear fashion with the users able to see the interdependencies, move maps around, show hide them etc.

If you have a complex mapping challenge and would like to be able to visualise how your work interacts with various standards the let us know.

Benefits of ISO27001:2013

My team was recently asked to produce a case for actually implementing ISO 27001:2013 or other standards.  One of the problems with information assurance / cyber security is the discussion of when to stop.  It is very easy to spend money on cyber security, however how do you know that what you are spending is worthwhile or correctly targeted?

While we were researching this problem we looked into the benefits of ISO 27001:2013 as a way of deciding how much cost we could justify, and how that would benefit top level stakeholders. Part of the way we did this was by breaking down a document by the BSI on the benefits of ISO 27001 to give us the benefits, and linking these to core actions within the standard itself to see how each part of the standard gave value rather than increased security.  The map that we produced is currently available for free on StratNav. 

The top level benefits of ISO 27001:2013 are partially what you'd expect

• Better protection of information
• Enhanced business reputation
• Better understanding of threats to the business
• Clearer alignment of IS procedures to business objectives

What is more interesting is the way that these are achieved.  Clearer alignment comes from better understanding of what the business is using information to achieve coupled with better focused spending on IS.  Enhanced business reputation is of course less incidents, however it is also better focused and more efficient operations allowing you to win and maintain more business.

I'd argue that a strong benefits focus is needed to ensure that IS spending and policy is focused on supporting the business use of information, rather than the traditional IS tells the business how to "safely" use information.  Getting IT and IS to agree that they should enable rather than protect could be a challenge in some organisations, however it is a challenge well worth taking on.

Interesting uses of Benefits Realisation

One of the things often said about Government is that when there is plenty of money it pays to achieve things, and when there is no money it writes policy.  This is all well and good, but of course how do those tasked with implementing a mass of policy make sense of it?

The company Reachal has been working with PSN in Cabinet Office on a possible solution for this.  That solution takes the form of an application called StratNav.  This application is a free demonstration of how benefits mapping can take multiple complex strategies, break them down into what needs to be done, what that gives, and how it achieves goals.  More than this though, the Gov ICT collection allows users to visualise the links between individual strategies and follow them between and through strategies.

We think it is a far better way of consuming strategies and understanding them in a much more realistic way than simply trying to read hundreds of pages of text.  Give it a try, and let Reachal know if you agree!

Hostile Benefits Analysis

One of the stranger usages of benefits analysis that I have been involved in has been in creating benefit maps from documentation to show that a target project will not work, helping to built the business case for a different project.

This sounds like a fairly unpleasant or unnecessary task, however lets think for a second about how spending decisions / bids are decided.  These are frequently competitive processes where there is a limited pot of resources to be spread between many good and well argued ideas.  If the documentation for each bid / project can be obtained then it is a "fairly" quick and simple process to break that documentation down into a benefits map.

The interesting thing here is that you have a benefits map based off of the project / bid documentation that is usually full of holes where assumptions come into play.  Frequently there are listed benefits with no initiatives to make them happen, or assumptions that doing something will achieve a goal that is unrealistic.

Of course what should be done at this point is to take the map to the stakeholders and bash it into shape in a workshop, however it is also possible to simply hand the map to the decision maker.  Each of the problems in the map can be justified from the project / bid documentation, and because of this evidencing process the map can be utterly damning.

A defence against this is of course to fix your documents when you have completed the stakeholder workshop section of document deconstruction, as if you haven't you may see your documents mapped for you...

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.