Fixing the Software Requirements Mess

1 2 Page 2
Page 2 of 2

Poking through the rubble, Sherman at first couldn’t understand what had gone wrong. Why had the seemingly ideal specification failed to produce a suitable application? He hired a contractor who spent two months tracing every requirement to every relevant sentence in the specification. P&G found that 30 percent of the deliverables were not adequately addressed. And from what Sherman could tell, the misfires were a result of being too dependent on team members’ recollection of document comparison. The supplier had looked for common patterns that it could duplicate in order to reduce coding complexity. To Sherman and the others reviewing the specification, it looked—on the surface—as if those patterns matched exactly to the requirements. But they hadn’t. The problem, Sherman eventually decided, was that everyone involved had simply run up against the limits of their ability to comprehend extremely complex situations. The management tools they were using were also unable to make proper connections between deliverables and the actual business processes they would support—connections that would have highlighted the subtle distinctions that turned success into failure.

Frustrated with the inability of requirements management software vendors to address the overriding disconnectedness he felt was at the core of many development problems (not just this one), Sherman decided to build a system using his own schema and a collection of tools that now includes Visio and Telelogic’s Doors. The premise, he says, was simple: granular traceability. His vision was to be able to take a piece of code and quickly trace it back through the development process, back to requirements and then—rather than stopping there—map it all the way back to every affected business process to better gauge the application’s impact on the business and to find hidden stakeholders.

Getting to this point has taken five years and has required the IT team to gain an encyclopedic understanding of business processes, but the results have been worthwhile. Using complex pharmaceutical project lifecycle management tools as a benchmark, Sherman says he produced the application at one-quarter the cost and with fewer than 10 percent of the expected defects compared with outside development estimates. Sherman also helped another group in P&G apply the technique to a teetering ERP implementation that seemed destined for failure thanks to a never-ending requirements process. By shifting midstream to the new schema, however, the project got back on track and now looks like it will be a success, he says.

The P&G schema has produced numerous side benefits as well, Sherman adds. For instance, an approach called "initiative scenarios" helps IT teams identify potential enterprise-level stakeholders, with the aim of converting them to sponsors before a project even gets under way. Since every requirement links back to a business process, business-side stakeholders, developers, architects and analysts can trace their way through the organization, identifying groups that feel an impact from the new application, even if they weren’t the actual end users. As an example, Sherman points to an Electronic Lab Notebooking (ELN) application (a digital data collection tool for researchers) that P&G had been having trouble getting rolled out. Previous attempts at justifying and delivering the ELN limited the requirements analysis to the lab bench and the scientist who used the notebook. But Sherman was able to demonstrate a domino effect that showed how notebook data would affect acquisitions, divestitures, patent filing and more. As a result, the IT group was able to seek additional sponsors inside the organization, and the project is heading toward 4,000 users.

"If you’ve done the appropriate joins [to these work processes] and you understand the linkages back to the roles, you can get the clearance ahead of time—or kill the project if you don’t have the buy-in," Sherman says.

The schema also has a dramatic impact on compliance. A too-restrictive view of regulatory issues can cripple projects in the pharmaceutical industry. A too-loose interpretation, meanwhile, could open the company to legal action. But previous requirements methodologies at the company relied more on gut instinct to determine the proper balance. Now, Sherman says, compliance experts can trace their legal requirements all the way from business process to final code to determine if regulations come into play. And the schema’s chartlike format and standardized sentence structure make it possible for just about anyone to trace a path, which helps users and developers prioritize requirements based on which ones will have the greatest impact on a business process.

Even so, Sherman says, successfully using the schema requires a couple of rules. Projects must be broken down into pieces. More complex applications can be built by combining these pieces, but Sherman believes that going beyond a certain level of documentation leads only to more documentation—and greater complexity—instead of execution.

Required Thinking

As these cases show, requirements processes must change, and CIOs need to drive the charge. Fixing your broken process probably won’t be easy or quick, so start now.

"Today, survival depends on game changing—certainly for IT it does," P&G’s Sherman says. To change the development game, "IT is going to have to understand the intersections between requirements and business processes." Failure to achieve that understanding could have dire consequences, he warns.

"If you’re not rewriting the rules of the game," Sherman says, "then you deserve to have your job offshored."

Related:

Copyright © 2005 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Download CIO's Roadmap Report: Data and analytics at scale