So, What’s in it for me? An Introduction to Stakeholders

Throughout this blog and Kevin’s blog you will have seen multiple references to stakeholders – they clearly are important in the field of BRM. But what are they? Who are they? And why are they so important to this process? 

In order to engage with our stakeholders, we must first identify them. How do you know whether someone is a stakeholder or not? Is this a stakeholder? 

A good place to start would be with the definition of a stakeholder that we can then build upon. According to Gerald Bradley in his book ‘Benefit Realisation Management – A Practical Guide to Achieving Benefits Through Change’, “a stakeholder is any individual, group or organisation who will be affected by, or have influence over, the proposed investment. Stakeholders should normally include customers and suppliers (internal or external)”.

 Now that we have got a definition of what we think a stakeholder is, we still need to actually identify them, a task that may be easier said than done. There can be immediately obvious stakeholders such as the ‘project manager’ but there also may be people who won’t be affected until the latter stages or indeed after the completion of the programme or project. It is very important to identify all stakeholders at very early stage and document their requirements, interests, involvement, expectations, type of influence, power and possible impact, and communication requirements. They may be internal stakeholders (internal to the organization) such as the company management team, SRO, internal customer, project team, program/project/portfolio manager, shareholders etc or external stakeholders (external to the organisation) for example customer, users, suppliers, contractors, local communities etc.

This blog is designed to give a quick and simple introduction to what stakeholders are and why they can be important. For further information on stakeholder analysis and management techniques, we recommend further reading on the subject – some useful books are contained in the Bibliography and Glossary link.

So now that we have a definition of what a stakeholder is, for this learning project, just who are our stakeholders and why are they stakeholders – why are they important and what influence do they have over the success of the project?

Kevin – Director and CTO of BRM Fusion. As a director of the company and CTO, Kevin would be an important stakeholder in this project– he has a direct interest in the achievement of the outcomes and objectives in terms of the value of the Realisor product and the standing of the BRM Fusion/Realisor brands in the community. Additionally, Kevin has responsibility for the Realisor tool development and can determine the direction of the help functionality within the tool and can determine the content required for the benefits management material and also provide valuable insights and offer support and guidance on the content and can thus influence the ‘standard’ of the material produced and the direction that the learning material can take.

Jenny – ‘Project Manager’ of this project - Jenny is both affected by and can influence the project at various stages. Jenny is to provide initially the specification for the course and the content within it. Creating a blog will have an effect her profile and standing within the BRM community but will also reflect upon the company. The content of the course

Davey and Wyn– Software Development and Support team.  At this stage a member of the Realisor development team may not seem like an obvious stakeholder in a project that is focused around an approach to learning BRM, with Realisor just being used as an example tool. However, when you refer back to the documentation, consideration is being given as part of this project to providing help material for how to use Realisor as a tool and a consideration of improved tooling integrated within Realisor to support the process. Documenting how Realisor functions as a tool may have an impact on some of the processes used by the development team – e.g. an extra level of communication between the developers and learning support team to ensure any changes to the tool are fully documented and recorded. Additionally the consideration of added tooling within Realisor may require additional skills/time or even developers to complete. When responding to customer support requests, it is important that the members of the support team possess the knowledge of the subject area and are familiar with the learning content and the Realisor tool so they can provide the best level of customer support.

Perhaps the most important stakeholder in this project is one that we cannot pull into our workshop – the customer – the user of Realisor and the help/support material. The objectives of the project include increasing good practice, project professionalism and programme/portfolio success rates, which mean that the customer learning experience is important in achieving these objectives and realising the anticipated benefits. However, despite the recognition of this, it can be very difficult to engage with and involve customers, especially in the early stages, such as in a workshop. We can give the customers the opportunity to comment and give feedback on the learning material that has been produced, enabling comments and Q&A on the blog

So now that we have a working definition of stakeholder and have identified our stakeholders why are they so important?

Chances are that your organisation/project/program is undergoing a change or introducing a new ‘concept’ and you are looking to make sure that expected benefits are realised from this. People need to be brought on board for this to be successful – they need to be engaged, motivated and involved in the process.  As Bradley points out, that common hindrances to success include a lack of commitment from senior managers, lack of clear objectives and vision and stakeholders not being brought into the change. For many people, change is not always welcome. Sometimes the benefits of change may not be apparent to them, or they may have difficulty fitting into the current way things are done. It should be noted that some of these stakeholders will have minimum interest or influence on the project; however, project manager also has to take care of them because no one knows when they will become the dominant stakeholders.

What the stakeholders will want clearly communicated is ‘What’s in it for me?’ and ‘What is against my interests?’ The Realisor Guide: Questions for Business Analysts and Consultants available to download here provides further useful questions that you may want to consider asking. Perhaps one of the most constructive ways of asking and answering these questions would be in a workshop

Making a Map-sterpiece

 Like the creator of the iconic London Underground map, Harry Beck, we are going to create a map. Like Beck’s map, the aim of this map is to show us our final destination, where we will have to go to get there and the best route to follow.

In the previous blog entry ‘Document Deconstruction: A Working Example’, we discussed how to pull a document apart to gather our Objectives, Outcomes and Initiatives. Here, like Humpty Dumpty (only hopefully more successfully), we are going to try and put them all back together again. Using Realisor’s node import template functionality, we have created our list of Objectives, Outcomes and Initiatives in MS Excel and imported it into Realisor. Now we need to order and link these nodes in an attempt to bring some cohesion and clarity to the program. 

As discussed in Kevin’s Benefits Unmasked blog post ‘Terminology, what’s in a name?’, there are many different BRM methodologies – we are going to be using the Realisor default names of Initiative, Outcome and Objective (which can be changed within the tool to customise yours or your customers preferred modelling preference) and we will be mapping with Outcomes and Objectives to the right of the screen. This is where we will go first. 

The first stage here is to place our Objectives at the far right of the screen – this is the ultimate destination of our benefits road map. On the far left, we will have our Initiatives – the actions we will need to do to begin our journey and between these we will have the Outcomes that are achieved from undertaking our Initiatives and that will lead to meeting our Objectives.

Now we need to link our Initiatives, Outcomes and Objectives to form a map - 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 contribution links would exist. 

In document ‘Providing Realisor Education, for example, it is noted that team members should commit to setting up and contributing to blog (Initiative – Establish Blogs). This is stated that it will help raise the profile of the blogger (Outcome – Raise Personal Profile of Blogger) and we can then use our judgement to say that if the profile of the blogger has been raised through the provision of an established good quality blog on BRM, this will surely contribute to the Outcomes ‘Increased Value of Consultancy Services’, ‘Increase Company Reputation’ and ‘Increase standing of BRM Fusion & Realisor brands in community’. 

Looking at the diagrams in the ‘Providing Realisor Education’ document, we can see other Outcomes that are connected to the Objectives, with ‘Trust’, ‘Expertise’ and ‘Exposure’ leading into the Objective of ‘Increase BRM Product and Shareholder Value’. 

As you go through the model, you may need to do some tidying up - for example you may find that you have some Outcomes duplicate. Now that your ‘straw man’ model is complete, the next stage would be to demonstrate the model in a stakeholder workshop. The next post will consider what a stakeholder actually is, why they are so important in the BRM process and how to identify them.

 

Document Deconstruction: A Working Example

Having considered in our previous blog post the starting steps of the benefits realisation mapping process, this post will work through an example of each of those stages and see how we can get from a forest of paper to a clear map that enables us to distinguish the wood from the trees. Our example is focused upon a project to create learning material for benefits realisation.

Step 1 – Collect together all the available and relevant documentation. In this example, we have a strategy document entitled ‘Providing Realisor Education Material’, of which a pdf can be viewed here and a provisional plan for the process of creating a blog called the ‘Black Box of Benefits’ that can be found here.

Step 2 – Whilst this could be done using a collection of Post It’s, for the purposes of demonstration via the blog, we are going to add comments to the document using the Review function in Microsoft Word. Each comment that is added to the document would be a Post It.

Step 3 – Taking the ‘Providing Realisor Education Material’ document first, we can see that the opening section specifies the ‘Aims of Realisor Education’ – or the outcomes that we would like to achieve from the education process. 

Referring to Kevin’s recent blog post on ‘Finding Outcomes and Initiatives in Documents’ here at this point we do not know if these are separate outcomes, or if when we go through the rest of the documents that overlapping Post It notes will be created. So what we need to do at the point is to comment/create a Post It note of where these came from. Kevin’s post also considers the naming of Outcomes, using OutcomeJogger as a reference guide – these are not quite worded as Outcomes yet. Further reading of the document draws out what types of learning material is likely to be required – this is what we will do to achieve our Outcomes so we can note these as a set of Initiatives to be undertaken. Within the strategic objectives section, we note the key strategic objectives of this project - like within this document, these can often be found in diagrams within documents. The section covering ‘What needs to be done’ is more typical of what you may find in a strategy document – a mix of Initiatives and Outcomes that these connect to. This document has set out in a manner that is easier to deconstruct for the purposes of this demonstration but tend to be more typically phrased as per the example given in the ‘Finding Outcomes and Initiatives in Documents’ blog post.

In a similar fashion, we go through the ‘Black Box of Benefits’ document and use the comments to note anything that could be considered an Outcome, Objective and Initiative. As you can see across the two documents that we have deconstructed, we have some Outcomes, Objectives and Initiatives that are the same, both within the document and across the two documents. As discussed in the previous blog post, ‘Document Deconstruction’, this can provide key insights into the importance of the benefits – if you have the same thing noted down several times across the same or multiple documents, this 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 sort 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. We are also considering at this point any Initiatives/Outcomes/Objectives that have been duplicated across the documentation. 

Step 5 – The next stage is the creation of the benefits map – here we are using Realisor to do this. As discussed in Kevin’s Benefits Unmasked blog post ‘Terminology, what’s in a name?’, there are many different BRM methodologies – we are going to be using the Realisor default names of Initiative, Outcome and Objective (which can be changed within the tool to customise yours or your customers preferred modelling preference). 

Realisor has import template functionality so we are creating our list of Initiatives, Outcomes and Objectives in an MS Excel node import. We can add the title we want to give our nodes, e.g. ‘Increase Realisor Sales’, select the node type and in the description field we can enter the details of the document that this came from – ‘Providing Realisor Education Material, page.1’. The description field in Realisor is searchable within the ‘Search’ tab and so we can easily find any Outcomes that have originated from the ‘Providing Realisor Education Material’ document for example. For help with naming your Outcomes, we suggest downloading the free resource OutcomeJogger.

Once we have imported this list into Realisor to create the nodes on the map, we can start bringing 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 contribution links would exist. The pulling together of this map will be discussed in the next blog post.

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.