photo (14)IT projects have been around in one form or another since the 1940’s. Looking back in the literature describing the history of IT, the topic of requirements in general and identification of requirements specifically have been top of mind since day one.  There are numerous definitions of ‘requirements,’ however at a high level requirements can be thought of as what the functionality developed by the project should ‘do’. Identifying requirements is difficult because it requires nearly a perfect storm of the correct process, involvement of the correct people for the business problem to be solved (before it is even defined) and an environment that is conducive to making all of the parts work together.  This confluence forms a set of three constraints that are overlaid on flowing time which ensures subtle changes are continually being introduced to all of the variables.  A breakdown of process, people or environment will reduce the effectiveness of the result or render it unusable.  The factors driving the people category are typically the most volatile and seemingly least controllable of all of the variables within the requirements process.  This essay will focus on the ‘people’ category with subsequent essays focusing on process, environment and suggestions for solutions.

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:

  1. Lack of experience
  2. Human nature
  3. Communication
  4. 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.