Is there more to the usage of the requirement gathering process? Or in other words, are requirements used for more than just the details of the software and product work to be done? I would argue that in some organizations, the requirement process has turned into a way to help manage a team. Leadership uses the requirement process as a management, oversight, and budget tool.
Requirements become a way to measure the work and effectiveness of the team. Thus requirements are a tool for leadership to manage a team. Requirements started out as the definition of work to be done. But as the process has improved and evolved over time, it also has taken on other purpose.
It now is used to make leadership feel more like resources are being used appropriately, time and money is being spent correctly, and just an oversight tool in general. Which, I do not mean to say those are bad things. I would simply state that some degree of that is needed, and there are better ways to do this. We should keep oversight and the process to manage a team separate from the work of the team to build software products.
Requirements can be just another tool to manage teams
Back to this process of using requirements as a tool to manage the team. In typical, and more so traditional, software and product development, teams gather a lot of requirements to define the work. There is a great deal of process to define them, organize them, and plan work around them. Their is the assignment of resources based on the requirements.
There is also the time estimation and budgeting of the work, based on the resources. By using requirements to track if work is done according to time estimates. And also to track if work is done within the budget, you are essentially using process this process to manage a team.
However, besides points already made, I would say its also a flawed practice because requirements are not equally weighted according to time or cost. Some requirements take much longer to complete than others. Some requirements are much more expensive than others. Thus measuring completion success, while in progress, according to requirements is flawed. Unless you are purely looking to see forward progress.
Management doesn’t see that though. They look at the work in numbers. They see dollars to do the work. That is weighed against current revenue and potential revenue of the new work. When things are lopsided, they get nervous.
What do do about it
So what is my recommendation then? How can these different processes live together peacefully? Sprint velocity and team capacity can be used to measure team effectiveness. Looking at how much output a team can consistently deliver and measuring that sprint after sprint is a great method to assess the effectiveness of the team.
That also then frees requirements to be requirements only. The definition of work to be done and what is to be delivered. When free of some of the red tape that slows the team down, they can be more collaborative, and creative, and truly deliver really great software products to the organization. Which will bring value for the organization.
Additional reading that helps to manage a team
Another great read is on lean practices. Being more lean can help focus more on the important things, and thus also not spend effort on duplicated processes like using requirements to manage a team. A great read on lean here.