Requirements management software will not solve our requirements problems.
Jerry Aubin of Seilevel made this great point in his presentation this evening at the IEEE Computer Society, Austin / A-SPIN event. This was a great event, focusing on how to take requirements management “to the next level” – not just being good at it, but being great at it. Seilevel’s speakers (Jerry and Joe Shideler) demonstrated that they have great insights into the art and science of requirements management – and presented some cutting edge ideas that extend the “known good ideas” in some interesting directions. Definitely a company to keep our eyes on and learn from. Their blog, requirements defined, is linked in our blog roll – check it out.
The Norm Abram analogy
Jerry used what he coins as the “Norm Abram analogy”. Norm Abram is a great carpenter, and he does a weekly television show here in the US. He has an amazing workshop, with every tool imaginable for cutting, shaping, sanding or finishing wood. And Norm uses those tools to create beautiful products.
If you had those tools, Jerry asked us, would you be able to suddenly create products as beautiful as Norm does?
No.
Norm became a great carpenter and he became proficient with tools that help him do his work faster. The tools didn’t make him better, they just make it easier for him to do the work.
Would having typewriters make us write better, or just faster?
Applied to requirements management
The same holds true about requirements management software. Having access to software won’t make us better at managing requirements. The software will help someone who already knows how to manage requirements be more efficient.
The folks at Seilevel have seen the introduction of RM software (requirements management software) actually be counter-productive for teams who are new to managing requirements. We agree – we think it’s like getting an expensive car so that we can teach someone how to drive. The learning process has to come first.
Jerry showed statistics from the Standish Group’s 2004 CHAOS report. We’ve talked about that report earlier. That report shows that 71% of software projects fail. The issue isn’t the speed or cost of writing requirements, the issue is writing bad requirements.
For those 71% – the problem isn’t the tool, it’s the training. For the other 29%, there are absolutely solutions to help us do our jobs faster.
What should we do?
There are two ways to get better requirements. Buying RM software is neither one of those.
- Get help with your requirements. Companies like Seilevel and Tyner Blain have already invested in learning how to do requirements right. Let them or someone else help you manage requirements, or let them do it for you.
- Learn how to manage your requirements. Get training, read, study, practice, fail, improve, and succeed. As individuals, find mentors. As companies – get outside experts to come in and audit your projects.
When should we buy RM software?
When we’re already good at writing and managing requirements, and we’re looking for a cost reduction. Introducing a tool of this complexity to a team that isn’t accustomed to the process will actually hinder the process.
Requirements management is an interesting case, in that it *is* possible (barely) to do decet requirements management without tools. It requires lots of manual work, is very error prone, and in general leaves a lot to be desired as far as productivity goes. Just as one example, if you don’t have a central repository for your requirements, then the “gold copy” of the requirements has to travel around the organization (often as many copies, each of which has one set of updates that eventually have to be combined), and it’s never clear who has the last word.
On the other hand, there *are* product management activities that are so difficult to do in practice that not having a tool to support the activities means they don’t get done.
For example, consider modeling the effectiveness of different sets of requirements (i.e., release scenarios) against different market segments to see which delivers the best return on investment. In practice, even with Excel, you might be able to do this analysis once or twice for a release for two scenarios. But it’s just not feasible to do the analysis against five or ten scenarios, or five different strategies, or to do it every week as your set of unfinished requirements and available resources start to converge.
It’s like saying that everything you do with Excel you can do on paper – definitely true, but Excel enabled normal people to do whole new types of analysis that they would never have been able to have done before.
Hey Nils, thanks for reading and commenting!
You make some great points that many things would be cost-prohibitive without technology.
I’ve only had one experience with requirements management where a company knew the importance of doing something, knew that a solution existed to make it viable (cost/time), and could/would not invest in the software.
I’ve seen more examples of companies that didn’t appreciate the benefits of the activities (like explicitly associating tests with requirements). And a couple companies with capability in-house that was not being used effectively (test automation, requirements repository).
To be great, requirements management tools are essential, but insufficient. Enterprise packages can be better than excel, but following an 80/20 rule, a company with no tools can get pretty far pretty fast “on the cheap.” Either way, it’s the knowledge of how and why to use the tools that makes the real difference.
Scott – excellent points. Getting back to the original analogy, most everything Norm does was done by craftspeople before powertools. But not before steel forging — so there is some requirement for technology even in the Norm domain. And, these old guys often had to create their own tools (e.g., a dovetail jig or a panel plane) to be able to create their masterpieces. This is something PMs often do, of course.
The two points have a pendulum effect — there are things you really can’t do, realistically, unless there’s tool support. But then you still need certain skills and techniques (and even talents) in the domain before you can do a good job, no matter what tools you have available. And then if you have those skills, better tools can enable you to do a better job, or get it done faster, or whatever.
Couldn’t agree more! Sincerely, thanks for contributing to the discussion and community here – it really does make it a better place.
My wife is helping a friend with kitchen cabinets this week – they made a jig out of cardboard as a drill guide for placing the knob holes. Funny how it all comes back around.