A basic map of our stakeholders
Quite some time ago, I wrote an article on “creating a basic communication plan” and for many projects that is all you need.
But sometimes it is worth analysing your stakeholders in more detail. This article explores a couple of approaches that I like to use when I need to understand more about my end users or more about my “project stakeholders”.
We still start with a basic map of our stakeholders
A simple way to start any communication plan is to map stakeholders against two criteria – our impact on them and their impact on us, as you can see in this diagram.
Once you have done this then you might spend more time on your end users (the ones you impact the most) and your key stakeholders (the ones who have the most significant impact on you.
Let’s start with the end users
To better understand your end users, you might use a variety of tools.
- Value stream maps are a great way to understand the relationship between customers, internal staff and processes.
- Story maps are a great way to understand the relationship between your product and the things users desire the most.
- PAC is a quick and dirty way to understand your users and the context within which they will use your system. Empathy maps, personas and the value proposition canvas are more professional and sophisticated ways of achieving the same thing
But the tool I want to discuss here is a “why, how, so what” map.
What do people do? Why? How? So what?
When I am analysing users, I often find myself asking the same three questions:
- Why do they do that?
- How do they do that”
- So what – what insight does that give me?
For example, let’s assume that I came up with a brilliant idea – I will build a mobile application for hotel guests. This application will allow them to manage their stay in the hotel, with features like booking their room, investigating tours or ordering room service.
- But why should people buy this app? To manage their stay
- How will it help them manage their stay? They can manage a lot of transactions they have with the hotel without having to talk to anyone?
- How? They can book their room online and then use their mobile phone as a room key or they could order room service from their mobile while on their way back to the hotel.
- Why would they want to do that? etc
So it comes as no real surprise that some people turn these questions into a diagram or “map”.
A “why/how/so what map starts with an idea (for example “I want to manage my stay in a hotel”).
The map then connects the following three questions into a diagram around that original idea:
- Why people do things (to get closer to their real needs and also help identify other ways of helping them);
- How they do things (to get more detail and to identify the actual features or services to implement for them); and
- My insights, observations and potential implications.
Let’s look at a possible diagram for our “Hotel App”:
This information is in rough (sketch) form and it can now be used as background to completing an empathy map, persona or value proposition. Alternatively you could take feature suggestions straight from this map. This forms the basis of my “business analysis plan” or my “customer discover plan”. These may not sound like the same thing as a communication plan until you realise that “communication” is a two way process:
- In a communication plan you work out what to communicate to people and how to deliver change in an organisation … but you need feedback from the potential users for this to work;
- In a business analysis plan you plan who you will interview and what information you will gain from interviewing them … but you need to provide them with feedback, which becomes part of a communication plan; and
- In a customer discovery plan you plan experiments, focus groups and prototypes to learn more about your potential customers … but it is also useful to provide them with feedback.
So I see this approach as BOTH input for further analysis AND input for creating a communication plan. I will leave you to decide whether or not this is valid.
I sometimes use this map in workshops and I find it really useful. But even without the diagram I find that the questioning structure is really powerful.
What about the key stakeholders who will impact the project?
I also like to apply a rough “map” to my key stakeholders whose help I need on my project, or whose interference I fear.
To do this I break them into groups such as allies and antibodies. I don’t always use these terms because it may not always go down well, but here is how I sometimes classify people …
Allies and antibodies
Here is my list of “People who can impact your project”:
|People and organisations who grant you permission to proceed with your service. For example you might need the permission of an internal IT security or branding team.
Externally, you might need to comply with privacy laws, vendor management teams and others and so you need to address the needs of the outside Authority. This might involve both capturing their needs and communicating to them that you have addressed their needs.
|Although you do not need the permission of “allies” to launch your product, you still want their help.
Allies include the IT security or brand team again if you need guidance from them but allies can include industry groups, valued advisers, key subject matter experts and others.
|These are the organisational forces (and people) who protect the organisation from danger (and therefore from change, vendors and anything new that could provide a threat).
These people may see your new product or service as a threat and therefore hinder your progress if you cannot satisfy them as to why your change should be allowed to proceed. They do not always have the authority to approve/reject your project but they can certainly hinder your progress if you are not careful.
This group might include vendor management teams, architecture teams and others who provide good governance and/or bureaucratic pain for projects.
|Saboteurs are the people who actually want you to fail.
This could include competitors, internal rivals or just people who are really mean.
You might not want to communicate to your competitors but you might actually want to anticipate their reaction to your project and mitigate the potential communication they will provide to your stakeholders.
You might not have internal rivals or “really mean people” in your company but you might be surprised how often someone in an organisation is threatened by a change or how often an external lobby group might get involved in generating “bad press” for you.
Again you might want to communicate to these people to convert them from saboteurs to allies, or you might just want to anticipate and mitigate their reaction to your project.
Questions to ask about these stakeholders
Rather than worrying too much about how to classify stakeholders, you are probably more interested in identifying the questions that will help you decide how to deal with them.
These are the questions I often ask in order to plan how to deal with “allies and antibodies”:
Authorities and allies
Potentially – I might then find that I need someone else’s help to influence or convince the authority or potential ally to help me. So this new stakeholder is a potential ally and I repeat the above questions to help me understand how to get their help.
Antibodies and saboteurs
Potentially – I might then find that I need someone else’s help to influence or convince the antibody help me rather than hinder me. So this new stakeholder is a potential ally and I repeat the above questions to help me understand how to get their help.
Again, you can turn this into a sort of map, and you can use this as a structure for a workshop.
Here is what my “allies and antibodies” map might look like:
Rather than contributing directly to new features in your product or service, this information is likely to form part of your marketing plan, communication plan or implementation plan.
For example you might highlight that to launch the new mobile app (for hotel guests to use in managing their hotel experience) you need the help of internal IT staff at the hotel.
But internal IT people don’t really care about your product, so you need to find a way to explain to them that they should care. You might also want to find a way to make it easy for the internal IT support team to understand your product and potentially even tell their management team to use it. But you can’t really speak to the internal IT teams directly because you have no channel to communicate to them.
Then you might decide to work with the vendors who provide the “Hotel Management Systems” (Hotel ERP systems, Hotel CRM systems etc). If you can get these vendors to support your product, then this will help you to get the support and buy-in from internal teams within any hotel group. But why should these vendors help you?
I hope that all makes sense – what I find is that by asking “what do I want to do – who can help (or hinder) me,” I gain some really useful insights into building a communication plan that will address their needs and therefore help me to manage them better.
One thought on “Analysing stakeholders – beyond the basic communication plan”