Who is important to talk to about requirements?
When I worked in custom development, the interested parties were essentially appointed. Whoever the customer assigned to talk to is the one you talk to. The analyst was not allowed into the inner workings enough to understand what weight this “appointee” has in the company. When I found myself in internal development, at first I followed the usual path. Whoever brought the request, I looked for demands from him. Whoever comes more often and shouts louder has more important demands. I began to distinguish the characteristics of stakeholders only when I realized that for some reason the requirements were difficult to coordinate and generally turned into a complete “wrong thing”.
Roles
A role defines the tasks for which a stakeholder within an organization is responsible. It happens that these tasks are not entirely obvious from the formal title of the position. How far is it to walk? For example, somewhere an analyst may be responsible for architecture tasks, design, and user documentation, and somewhere he is responsible for drawing up requirements and a little testing.
People often comment on requirements outside their area of responsibility; this can be very noticeable when approving large documents. Understanding the role helps you decide which comments will definitely need to be taken into account, and which ones will just need to be politely thanked.
Relationship
Anyone who is interested in the results of your task can provide more information and actively load the analyst with their ideas. It is a pity that interest does not necessarily coincide with an important role and authority in decision-making.
For example, when an analyst goes out into the field to communicate with end users, he often sees very high interest. These are the ones who stumble over our fields and buttons every day! They have many ideas and demands. Returning to the workplace, the analyst discovers that decision makers see priorities differently.
The attitude towards the task may change over time and this also has to be monitored. For example, if a feature is not implemented on time, then interest may decrease.
Authority
It would seem like a clear thing – authority in decision-making, but there are nuances here too.
It happens that powers are delegated and it is important to understand this in time. It is likely that it will not be the director, but one of the key experts on his team, who will coordinate requirements or provide information.
It also happens, on the contrary, that we believe that someone with whom we contact regarding requirements can make decisions, but in reality they cannot. Once I spent a long time gathering a whole group of people on the issue of working with reports, and they honestly came to meetings and tried to tell and formulate something. It was impossible to formulate. The issue was not within their sphere of authority, and for some reason this was not stated explicitly at the meetings, perhaps for fear of losing status, but no one was ready to make a decision. There was a lot of unnecessary talk; the issue was resolved at a higher level of decision-making.
Level of power or influence
This characteristic is not necessarily the same as the role or title of the stakeholder.
Many teams have employees who have been around for so long and are so deeply involved in the process that their opinions are trusted without question and are often consulted when making decisions, especially in operational activities. I remember a case when, when agreeing on new functions of the system, I did not discuss them with such an influential expert. He was on vacation at that time, I didn’t wait for him. Then we had to wait for the entire IT team when he made comments already at the development stage. It was impossible to ignore the comments due to the high influence of the author.
Understanding the power dynamics among stakeholders helps save time. You can and should look for information in very different sources, but it is better to formulate implementation requirements from it, taking into account the characteristics of the stakeholders.
