People have a major impact on the vagaries of requirements. All of the strengths and weaknesses that individuals and groups bring to the table will influence the final requirements product. A few of the more intractable contributors to requirements variance are:
- Lack of experience
- Human nature
- Communication
- Organizational politics
We’ll discuss the first two today and deal with points 3 and 4 on Monday.
Two types of experience are the most germane to this discussion. The first is whether participants have knowledge of the problem space from a business perspective. Without that, the requirements may not practically address the project needs. Knowledge of and experience in the problem space is critical for effectiveness. One technique that has been developed to mitigate this risk is to ensure access to business knowledge through co-location with a business partner. This kind of access is a central tenet of the most of the Agile methods. The second category is experience with the requirements process itself. Without experience gathering, recording and managing the requirements process, it will be difficult to ensure information gathered is correct and that the results developed will be apt to be more costly than necessary and less valuable than needed. Agile methods use coaching to reinforce this knowledge and experience, while other methods use training and processes. The goal is the same in both cases: efficiency and effectiveness.
Human nature can act as tool to focus or redirect the requirement process. Watching several requirements gathering systems has lead me to the conclusion that there is a natural tendency for groups to jump to defining the solution before defining the need. This can lead to a number of communication issues. Needs provide a locus for grounding the work, which focuses the solution. It is important to remember in the grand scheme of life needs change before the solution changes, rather than the solution changing the need [even though in exceptional cases this can be true].
There are a number of tactical solutions for all of these issues, however the first step to solving requirements issues that are people-centric begins with recognizing that a problem exists. One best practice that I would recommend, taking a page out of the Agile handbook, is to use coaches to support the people working on gathering and managing requirements. The role of coaches is to be the voice of the people focused inward on the team and the work. A coach observes how work is done, provides support and instruction in a consistent and focused manner when and where it is needed. This role is different from that of project manager which is externally focused, interacting with outside parties and clearing external roadblocks. While people are not the only factor driving the quality of requirements, they are a critical factor. Pay attention to how people are being deployed, provide support and instruction and make darn sure the right people are in the right place at the right time.