“Why Are Requirements So Hard To Get Right: Process”
As noted in the first component of “Why Are Requirements So Hard To Get Right”, getting requirements right is a complex task. People, process and environment must align (or be aligned) to create an outcome that has value and can stand the test of time. In this second installment of the essay we will explore the influence of process of ‘getting it right’.
One of the common process problems the method of approaching each requirement gathering or development situation in an ad hoc manner. Assembling (or making up) a process as you do the work is it at best inefficient and at worst ineffective. My observation is that natural selection will erase this problem over time. Assuming a stable workforce and that is not easy as failing to get requirements right (at least at delivery) is generally viewed as a career limiting move. The tactics that work will naturally be selected overtime if for no other reason than to avoid the beatings that follow failed projects. Unfortunately the process of natural selection takes a long time and with the high probability of staff turnover that occurs in this type of shop, the outcome of trying to all the process without intervention until you find the right on one is . . . ambiguous. There are as many requirements processes as consultants in the world and maybe a few more as a garnish. Processes come in many shapes, sizes and perceived level of discipline. Equally variable as process are the cultures and subcultures of organizations where processes will be applied. The challenge presents of trying to match process or method to culture. While basic rules for match are quickly apparent, such as not matching Agile methods to highly regimented organizations (or if you do, to understand the risks). There are however fewer basics rules than there are gray areas which require guidance. Gray areas abound which makes process selection and tailoring more than a simple trip to the mall to try and shoes on. Before addressing process (requirements or any other process) spend time building a culture map. A culture map is a wonderful tool for plan organizational change, communication and for process selection. Finally, recognize that most change agents go through several iterations before success.
A second process issue, albeit similar, is the failure to recognize that not all business problems can be addressed by a single method. One size certainly does not fit all. As an example, one of my favorite techniques to investigate requirements is the use of brainstorming and affinity grouping sessions. Both are powerful techniques to drive out information and a group data. The technique works best for relatively small, semi-homogeneous groups (also some cultures better than others). They have issues when you are dealing with an auditorium full of people or where groups have very different views of the world. Techniques such as interviews focus groups surveys might be more appropriate these types of situations. One word of caution, even when you have a palette of techniques to apply as the requirements process just because a process works once does not mean it will work again. People, culture change and time go by. I once watched a site manager rip handfuls of little yellow sticky notes off a conference room wall. Frustrated that ideas were being grouped differently than he saw them in his mind. In retrospect interviews would have been better in that environment even though a week before the same environment (on a different less emotionally charged topic). The past is certainly an imperfect predictor of tomorrow. You must have multiple processes and an understanding of when to use and not use each.
One reason requirements are so hard to get right is that the improvement is not as simple as just getting ‘a’ process. While it might be heresy, just getting the wrong process might be worse than none at all. The correct process is one that matches the organization’s culture now and the business problem
