How to identify stakeholders

by Ulf Eriksson / 16 May 2012 / 4 comments

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.

How to identify stakeholders

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.

About the author: Ulf Eriksson

Ulf Eriksson

Ulf is the founder of ReQtest and as the Product Owner, decides what features are added to the product, and makes sure that ReQtest is of a consistently high quality. Ulf has written several books and courses as well as a library of articles on the subjects of testing and requirements management, as well as speaking publicly on a number of subjects related to the world of testing.

4 Comments

  1. [...] Read the article “Identifying stakeholders” to learn how to find good sources of requirements and details; http://www.reqtest.com/newsletters/how-to-identify-stakeholders/ [...]

  2. [...] in requirements management, you will obviously need to understand your stakeholders’ needs. Stakeholders may be clients, users, decision makers and anyone else who somehow influences the future system [...]

  3. [...] 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 [...]

  4. [...] the environment around the system changes, so it’s a good idea to periodically conduct a stakeholder analysis. I recommend you carry out a stakeholder analysis at least once a year throughout the maintenance [...]

Leave a Reply

Your email address will not be published. Required fields are marked *