Who Should I Listen To? Prioritizing Organizational Stakeholders

Stakeholders are individuals or organizations who stand to gain or lose from the success or failure of a software development project. This article focuses is on the prioritization of stakeholders within the organization to create the good requirements for a successful project. It presents a process for dealing with internal stakeholders and tools to help to prioritize them.

Author: Ulf Eriksson, ReQtest, https://www.reqtest.com/

Stakeholders are individuals or organizations who stand to gain or lose from the success or failure of an IT system. Within the organization this can include managers, developers and users of a system, amongst others. Since by definition, stakeholders are those who are impacted upon by or have an impact on the software project, their perspectives need to be taken into account in order for a project to be successful.

Stakeholders can have positive or negative views regarding a given project, and often don’t agree with one another. This often makes reconciling their varied viewpoints quite a challenge.

In this article, people who are involved in software requirements management will learn more about how to prioritize stakeholders and get their views into the requirements management work.

Imagine you are developing a sales support system. Sellers, the CEO, sales managers, customers, developers and operations staff will all most probably want different things. The sellers will want the system to do things automatically, so they can spend more time selling and less time working in the system. The Sales Manager might want more statistics and this will lead to more work for the sellers. The developers could want to build a system with the latest technologies so that it is possible to maintain the system for a long period without having to change technology. This makes the system more expensive in the short term. The CEO wants the system to be as inexpensive as possible. Sound familiar? Of course, it does!

The reason why stakeholders have different wills and wishes is that they have different goals.

An important tool for identifying the right requirements is the stakeholder analysis, in which the objective is to identify the system’s stakeholders, including various groups of users. How to carry out a stakeholder analysis is described in this blog post, so take a look at it for more information.

In this article the focus is on internal stakeholders within the organization and the need to prioritize between them. A stakeholder can be in charge of a department, it may be a process owner or group of users who have different desires. The project members have different wills as well, for example, project managers, development managers, test managers and acceptance testers. People who work with requirements management often find it difficult to deal with conflicting desires. Should you, for example, listen to those who shout the loudest? Or maybe to those who represent most users? Who is most important? Whom do I listen to?

The stakeholder analysis is usually a good starting-point.

A process for dealing with internal stakeholders

1. Identify internal stakeholders

Start by listing all the people in the organization who are affected by the project, those who affect your work and those that are interested that the project succeeds. A good way to find stakeholders is by asking yourself about the organizational challenges of the project. Meet the stakeholders and unravel the company structure further to find out more. Ask those you meet who else may affect or be affected by the project. You can then find more information about stakeholders by reading requirements and other documentation. The stakeholders’ influence may be varied; for example, it could be economic or political influence.

2. Prioritize stakeholders

When you meet with stakeholders, you need to document them in a uniform manner so that you can compare their importance relative to each other. One way to do so is to set them up in a table like this:

Stakeholder	Role	Influence	Interest in Project	Goals	Objections
Nikola Tesla	CEO	High	High	Statistics, cost effectiveness, overall image	Dislikes high initial investment
George Stephenson	Sales rep	Low	Medium	System ease of use, reduce administration tasks	Complicated system
Orville Wright	Sales Manager	Medium	Medium	Easily accessible stats and charts for reports to CEO	The system must not take too much of salespeople’s time

This kind of table is very useful for future design discussions. However, you will to decide early on who is allowed to see this. If the table is made public it will be up for discussion and all the biases people have towards their own roles will once again be an issue. One possibility is that only you and the project manager can see the consolidation.

The table serves as a basis for how much focus you will put on the various stakeholders. Stakeholders that both have great influence on and interest of the project should be given the most attention. Stakeholders who have great influence, yet little interest could scupper the project, so they will need to be aware of the project on a high level, but are generally not interested in details. Stakeholders who have great interest, but little influence could be a great help; they often have valuable information that helps the project to move forward. Those who have little interest and little influence should be given the least time, they have neither an interest nor a position that can help the project forward.

3. Detail – Understand the stakeholders’ perspective

Perform semi-structured interviews with the selected stakeholders. An effective technique is to allow each stakeholder list which features are most important, now, in the present and in the future, for example three years from now. What do the system owner and different target groups want to achieve? Compare the goals of the system owner and the target group. If there are multiple goals (?) by target groups, which ones are most important? Prioritize.

The purpose of detailing the requirements is because they will form the basis for further, more detailed requirements, even if at this level, the requirements are not completed business requirements. It is wise to work focused with interviews, so you have them fresh in your mind and can compare interviews with each other. Plan also to supplement interviews with additional interviews later in the work.

Complete interviews with other requirements gathering techniques such as workshops, observation and questionnaires. A good way to use the data is to create personas that represent the different stakeholders.

4. Turn stakeholder needs into requirements

The interviews will give a good picture of the organizations’ and the key stakeholders’ goals. Stakeholder goals will of course not go away just because you know that they exist, and they must be dealt with in the ongoing requirements management process. The best scenario is when it is possible to design the system to meet all stakeholder needs, or at least as many as possible.

For some conflicting requirements, it might not be possible to change the system so that it satisfies all stakeholders. If the president demands that the sales system will supply more data than it did in the past, it could mean that sellers have to enter more data into the system. If the sales manager announces that sellers should not have to enter as much information, these two requirements are in conflict and the problem cannot be solved with a simple modification of the requirements.

Compile information and list the pros and cons of each option. A cross similar to the above can visualize the decision and make it easier to choose the right option. For example, you can look at which of the solutions provide the most value to the organization in relation to the solution which gives the most satisfied users.

5. Follow up

Compare the requirements with the stakeholder analysis and verify that no major requirements have been missed. Revise the stakeholder analysis and priorities. Involve more of the target groups in acceptance testing as they are, after all, the intended user base, so it’s only wise to get them on board as early as possible.

Additional reading

* Ethical Decision-Making and Prioritizing Stakeholders
* Stakeholder analysis a pivotal practice of successful projects
* Using Stakeholder Analysis in Software Project Management
* Customer KPIs in Agile Software Development