Why Do We Continue to Fail at Requirements Management?
I find it strange to be having a conversation about why software professionals continue to fail at requirements management (RM). If you ask any developer, business analyst, project manager, CIO, or anyone involved with application creation, I guarantee that the majority will say they are failing because of bad or incomplete requirements. An interview and a survey I found by ESI International nicely sum up these issues with requirements and the lack of requirements management.
So what is requirements management? For the answer I go to Villanova University’s website. The authors give us five stages of RM—investigation, feasibility, design, construction and testing, and release. The only change to the list that I feel is warranted would be adding control to the release stage. Now that we have the definition of RM, how can we do a better job at it? It’s one thing to say requirements management is not our strong suit, but we have to offer more than stale words and tactics.
One of the ways we can fix RM issues might be related to using the right RM tools. Seilevel’s blog gives us six reasons why business analysts need a good RM tool. Enfocus Solutions has a presentation on slideshare.net arguing that Microsoft Word, Excel, and SharePoint are not the right tools for RM; even though they go on to recommend their product, their points about Word, Excel, and SharePoint are spot on. I am not satisfied that a RM tool will solve all of the problems, however. We still have the “garbage-in-garbage-out” issue to contend with.
On the Project Management Institute’s website I found an interesting article about good RM in which the authors recommend five steps to master requirements prioritization. I agree with the premise, but I don’t know if this is enough to fix the underlying issue.
Computer Weekly asked Kevin Parker of Serena what we can do to fix RM. He mentions that we need requirements churn, the ability to see what changes truly cost, and good communication surrounding the delays caused by changes as well as the business-side taking ownership of the requirements. To paraphrase his remarks, he says that all of those things need to be in a tool that allows the business to make the changes and then relay those changes to IT.
For a solution to the tools argument, I turn to Richard Denney's StickyMinds article, which describes how you need to get a high return on investment on your RM tool. This exhaustive look at the numbers can help you justify the purchase of a good RM tool. This article should be printed and handed to your powers that be so they can make a sound decision based on it.
How do you feel about RM? Am I off base? Can a good tool give you the ROI you need to finally make the plunge?
