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 Inc. 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 and not enough of the right features delivered fast enough. Too many requirements are frozen too soon. There's not enough flexibility when business needs change. There are too many excuses. And not enough responsiveness.
We got away with that routine for a long time. But now business-siders have an alternative, and we've got competition.
So we can no longer afford to pretend that a configuration management system and Gantt charts in Microsoft Project represent the state of the art in project automation. We need to start using new tools and techniques for everything from tracking requirements to generating code to keeping it bug-free.
Yes, that will cost some money, which is hard to come by these days. Even harder will be getting IT project teams to adopt new ways of working. We don't much like having to change. But for once, we've got some real motivation. Bringing our project tools and processes into the 21st century may not be enough to keep that work in-house. But if we don't, we're toast for sure.
Because if we can't start delivering on the promises of transparency, accountability and credibility and show business-siders the advantages of in-house IT, the next requirements we have to manage could involve turning out the lights in the IT shop -- for good.