Stakeholders; Who, What, Where?

If we don't know why and for whom we build features, how can we possibly distinguish between what is important and what is not?

Developing software and websites is labour-intensive work. We nearly always have to cope with tension between budget, run-time and undesired functionalities. How do we ensure that we make the right choices and create an optimal coordination between budget, run-time and functionality?

If we don't know why and for whom we build features, how can we possibly distinguish between what is important and what is not? Requirements and wishes always come from stakeholders (interested parties). It is very important to start with a complete overview. Who are the future users? Who has a direct interest in the solution and who sets clear boundaries for what is and is not possible?

The Stakeholder Model

There is an easy way to achieve this overview in a short period of time. We use a Stakeholder Model for this purpose. This is an easy-to-use model, in which multiple people can collaborate. Adding game elements also often works very well. The model is subdivided into 3 circles, in a horizontal line (internal, external) and a vertical line (management, operations). This yields 12 fields. We put the Stakeholder model on the wall, explain the model in 5 minutes and let our customers fill in the model themselves. If possible, we let 2 groups do this. This requires at least 4 participants. After filling in, we let the groups present the model and provide feedback. This gives rise to a complete idea of the various stakeholders.

Whom should be taken into consideration?

In the third circle, we place all parties that will not be using the system, do not have a direct interest, but that do set boundary conditions (constrainers). Here too we distinguish between internal and external interested parties and interested parties on a management and operational level.

Now that we have mapped the Stakeholder, we can continue mapping the requirements and wishes of the stakeholders. This can be done in user stories as well as in requirements. Also the non-functional requirements, particularly from constrainers, are recorded in user stories or requirements.

Who has a direct interest?

In the second circle, we place all parties that have a direct interest in the system. They will not be using it, but do have a direct interest in it. This group must not be ignored. This group usually includes the client and budget responsible. This group is also divided into internal and external interested parties and interested parties on a management and operational level.

Who are my users?

In the middle circle, we place the users of the system with post its. We divide these into internal users and external users and management and operational users. The distinction is important to better understand the users' background.