A Project Manager’s guide to stakeholder management in Agile

Who is a stakeholder?

According to “Mastering Business Analysis Standard Practices”:

A stakeholder is a group or individual with a relationship to the change, the need, or the solution. A stakeholder is any person, group, or organization that may impact, be impacted by, or perceive itself to be impacted by a project, program, initiative, operation, or portfolio

Um, okay… But what does it mean in practice? In order to answer that question, we need to talk about the role stakeholders have in the software development process. They can make the project’s requirements a little bit messy. The reason is simple – people have different opinions on certain aspects of the project (often contradictory with each other) and not everyone will have the same positive attitude towards every idea and solution.

Before stepping into the project, it’s necessary to know who actually is a stakeholder. Is it a user? The development team? Product Owner?

Stakeholders are all the people who have a personal interest in a project. It includes investors, creditors, employees, and suppliers. The interest may come for a variety of reasons. It may be a direct relationship for example – such as employment, ownership, or investment.

Also, it’s important not to mistake a stakeholder for a shareholder. Citing Investopedia: 

Shareholders are always stakeholders in a corporation, but stakeholders are not always shareholders. A shareholder owns part of a public company through shares of stock, while a stakeholder has an interest in the performance of a company for reasons other than stock performance or appreciation.

How do I know who is a stakeholder in Agile?

In an ideal situation, your client should provide you with a list of all the people engaged in a project. Moreover, if you work in Agile – the Product Owner should know everything about them.

Unfortunately, the reality is not that perfect. That’s why before you start planning anything, you should carry out the analysis of Agile stakeholders with the client and the Product Owner.

It’s a good practice, to write down all the people or groups who will be affected by your software. Remember that the biggest risk when analyzing stakeholders is… to forget about someone. How to avoid that? Let’s use the onion analogy. 

Peeling the onion a.k.a. stakeholders’ analysis

Some people may compare stakeholders’ analysis with… onion layers. And it’s not only because both can make you cry. First and foremost – the analysis of stakeholders may be really crucial for the project.

One of the most common mistakes is to miss someone. Just imagine what can happen when something like this happens. At the beginning of my adventure with analysis, I experienced something similar. Accidentally, I forgot about the most important group – developers… 

They quickly reminded me that they also wanted to have an impact on the project. Not only in terms of the technical requirements but also in possible solutions – due to their professional experience. It turned out that their solutions were actually easier to implement.

Another example is about focusing only on the decision-making people, forgetting about the real users. One of the recent workshops made me realize that the management’s vision of the need for a solution may be different from how users actually use the system. 

You can have a system that no one uses because it doesn’t address the needs of end-users. A great example is Nokia and some of its phones, e.g. the models 3300, N-Gage, and 7600 which initiated lots of memes.

In the documentary film “Nokia: We Were Connecting People” there is a story of the 3300 model which had buttons… that didn’t work. Why? Because the backend lacked those functionalities. Why? Because they weren’t properly discussed with all the stakeholders. Simple as that. No to mention that the shape of this phone, in my opinion, was not really user-friendly.

Now you know that any mistake at this point may cause some big changes in the architecture in the later stages of the project – and worst-case scenario – it may destroy the whole project. That’s why it’s important to invest some time and energy to study:

• client’s business,
• project’s goal,
• organizational structure,
• existing processes, reports, data,
• internal or external media such as blogs, online chat forums, newsletters, and social media.

During analysis, most probably you’ll have a chance to talk to some stakeholders. There will be some brainstorming, workshops, and so on. It’s necessary to remember that the process of analyzing stakeholders starts with the project kick-off and it lasts until the whole project ends. That’s why you should update the list of stakeholders regularly.  

Once you wrote down the list, you should discuss and agree on channels of communication. Also, it’s good to set the groups of people who will be involved in a project and their roles. Remember though,  that not everyone will be involved in a project in the same way. That’s why you can use the aforementioned onion analogy to set priorities. 

It’s one of the techniques which can help you determine who is the most important. You can use “onion layers” to divide stakeholders from the closest to your project (layer 1) to the farthest ones (layer 5).

Layer 1

Solution: the product, service, or result being created;

Layer 2

Solution delivery: the solution domain stakeholders, PM and/or Scrum Master, BA and/or Product Owner;

Layer 3

Domain: the stakeholders in the area of the business being affected;

Layer 4

Business, organization, or enterprise: the stakeholders who interact with the affected domain stakeholders;

Layer 5

External: the stakeholders who are outside the business, organization, or enterprise.

There are, obviously, different methods for group stakeholders. If you read through some specialist literature, you’ll find the division to external/internal or active/passive. However, the “onion diagram” is the one I find the most accurate. 

How to properly prioritize the requirements?

So, once you determined all the groups of stakeholders, now it’s time to establish whose requirements will be the most important ones. How to prioritize those? According to the “I pay – I demand” rule, the investor of your solution might have the most to say in this matter.

Nonetheless, it’s good to try and break through this barrier to reach the real user. I know from my personal experience that sometimes the vision of management is extremely different in comparison to the user’s needs. The end-users who are the target group are able to report different issues and needs than sponsors and other superiors. That’s why it’s so important to reach the target group. Finding people who have a positive approach towards your solution and who can help you encourage others – ideally through mentoring.

To do it, you can use a technique that is used in marketing and divide your stakeholders into four groups.

• Opposer: a stakeholder who is resistant to the change and isn’t concerned with implementing the change. An opposer has important requirements associated with the potential risk that you will need to elicit.
• Conductor: a stakeholder who provides advice and direction regarding the requirements for the change. A conductor also has important requirements associated with potential issues and risks.
• Advocate: a stakeholder who is an active promoter of specific requirements associated with the change. An advocate often has technical advice and specific knowledge that will help you throughout the change life cycle.
• Change Agent: a stakeholder who is completely integrated into the change. A change agent is ultimately responsible for ensuring that the delivery of the change activities results in success.

The diagram below shows it more clearly.

It’s one of the methods of using the so-called stakeholders’ map or stakeholders’ matrix. The map presented above shows the engagement of your stakeholders in your solution. It doesn’t answer the question: “whose requirement is more important” though. To answer it, you can use another stakeholders map. 

The power/influence matrix compares the stakeholder’s level of authority with the stakeholder’s amount of active involvement.

In the top right corner, you place the most engaged stakeholder, who has the biggest influence on your project (for example sponsor). Once you group stakeholders and you know which requirements have the top priority – it’s time for a more difficult phase – stakeholders management.  

As I mentioned above, the biggest risk during the analysis is to skip any groups which are important for the project. Another risk is about managing them. You can use yet another map to make it easier. 

The power/interest matrix compares the stakeholder’s level of authority with the stakeholder’s level of concern.

In the bottom left corner, you place people who should be contacted from time to time to check if they engaged in the project more than in the previous phases. On the opposite side, there are people who manage the project closely and who present requirements.

Thanks to the map above, you can take care of the stakeholders’ satisfaction. Also, you can build trust in your work. Citing one of the texts from below bibliography: 

When trust is low, the speed slows down and costs go up. Conversely, when trust is high, the speed accelerates, and costs go down.

Summary

Summing up, Agile stakeholder analysis is not easy but with the proper background is doable. Theoretically, it might seem like the Product Owner’s job, however, it’s good for you to go through this analysis on your own to make sure you understand stakeholders and the requirements’ priority. It’s important to remember not to omit anyone. Once you have the list of stakeholders, it’s important to define their engagement and set priorities. It can significantly improve stakeholder management in Agile. Also, you should agree on certain communication channels to build trust and improve cooperation. The last step is to create the list of persons for the chosen groups from the map. But this is the topic for a completely different story. 

Bibliography

Mastering Business Analysis Standard Practices; Kelley Bruns, Billie Johnson

Hanna Wesołowska, analiza.it 

Dawid Lewandowicz