This blog has been on my mind for awhile. I’m particularly passionate about requirements management and its importance for business analysts. See, I’m a big believer that business analysis is most successful when it has a purpose and leadership behind it. Too often I see projects that need requirements and business analysts are deployed to “gather requirements.” There are no systems or standards in place. Project leaders believe that somehow the act of putting business analysts on a project – without their own processes or practices – will simply make a project successful. What results is a haze of unrelated Word and Excel files stored usually on a shared drive or directly in the work management tool. They’re hard to find and even harder to source control so practices of requirements re-use or versioning are not used (just a new document each time). Moreover, BA work and processes are ad hoc and inconsistent leading to uneven work products. When the project is completed, a lot of money has been spent to create requirement assets that will be thrown on the trash heap because they are almost immediately out-of-date by the time the product rolls into production.
You know what I’m talking about. You’ve been on that project. More than once, I bet.
So this blog is dedicated to requirements management techniques and leadership. I’ll give you a little strategy but we’re going to get right to the tactical bits so even if you don’t have a formal requirements management practice at your shop, you’ve got some tips and tricks you can immediately put to use.
What requirements management practices are problems at your shop? I’d love to hear your thoughts so we can make this blog what you need it to be.