How to Identify Stakeholders

This article originally appeared on Konsultbolag1

A common problem in requirements management for IT systems is that stakeholders are often overlooked. This causes complications, and occasionally, even interpersonal conflicts. No one likes being left out, especially if they have an important role to play.

Unfortunately, development teams often become aware of this problem late in the process. Correcting this issue often means costly rework and client dissatisfaction. In this post you will learn how to use a workshop to perform a stakeholder analysis and create your own list of stakeholders within a project.

A good place to start is by creating a typical list of stakeholders. This will vary according to the industry or scope of the project, but a typical stakeholder list would include:

• Customers
• Customers’ customers
• Users
• Developers
• Marketers
• Product Managers
• Testers
• Authorities/regulators
• Laws/company lawyers

This list can help you to identify stakeholders, but because as said earlier, stakeholders are different for every system, you will need to conduct a stakeholder analysis. We like to carry this out in the form of a facilitated workshop.

Your participants in the workshop might include people who were involved in a feasibility study, or representatives from both the client and the system provider.

One way of starting the exercise is to simply write the name of the project or system in a circle in the middle of a whiteboard.

Let the participants brainstorm all the possible stakeholders. They should write the name, role, or organization of each stakeholder on a post-it-note and place it on the whiteboard around the circle.

Next, draw an arrow between each stakeholder and the project.

Divide the participants into groups and distribute the stakeholders between the groups.

Give the groups around 30 minutes to discuss what each stakeholder gets or requires from the project, and what the project needs from or gets from the stakeholder.

After 30 minutes the groups should present their findings. Write down what the stakeholder requires or receives from the project on one end of the arrow, closest to the stakeholder, and what the project requires or receives from the stakeholder at the other end, near the project.

After all the groups have presented their findings and your workshop is complete, you will have produced the material for a table similar to the one below.

This method is not perfect and may require practical tweaking in situations with a large number of participants. However, it does provide a solid base from which to start.

Keep in mind that certain requirements are to be discussed in more detail than described above, and with people who are specialized in that field. For example, any design work requirements should be relatively simple, especially if a senior designer attends the stakeholder meeting above, but other requirements, such as the law, are far more complex. Do set aside plenty of time to discuss in more detail where required.