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.

Prioritization of stakeholders for software requirements

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.

Stakeholders prioritization influence matrix

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

You may also like...

1 Response

  1. tom gilb says:

    Good paper Ulf, but of course I have some thoughts –
    It is logically necessary to include non human stakeholders, such as law and standards, if we are to derive all necessry requirements. Most people miss this point.

    DETAILS
    Consider the definition of stakeholder (from my Planguage and CE book)
    Planguage Concept Glossary as edited in Competitive Engineering book 2005
    http://www.gilb.com/tiki-download_file.php?fileId=387

    Stakeholder Concept *233 May 10 2011 (‘defined’)
    A stakeholder is any person, group or object, which has some direct or indirect interest in a defined system.

    Stakeholders can exercise control over both the immediate system operational characteristics, as well as over long-term system lifecycle considerations (such as portability, lifecycle costs, environmental considerations, and decommissioning of the system).

    The parameter ‘Stakeholder’ can be used to specify one or more stakeholders explicitly. We can attach stakeholder information to any elementary specification, or to a set of specifications, as appropriate.

    Stakeholder :
    An interested party having a right, share or claim in the system or in its possession of qualities that meet their needs.
    Source: Standard ISO/IEC 15288:2002] and ISO/IEC 25000
    NOTE Stakeholders include, but are not limited to, end users, end user organisations, supporters, developers, producers, trainers, maintainers, disposers, acquirer, supplier organisations and regulatory bodies

    Notes:
    1. The views and needs of stakeholders have to be sought and listened to. For example, stakeholders might have an interest in:
    • setting the requirements for a process, project or product
    • evaluating the quality of a product
    • using the product or system, even indirectly
    • avoiding problems themselves as a result of our product or system
    • the system or product being compatible with another machine or software component
    • determining the constraints on development, operation or retirement of the system or product

    2. Stakeholders specify requirements, directly or indirectly, for the system attributes (function, performance, resource, design constraints, and condition constraints). They determine the degree of product or system success or failure.

    Some stakeholder concepts. Courtesy Gerrit Muller, Philips, Eindhoven, NL. In
    “Requirements Capturing by the System Architect”
    [Editor Note to Publisher: EDIT NOTE: PERMISSION GRANTED TO USE THIS IN EMAIL 9 NOV 2001 FILED IN PERMISSIONS FOLDER TG]

    3. Systems engineers should determine which requirements the stakeholders need, and which requirements they can afford. Even if the stakeholders are not currently conscious of those needs and limitations!

    Example:
    Goal [Stakeholders = {Stakeholders = Installers, Service People}, Deadline = End This Year]: 60 hours ← Marketing Authority.
    Marketing Authority: Stakeholder: Our Service Organization.
    The Goal requirement applies to a set of defined stakeholders. The requirement authority (the one who has requested this Goal level) is defined as another stakeholder.

    4. Stakeholders can be internal or external to a system. Internal stakeholders are typically in our development organization, or related to it or to the development process. External stakeholders are users and customers of the developed system. Very external stakeholders are instances like laws and government organizations that can impose requirements on our system. This distinction is useful:
    • to help us develop better lists of stakeholders
    • so we don’t get fixated on the ‘customer/user’ as the only requirements source
    • to give us a systematic set of (internal) stakeholders to deliver to, as we evolve the system, even when it is not ready for external stakeholders.

    5. Stakeholder classes RACI, which stands for Responsible, Approver, Consulted, and Informed. This might provide valuable detail rather than a simple clump of people within the stakeholder. <- Erik Simmons

    6. : I suggest we can generally classify stakeholders with these concepts:
    Stakeholder Hierarchy
    = any set of Client Stakeholders and their Server Stakeholder relationships.
    Client Stakeholder
    = any stakeholder with needs that any server stakeholder might satisfy.
    Server Stakeholder
    = any stakeholder that plans to satisfy some client stakeholder needs.

    Keyed Icons [Stakeholder *233]:
    : – | Stakeholder or Neutral Stakeholder converts in Word to :|
    : – ) Happy/Satisfied Stakeholder converts in Word to ☺
    : – ( Unhappy Stakeholder. Converts in Word to ☹

    Related Concepts [Stakeholder *233]:
    • Owner *102
    • Client *235: Synonym is Customer
    • Sponsor *396
    • Consumer *038: Synonym is Customer
    • Decision-Maker *237
    • User *234
    • Designer *190