Frankly Speaking: Good project management needs requirements management

Computerworld - I called Bruce Barton because I wanted to know something about requirements management. Barton is a systems engineer who has been using requirements management software for years. He says he can't imagine doing development without it. What real difference does it make? I asked. His answer was straightforward: The requirements for a project can start out vague, they can change midstream, and new requirements can show up. If you don't have a good way of managing those requirements, you have to deal with that vagueness and change in the dark.
He didn't add, "... the way most IT shops do it." But he could have.
After all, in most IT shops, "requirements management" consists of a spreadsheet containing all the user requirements that were collected at the beginning of the project. It's pretty useless as anything more than a historical list. Those business requirements aren't linked to technical requirements within the project. And when requirements change, you can't tell exactly what the effect will be on the project.
Compare that with the situation when Barton's company implemented PeopleSoft. If one business requirement for the project translated into 20 specific technical requirements, they were all linked in the requirements management system. If the business side wanted to change that requirement, the implementers could see how the changes cascaded down.
They could see what would happen when a vague requirement was clarified, or new requirements were added, or changes had to be rolled back. Nobody had to guess. They could tell how the changes would affect what had already been done on the project and what the consequences would be for the work still left to do. That gave them much better control over the project's costs and schedule.
It also meant that the implementers could answer business-side users' questions about potential changes -- and could justify budget and schedule shifts with hard facts, not guesses and fuzzy estimates.
That's the difference a requirements management system can make: control and information that translate into transparency, accountability and credibility. And these days, those things matter a lot.
Why? Because those are things being demanded of everyone on the business side. And there's no way IT will be exempt. If the IT shop can't deliver transparency, accountability and credibility, business-siders will ship IT work offshore.
Don't kid yourself -- all those IT projects aren't going overseas just because of the cheap labor. There's also plenty of dissatisfaction on the business side with what it has been getting from IT. There are too many bugs