Friday 24 August 2012

Document Deconstruction

A good place to begin would be with Plato, who once said that 'the beginning is the most important part of the work'. Indeed, as W. Clement Stone said, 'definiteness of purpose is the starting point of all achievement' and the purpose of benefits realisation is to ensure that the project/program's objectives are met and the benefits achieved.

 The problem is knowing where to begin or how to start and this could not be more true of undertaking a benefits realisation process. There are several excellent books available on Benefits Realisation and Management, but within these, there is an inherent element of assumed knowledge. It is almost taken for granted that you will be able to deconstruct documentation to tease out the benefits and objectives, that you can identify a stakeholder at twenty paces and run a workshop more thoroughly and efficiently than Usain Bolt can run the 100m, that like Jeremy Paxman you know what questions to ask and how to get the information you require.

This has resulted in a knowledge gap, and for this starting knowledge to be missing or incomplete makes the entirety of the benefits realisation process difficult to begin or to have success with. Here, we are going to fill this gap and take you through how we begin the benefits realisation process. A working example of this process will be displayed in another blog post.

Step 1 – Collect together all the available and relevant documentation. This could be things such as strategy documents, overviews, vision statement, Microsoft Project plans etc. This list is not definitive and the type of documentation will vary from project to program. The information you are looking for is why change is occurring and what they hoped to achieve from this change.




Step 2 – Grab a cup of coffee, multi coloured packs of Post It’s, a pen and pencil and a copy of OutcomeJogger™ –it’s going to be a long night!

Step 3 – Use the Post It’s to note down anything that resembles a benefit, strategic benefit or initiative. (For help with identifying these, you can refer to the blog post on Benefits Identification which can be found here on Benefits Unmasked). You may find it useful to colour co-ordinate these by document, using pink Post It’s for the vision statement, purple for the MS Project plans etc. This is helpful when you wish to refer back to which document the benefit came from and can provide key insights into the importance of the benefits – if you have the same benefit noted down in 5 or 6 different coloured Post It’s, that indicates that it could be a key benefit.

Step 4 – Now it’s time to collect together all the information you have pulled from the documentation and start sorting it into groups, for example by what we call an ‘Initiative’ – where something is happening or being done and by ‘Benefit or Outcome’, which are the results of the changes – these can be both positive and negative. You may also find it helpful to further break down these groupings – during the recent construction of a benefit map, we found it useful to sort our Outcomes or Benefits into areas, for example pulling together those relating to technology, relating to marketing etc.

Step 5 – The next stage is the creation of the benefits map. You can use a modelling tool to do this such as MS Visio or in this instance, we are using Realisor to create our maps and hold information on initiatives and outcomes. Now that you have your Initiatives and Outcomes sorted and grouped, it is time to pull them together onto a canvas and link them together, to see what Initiatives contribute to achieving the Outcomes, if there are initiatives that make no contribution at all and if there are Outcomes that have nothing contributing to them to enable them to be achieved. It may be worth revisiting the documentation at this point to see if any obvious links have been noted, i.e. ‘we are doing X to achieve Y’ and there is an element of using your own judgement to decide what would contribute to what. Remember at this point you are only making a first draft ‘straw man’ map that you will use to take to the stakeholders for their input.

No comments:

Post a Comment