The requirements process - literally, deciding what should be included in software - is destroying projects in ways that aren't evident until it's too late. Some CIOs are stepping in to rewrite the rules.

READER ROI

• How a broken requirements process can sabotage software projects
• Ways to rewrite the process for success
• Software that can help monitor requirements for problems

Hugh Cumming had his work cut out for him. The gap between what his not-yet-implemented call centre management application at a large European company could do and the requirements list created by 40 eager business-side stakeholders now filled 3000 pages and threatened to delay an already overdue call centre consolidation effort another four to five years. "My first instinct was that the project had absolutely no chance of success," says Cumming, currently CIO for ADP Employer Services Canada.

Requirements, as every CIO knows, are a problem, but CIOs may not be aware of just how catastrophic the problem has become. Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure - bigger than bad technology, missed deadlines or change management fiascos. Though CIOs are rarely directly responsible for requirements management, they are accountable for poor outcomes, which, when requirements go bad, can include: project delays, software that doesn't do what it's supposed to and, worst of all, software that may not work correctly when rolled out, putting the business - and the CIO's job - at risk.

Mishandled requirements can torpedo a project at any time, from inception to delivery. Start down the wrong road and you arrive at the wrong destination. And even if you're heading in the right direction, making fumbling changes midstream can be almost as deadly. Not integrating requirements with your test process can have you racing back late in the game to correct problems that might have been solved early on (and more cheaply).

It's up to the CIO to establish an overall requirements process that works and to support it with the political skills necessary to get buy-in from both the business and development sides. The CIO must also have the organizational backbone necessary to shove wayward requirements processes back into line. None of this is easy. Business users often don't know exactly what they want, can't prioritize what they do want, request things IT simply can't deliver (because of complexity or cost), or can't describe their desires in terms that translate accurately into code. On the IT side, analysts, architects and coders regularly try too hard to please and don't set realistic expectations for projects; they don't use every means possible to guarantee that what they're building is what the user really needs, and sometimes they even fail to make sure that they're talking to all the right stakeholders.

In short, the traditional practice of requirements is broken. But some IT folks are doing everything they can to fix the situation. To a man, they say process is key. Exactly what process? They all have their own ideas. One executive decided to simply enforce rules that should have been enforced all along. Another rewrote the rules from the ground up. And a pair threw out the old rule books completely, one taking a business-process-focused approach and the other choosing to build applications with quick iterations rather than long requirements documents. But they all agree that you should choose a formal requirements-gathering process and stick to it.

Writing requirements is hard. It will always be hard. But with a handful of smart decisions you can create a requirements process that will produce positive results - and maybe keep your next project from becoming another statistic.

Forty's a Crowd

Cumming's solution to his requirements nightmare was radical surgery. First - with backing from ADP's chief executive - he stripped down the scope of the consolidation project, lopping off existing processes that worked as-is and didn't need to be rolled into the new application. He also pared the group of 40 stakeholders to five active participants. He allowed the others to stay involved, but only in the more passive role of reviewing the implementation plan and feature specifications, without actually adding feature requests of their own. He then repeatedly went back to the remaining five stakeholders and asked them if specific requirements were really must-haves or simply nice-to-haves. After less than two months of pressing the issue, his new requirements list was less than 10 percent of the original. And after the project went into production, it needed to accommodate only one major change before being rolled out to 12 global locations.

Cumming says the problem in this case - and in many cases - is that IT often does not take a leadership position in the requirements process, instead taking the attitude that "the business is requesting it, so it must be the best thing to do". But that kind of thinking can lead to requirements lists that are unmanageable and unforgiving. Instead, he says, IT people need to develop a valuable skill: saying no with a smile. "Really what you're saying is: 'Not yet'," Cumming says.

To paraphrase Daniele Vare, managing requirements - like diplomacy - is the art of letting everybody have your way.

When Cumming reduced his army of 40 stakeholders to five, he admits that there were some "interesting conversations" about who would stay in primary roles, noting that people were worried they were going to lose features they felt were important to their business units. To ease their fears, Cumming and the core stakeholders created a "high-level vision" (a summary of the most important functions) for the project and spent time demonstrating how the final project lined up with that vision. He also showed all the stakeholders how they would get at least some value from the project - even if they weren't going to get every single detail they wanted.