Part II – Stakeholders and supporting processes for gathering proper requirements
Stakeholders and theirs Roles in the process of creating requirements
Engaging proper persons in the project or process is a clue and guarantee of the quality of outcomes. The requirements gathering project should also begin with defining the roles in the process. And this is how this is done in practice.
First of all, you need to define the necessary roles for the project, then select the representatives for those roles, and at last go through the process of defining requirements. I am describing this here only to better emphasize the importance of the proper selection of stakeholders for the whole process of creating and managing requirements.
Stakeholder – anyone who will influence the process of gathering requirements, define the requirements or use the final product. Typical stakeholders include:
– the product owner – decides about investment in the product, reports the general level requirements. Needed at various stages of work on requirements. Necessary at the stage of defining the Vision and acceptance of the set of developed requirements for further work, for investment. This is the decision-maker function in the product development process. This stakeholder decides what should be eventually delivered.
– user of the product – the persons who will eventually use the product, both from the operational and management sides. Any product user suggestions at the stage of developing the requirements are very important for the completeness of the requirements. The user provides very detailed information about how the process works, which can be translated into a well-defined requirement. However, it should be borne in mind that the way product users look at products and processes is very much limited to the users’ own perspective. Users carry a burden of their own experiences with currently existing systems or with other systems they work with. All these limitations should be kept in mind when processing the user’s requirements proposal.
– supervisor – the person who oversees the work of the entire team, controls the correctness of the allocation of resources and, in larger organizations, is responsible for the project at the political level. The supervisor’s involvement in creating the requirements is very small, especially in terms of providing essential input. However, the supervisor has the power to stop or redirect certain works and has influence on many participants in the process. This person should be properly informed about the progress of the work, to avoid that their decisions cause unnecessary impediments or delays in the development process.
– Requirement Gathering Process Manager – this role can be performed by the project manager or the analyst appointed by the project manager. What’s important to emphasize here is that the process manager acts as a liaison between the deployment team and the stakeholders to ensure the proper communication and cooperation. His or her role is not only managerial or analytical: it should combine both. He or she should to some extent understand the essence of the requirements, be able to analyze them to facilitate the process of communication and of understanding the requirement for the deployment team or its representatives.
Implementation team – composed of business analysts, systems analysts, security architects, developers, domain experts.
It is not always possible for all relevant representatives of the implementation team to be involved in the requirements development process. Of course, the level of their involvement should be appropriate to the methodology of the whole project management and the type of requirements. If the project is managed in an agile way, the deployment team will be deeply involved in it from the very beginning. A more waterfall approach limits the contacts and communication between the stakeholders and the deployment team members. In such a case the project manager should ensure the minimum: the representative of the deployment team should play an active role of a liaison between the implementation team and the stakeholders to build, as much as possible, a common understanding of every requirement that has been developed. It is crucial that the close cooperation approach regarding the development of the individual requirements be discussed and agreed upon.
Why is the involvement of the deployment team so important at this stage even where we are not managing the project using agile philosophy and though there is no decision to launch the implementation yet? No matter how precisely the requirement is described, if the executive team gets to know the requirements only after they have been created, it will need additional time for processing and understanding them. So, a series of interactions, meetings and workshops will anyway be necessary to achieve the expected level of common understanding of the requirements. Often, some of the requirements need to be verified and improved. The saving of resources at the early stage is a false economy. With the deployment team working on the development and refining of the requirements from the very beginning of the requirements development process, the benefits for the whole project are enormous.
Supporting processes
Finally, one should bear in mind some of the important supporting processes without gathering requirement process itself may not be properly carried out or the achieved results may not be so good as originally assumed. These supporting processes consist of: communication, negotiation and mediation, and lobbying.
Communication – providing access to work status information for all participants in the process. Access to current documentation. Access to plans, schedules, and deadlines. Access to meeting notes. Preparation of relevant questionnaires and related manuals to exchange data between process participants. In the age of digital clouds and multiple-access database solutions for accessing the documents over the network, the communication possibilities are enormous, but we often tend to forget about them. What is important is to choose a solution that all the participants of the requirements creation process can access and have the technical capabilities to use it, and to provide such participants with user manuals. The most useful task control tools are Kanban and scrum tables. It can even be a simple list on a white board with process steps drawn on it, supported by a shared disk for electronic document registration. These tools are ideal for supporting interactive and iterative approaches, as assumed in the IIRM Model (Interactive and Iterative Requirements Management Model). They are intuitive in use, facilitate communication among team members and clearly present the status of work progress in the process. Everyone can quickly understand what requirements are reported, identify the requirements currently being developed and postpone those that have passed the verification criteria, and finally retrieve those that should still be improved, complemented or redefined.
Negotiation and mediation – the essence of the process of creating requirements are perpetual negotiations – from the beginning to the very end. It is a constant search for a solution that will be satisfactory to every participant engaged in the process and which, at the same time, will be consistent with what has been envisaged in the Vision. The Requirement Gathering Process Manager is obliged to negotiate with each participant on the scope of content delivered, the due dates and quality level, the costs and engaged resources. However, mere negotiations are not always enough. The manager needs to be able to become a mediator among the stakeholders or between the stakeholders and the executive team. Often, at the edge of the two worlds disputes appear or even acute conflicts. Mediation skills will certainly be helpful in such situation.
Lobbying, communication and negotiation, while important and critical, they don’t always work at the expected pace as required for a smooth task execution in a given time frame. There are situations within projects when the manager needs to be ready to utilize other means of persuasion to get a good range of requirements on time. What’s essential for the lobbying to be effective is the proper stakeholders’ analysis and understanding of their interests, as well as the appropriate communication and persuasion techniques. We only mention this aspect of activities here. The larger the organization involved in the process, the more lobbying is required, and the importance of the lobbying process becomes greater. Lobbying is a tool of sensitive nature and it should be used as part of the whole communication strategy of the project.
Summary
Summing up the above considerations, the path to well-defined requirements can be traced in 5 simple (seemingly) steps.
- Identify the right stakeholders; identify them as specific people in the organization.
- Assign roles to specific people in the process, negotiate and agree on their rights and responsibilities.
- Establish and communicate the processes of reporting, reviewing, rejecting, and accepting requirements. The processes may be based on the adaptive APM model, i.e. the IIRM Model for gathering, defining and developing requirements in accordance with agile philosophy, regardless of the project management methodology.
- Agree on the rules of cooperation with the deployment team at the requirements development stage and prepare the team or its representative to work on the requirements.
- Establish criteria for selecting well-defined requirements. The INVEST approach to the criteria may be helpful.
However, the most important thing is to realize that regardless of the methodology used for the entire software development project (whether agile or waterfall), the process of creating requirements is not linear. It is important to ensure cyclical iteration, direct communication in an interdisciplinary team, and close collaboration. The entire software development project can benefit enormously from such an approach.
