• White Papers |
• Blogs |
• Video |
• Webcasts |
• Podcasts |
• Events |
• Solution Centers |
• Newsletters |
• RSS Feeds

Negotiating Users' Requirements for Software Development

By Michael Schrage

October 15, 2003 — CIO — As the cynical saying goes, There are lies, damned lies and statistics. Alas, responsible CIOs have to manage an even greater deception than statistics: requirements.

Requirements are the bane of cost-effective software development and deployment. I’ve personally witnessed far more money wasted in the creation of bad requirements than I’ve ever seen thrown away by bad coding or testing. (Gosh, where do we think so much bad coding and testing comes from?) We know companies always complain about the costs and confusion generated by undocumented code. Let’s talk, instead, about the costs and chaos imposed by undocumented requirements. The road to applications development hell is paved with "good" requirements.

The reason is as simple and obvious as it is horrifying: Most clients neither know what they want nor truly understand what they really need. They’re ignorant. They don’t quite "get" IT, and their grasp of their own internal processes is uncertain. If a little knowledge is a dangerous thing, then these clients are lethal. They’ll destroy any chance IT has of bringing a significant software-based initiative in on time, on budget and—please excuse the irony—according to spec.

Of course, any CIO with an ounce of brains and two ounces of experience already knows this. However, because we’re all supposed to hold hands and sing "Kumbaya" and be sensitive to client needs and truly listen to what they’re saying, IT ends up being the unhappy appeaser. Shame on CIOs for permitting this pathology to persist. At one Fortune 250 company, internal clients insisted they needed real-time analytic capability baked into their new CRM system. This marketing group wanted the ability to run sophisticated statistical algorithms to gain immediate insight into the behavior of particular customers.

The problem was that building in that requirement would add at least four months of development time, a month more testing and an additional layer of complexity that would both be both more costly to maintain and risk degrading the overall CRM performance. This was a multimillion-dollar decision. The clients were prepared to pay for both the development and the delay, if IT promised to allocate the resources.

A statistically savvy IT project manager looked at the requirement and found that a three-day programming effort would reformat the CRM data so that analytics could be run in not-quite-real-time on any PC with the right off-the-shelf statistical software package. In other words, the project manager reframed the original requirement in a way that gave the clients more than 95 percent of the desired functionality for less than 1 percent of the original cost.

 

 

 

Email

Print

Comments

Digg This

SlashDot