One Size Fits None
The November 15, 2005 issue of CIO Magazine leads with the headline "Rethinking Requirements" and includes an article titled Fixing the Requirements Mess.
Now, I just know someone is going to come along and burst my bubble by revealing this is a recycled story the editors run every few months, but I was pleasantly surprised to see the world of requirements front and center in a magazine that targets IT decision makers.
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:
Some of the more interesting (paraphrased) comments include:
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...
Now, I just know someone is going to come along and burst my bubble by revealing this is a recycled story the editors run every few months, but I was pleasantly surprised to see the world of requirements front and center in a magazine that targets IT decision makers.
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
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
...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.The author of this reader comment does a great job of summarizing a key tenet that we hold true at Seilevel. There is absolutely no one-size-fits-all approach to requirements. Every system and every organization faces unique challenges that require an approach tailored to that precise situation. Not recognizing this issue is one of the key factors that can lead an organization down the path towards requirements disaster.
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...
posted by Anonymous at 11/29/2005 08:56:00 PM
1 Comments:
Jerry,
I enjoyed your comments on the CIO Magazine article and had also marveled at the diverse feedback it had generated.
I was perhaps most interested by the Bank of Montreal Financial Group's approach in that it had singled out the training and experience (or lack of experience) of business analysts as a key area of concern. I'm increasingly of the feeling that the problems experienced with requirements on software projects have as much to do with the skills that the analyst brings to the table as with the methodology utilized. In many organizations, business analysts have grown into the role from technical writing, developer, or non-IT roles and may have not received training or had the opportunity to exercise some of the skills needed for successful requirements elicitation and management.
I agree with you that there is no one-size-fits-all solution that would work effectively on every project within every organization. An experienced and skilled analyst will design a requirements management plan for a project based on the needs and circumstance of the situation, drawing largely on practices they've used successfully on other projects. In helping my company to formally define its requirements management process, I am emphasizing definition of key best practices ("we manage requirements and have a stated plan as to how we do this", "we track progress over time and measure the status of the requirements efforts", etc.) over the establishment of company or department-wide standard methodologies. Again, the focus here will be on the competencies an analyst should strive for as opposed to adherence to a single approach.
Brian
Post a Comment
<< Home