Steering new projects in a leading position can be challenging, especially in large companies where navigating relationships with multiple stakeholders is crucial. How can you guarantee that your project goals align with those of the company? And how can you ensure that the actions you take go in the right direction?
This article discusses an approach to stakeholder management that provides a better understanding of how to turn unknown environments into known dependencies by focusing on people.
Overview of Relevant People
At the core of an organisation are individuals. The first step to stakeholder mapping, therefore, is to gather the people involved in your project activities. You could get them from meeting minutes, the company organisational chart, or by asking other project members. It's important to collect their names, roles and project involvement. Everything that provides context to that persons background. For important people you may also want to collect pictures so that you recognise them when you bump into them in the office . You could get those pictures from the company profile picture or from business networks like LinkedIn (pay attention to data privacy - if in doubt, collect only what is really necessary). Even though we are going to prioritise those people try to focus on important individuals and neglect unrelated ones.
Sample for a raw collection (made-up names):
- Mary: CEO
- Robert: Project Lead of Project X
- Susan: Project Lead of Project Y
- Thomas: Software Engineer in Project X
- ...
Take this collection as an example: there are 2 different projects and the CEO Mary who is an important stakeholder to our project (in sake of the example). Choose a representation that is most suitable for you. You could also use a list, or directly a diagramming tool that you can use at a later stage for visualising relationships like this:
In the beginning of projects I usually rely on people that have been involved in the project already. Additionally, as I take extensive meeting minutes I extract relevant individuals directly from my notes.
Prioritising and Clustering
This section describes how the collection is stripped down to most crucial and relevant individuals. There exist various dimensions on which the prioritisation could be based on. Try to reduce the collection while retaining the most comprehensive overview. Take the following examples as inspiration:
- If you have many different projects ensure to keep the most important person per project. Example: your list contains five people for project X and the project is not that relevant you write down the most important person from your point of view.
- To represent decision hierarchy, prioritise by role and influence of that person. Example: people within a steering committee take budget decisions which has a direct influence on project extensions.
- A personal relationship with individuals is very valuable. Example: you have worked with Thomas (from collected persons) in a previous project so you could exchange with him on a deeper level to get valuable insights into Project Y.
As mentioned, this is just an inspiration of dimensions and incomplete. Eventually, it is important for you to understand what your project currently needs: are you planning the next project extension? Then it is important to collect all decision makers for the budget. Are you planning on implementing an upcoming feature? Then it is crucial to prioritise people and projects that influence or depend on that feature.
In a recent project, I extracted over 70 individuals from meeting minutes associated with a particular project. After prioritisation, I reduced the list to 10. I used a combination of dimensions to ensure that the most important people and projects were captured.
Putting People in Perspective
This sections describes how the filtered collection is mapped into a dependency map of stakeholders. Take you favourite visualisation tool. If you are creating the map collaboratively ensure to have a tool that synchronises changes. Also think about maintenance: are you creating the map for depicting a one-time visualisation or do you want to continuously update changes potentially even within the team?
With people names and roles wrapped in ellipses and project scopes denoted by rectangles a basic visualisation of above collection looks like the following picture. Arrows with a short text describe the relation of your project to other projects. The description is based on your understanding of the relation and might be directly related to a project or a person. If you are unsure about the relation you can also omit them in an initial step and just place a directional arrow.
Mary as the CEO is sponsoring the project, while Our Project relies on the functionality of Project X and, Project Y is interested in utilising our project's features. Note that you might want to add profile pictures to recognise people if you bump into them.
I usually have different maps for different occasions with different people. One time I had to visualise dependencies across companies and thus introduced a company boundary. Over time I have also established a fixed set of figures inspired by the C4 modelling technique.
Conclude Understanding
Your relational stakeholder map can help you understand the decisions and importance of the people involved. For example, what action should you take to secure Mary's continued sponsorship? This would require a deeper understanding of her goals and interests in your project, which you could derive from the stakeholder map.
If you were only looking at titles, Thomas might not seem important in terms of project scope or governance, but you might have some questions about functionality that your project depends on, and Thomas might be the quickest person to answer (rather than going through Robert). Susan may contact you frequently if you fail to keep her informed of your next project delivery. To further define the scope and direction of the project, you could discuss the requirements with them.
Once you have mapped all the important dependencies, you should share the map with your team, or anyone else who you think will find the map useful in understanding the bigger picture. The map allows you to create a shared understanding of your current project dependencies. It allows you to create alignment by clarifying relationships with people (who knows whom?).
The stakeholder map you create is a living document. It is a snapshot of one dimension rather than a holistic understanding of the project. Use it as a tool to understand dependencies and create alignment. You will need to refine and update it as your project environment changes.
I usually just create shared stakeholder maps that everyone in the team can access and edit. Especially at the beginning of new projects or when there is a big change in scope, the mapping has helped a lot to get a common understanding of the project.
Conclusion
This article presents a stakeholder management method that involves gathering relevant individuals and visualising their interdependencies. The resulting map can aid internal project team alignment and facilitate understanding of project decisions and their impact.
It represents only one dimension of the overall project setup and requires effort to keep it up to date. In addition, there are many other perspectives on stakeholder management, such as approaches discussed in the Miro blog or related topics on staffeng.com.
For me the greatest strength of the whole exercise is the alignment with team members. When I present my drawings I have often gotten the feedback that this map really helped with understanding the bigger picture of projects and teams.