CIO —
Hugh Cumming had his work cut out for him. The gap between what his not-yet-implemented call center management application at a large European company could do and the requirements list created by 40 eager business-side stakeholders now filled 3,000 pages and threatened to delay an already overdue call center 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 fiascoes. 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.
