The November 15, 2005 issue of CIO Magazine leads with the headline “Rethinking Requirements” and includes an article titled
Although I found the article to be an interesting and worthy read, it did not quite live up to its title. This is not meant as criticism as much as it is an effort to support truth in advertising. Rather than the explicitly prescriptive discussion that the title suggests (at least to me), the article presents four case studies that reveal how different organizations chose to address their particular challenges with requirements. I don’t know if this was the author’s primary intent, but his approach provides an implied lesson that I believe is a key signpost on the road to better requirements.
The case studies include:
- ADP Employer Services Canada drastically cut scope down to 10% of the original plan
- Bank of Montreal Financial Group created a formal course of certification for business analysts
- Capital One adapted the precepts of Agile development
- P&G Pharmaceuticals focused on tracing every line of code back to the business process it supports
I have intentionally waited on writing this post because I was curious to see what type of comments, if any, CIO’s readership would have for this article. I was not disappointed as there were 18 comments supporting perhaps 24 different opinions posted within 2 weeks of publication. My expectation had been that no consensus of any sort would arise from the pool of reader responses and this ultimately proved to be true.
Some of the more interesting (paraphrased) comments include:
- You need to do a better job of elicitation by using the classic techniques
- You need to do a better job of elicitation by using entirely new techniques
- Start coding immediately and be agile
- Don’t start coding immediately but rather go slow to go fast
Among the many comments that are so wonderfully diametrically opposed, the post I found most interesting is the one that I feel does the best job of summarizing the key lesson I suggest readers take away from this article and its associated thread of comments –
How many Product Managers out there have been sent by senior management on a mission to find “the answer” for their organization’s requirements problems only to come back frustrated. Why is this? Because the simple fact is that there is no single answer but rather a whole host of solutions that a Product Manager must be skilled and knowledgeable enough to pick and choose from. Rather than snipe hunting for the silver bullet, the most successful Product Managers realize that successful requirements strategies fall along a normal distribution that ranges from informal, lightweight techniques to formal, ironclad processes. From this distribution they must pick and choose the tools and techniques that will best solve the problem at hand. Now, I have to say that I believe too many organizations have picked too often from the informal end of the distribution, but that is a discussion for another post…
…all the perplexities, confusion and distress surrounding IT requirements arise not from a penury of conviction or resources, nor from a paucity of our virtues, so much as playing downright ignorance on assessing “how much” of the requirements management practice is really needed in an organization for the success of IT projects. Of course, “how much” will need vary from organization to organization and project to project.
