Who is important to talk to about requirements? / Hebrew

Who is important to talk to about requirements? / Hebrew

When I worked in custom development, the interested parties were essentially appointed. Who was selected to talk to from the customer, that’s who you talk to. The analyst was not allowed into the internal kitchen enough to understand what weight this “designate” has in the company. When she found herself in internal development, she initially moved along the usual path. Whoever brought the request sought the requirements. Who comes more often and shouts louder, the demands are more important. I began to distinguish the characteristics of the interested parties only when I realized that the requirements are somehow difficult to agree on and generally turn into a complete “wrong”.

Roles

A role defines the tasks that a stakeholder is responsible for within the organization. It happens that these tasks are not completely obvious from the formal job title. How far to walk? For example, somewhere an analyst may be responsible for architecture tasks, design, and user documentation, and somewhere he is responsible for drafting requirements and a little for testing.

People often comment on requirements outside of their area of ​​responsibility, this is very noticeable in the approval of large documents. Understanding the role helps to decide which comment will definitely have to be taken into account, and which one should be politely thanked.

Relations

Anyone who is interested in the results of your task can provide more information, 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 “in the field” to communicate with end users, he often sees very high interest. These are the people who stumble upon our fields and buttons every day! They have many ideas and requirements. Back at the workplace, the analyst finds that the decision-makers see priorities differently.

Attitudes to the task may change over time and this also needs to be monitored. For example, if a feature is not implemented on time, then interest may decrease.

Powers

It would seem like an obvious thing – decision-making authority, 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 one of the key experts on his team, rather than the director, will negotiate the requirements or provide information.

Sometimes it’s the other way around, where we think someone with whom we’re contacting about requirements can make a decision, when in fact they don’t. Once I gathered a whole group of people for a long time on the issue of working with reports, and they honestly came to the meetings and tried to tell and formulate something. It was impossible to formulate. The question was not in their sphere of authority, and for some reason it was not clearly stated at the meetings, perhaps because of the fear of losing status, but no one was ready to make a decision. There were many unnecessary conversations, the issue was resolved at the highest level of decision-making.

Level of power or influence

This characteristic does not necessarily coincide with the role or position of the interested party.

Many teams have employees who have been with the team for so long and are so deeply involved in the process that their opinion is trusted without question and is often referred to in decision-making, especially in operational activities. I remember a case when, when agreeing on new system functions, I did not discuss them with such an influential expert. He was on vacation at that time, I did not wait for him. Then we had to wait for the entire IT team when he made a comment already at the development stage. It was impossible to ignore the comments due to the high influence of the author.

Understanding the alignment of forces among stakeholders helps save time. It is possible and necessary to search for information in various sources, but it is better to form requirements for implementation from it, taking into account the characteristics of interested parties.

Note on the roles of interested parties

Related posts