This essay was used on SPaMCAST Seven (www.spamcast.net).
Why Are Requirements So Hard To Get Right?
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. In my opinion, identifying requirements is difficult because getting it right requires nearly a perfect storm. A perfect storm requiring the confluence 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 a seemingly least controllable of all of the variables (people, process and environment) 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. 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’. A few of the more intractable contributors to requirements variance are:
1. Lack of experience
2. Human nature
3. Communication
4. Organizational politics
Two types of experience are the most germane to this discussion of the requirements development process. The first is whether participants have knowledge of the problem space from a business perspective. Without knowledge of the problem space, the requirements developed may not practically address the project needs. Knowledge of and experience in the problem space is critical for effectiveness. Lack of knowledge is a risk which has lead to the development of many techniques for managing this type of risk. One technique that has been developed to ensure access to business knowledge. The technique is to ensure access to the business partner through co-location. This kind of access is a central tenet of the most of the agile methods. In short keep knowledge and experience close at hand.
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 result 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 rather than beginning by defining that need/pain. Not defining the pain / need 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).
Communications problems can be a result of other processes and problems however there are communication problems that are deeply rooted in the act of communications. The problem is that many people just don’t communicate well;
- They don’t listen because they think they already to know the answer,
- There are those that do not know enough about the business therefore can not interpret what they hear,
- There are interviewees that don’t choose to answer the question asked,
- or Interviewers that don’t ask the right question,
- Or interviewees that are the wrong person to interview.
The list could go on further; there are just lots of things that can go wrong. Communication is a combination of getting the right people with the right knowledge facilitated correctly all in the right place at the right time.
A final potential problem is a topic called solution driven requirements (also called a solution searching for a reason or an answer searching for a question). Unfortunately humans are great at recognizing patterns, a solution is a pattern. Pattern recognition is a survival technique however even though a survival technique, it has drawbacks when used while gathering requirements. Gathering requirements with the solution already in mind like a solution hunting for a problem which can reduce the effectiveness of data gathering. Anything that potentially blocks the ability for interviewees to express themselves freely or for interviewers to hear business needs can potentially create a scenario where errors or omissions occur. Remember when you’re looking for a hammer you’re apt to see is a hammer and not the pliers sitting next to it.
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 the use of coaches to support the people working on gathering and managing requirements. The role of coaches is to be the voice of the people. The role is 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.
