How to manage stakeholders in your project
By: Olga Nowacka
Tags: Business Analysis, Product Management, Project Management, Agile, Scrum

How to manage stakeholders in your project

Photo by Windows on Unsplash

The stakeholders are defined as people who are invested in the project and who will be affected by your project at any point along the way, and their input can directly impact the outcome (wrike.com). That basically means everyone who will affect, or will be affected by the project.

There will be probably a lot of them in your project. Since they are crucial to your project, it’s vital for you to manage them well. To do it right, you should prepare a stakeholder management approach — a document that will help you organize the communication and facilitate collaboration with your precious stakeholders.

Being a Business Analyst myself, I have written this article from the perspective of a BA. Feel free to read it and adapt the advice given here even if you have another role in your project. A good understanding of stakeholders can be an asset for everyone involved in an initiative.

Identify stakeholders

Start by listing all the people involved in the project. You can list individuals (for example business representatives you know by name) as well as groups (a group of end-users for instance).

Who is responsible for which part of the project? What is their role? Prepare a tree structure of people in your organization. Make sure that all the people involved in your diagram are in the project scope. What influence do they have on your efforts? Try to be precise, but concise at the same time. You can assign each stakeholder to one of three types: (1) Provides business analysis input — you need information from them to conduct your work. (2) Relies on business analysis input — they need information from you to conduct their work. (3) Two-way relation — you need some information from them, and they need some information from you. What is their attitude toward positive and negative impacts? What affects their actions and behaviors? Think about how they talk about the project. Are they willing to take risks to make the change happen? Or maybe they are reluctant to your efforts and are against the project? Try to define their motivations as well. What is their work style? Focus on technical aspects (What hours do they work? Are they open to meet with you every day, or maybe only once a week?) as well as interpersonal ones (Do they prefer to work alone or in a group? Are they easier to communicate with indirectly by emails, or directly by meeting or call?). What is their experience working with a business analyst? It’s highly probable that some of your stakeholders have not yet cooperated with a business analyst and maybe don’t even understand the importance of such a role in the project. It’s valuable to detect these stakeholders and make sure to explain to them what your role is and how you will be involved in their everyday work. What is their position in the organization and knowledge about the needs? It is important to define what is the level of authority, meaning the formal power, of each stakeholder. The informal power — influence — doesn’t always go hand in hand with the formal one, and is also vital to be recognized. Think also about what knowledge of needs they have. People with less power can still have a better knowledge of what, or how, should change in the organization. Will they able to see the potential risks in the project? Can they be helpful in recognizing the limitations of the proposed solutions?

If you want to categorize your stakeholders even more, check a great article that Robbin Schuurman wrote on that topic.

Communication plan

When you already know everything about your stakeholders, you can focus on how to collaborate with them. Think about the following issues:

The timing, frequency, and location of the collaboration meetings. It’s crucial to define if all of you can meet on-site, or if it’s better to do it online. Think about how long and how often these meetings should take. Who should take part in these meetings? Sometimes you will prefer to meet individually, sometimes in a small group, and sometimes in bigger workshops. Plan this ahead, bearing in mind the specificity of each stakeholder you have already prepared. What tools can we use for collaboration? Where to store all the documentation? Each meeting will produce some conclusions you will need to note down, verify, and maintain later. Think where to store them, so they can be easily accessible by all stakeholders. I use mostly Slack and Jira, but there are a lot more to choose from. Plan your day-to-day communication as well — will you talk in emails or should you invite stakeholders to Slack? Level of formality. Will all the meetings need to be planned ahead? Or will it be okay also to schedule a meeting spontaneously, when some questions arise? Do the conclusions from the meeting need to be formally sent by email? Or is a Slack message enough? How the stakeholders can collaborate amongst themselves? Not always will the stakeholders need you as a facilitator in the meetings. Look for the opportunity for stakeholders working with each other, and help them organize the collaboration if needed.

Monitoring stakeholder engagement

After you have started working with the stakeholders, based on your stakeholder engagement approach, you need to monitor if the plan is going smoothly.