As the cynical 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.
The clients looked at the revised requirement numbers and effectively said, “Even though we’ve never done real-time CRM analytics, that’s what we’ve declared our requirement to be. Our management signed off on it; you signed off on it. So do it. We promise we’ll pay you more if you don’t show this alternate spec to the general manager.” Shamefully, IT went along.
This story does not have a happy ending.
What makes such tales particularly atrocious is that so many clients live with the pathetically self-serving delusion that they actually do understand what they want and that IT was put on God’s Green Earth to give it to them right now! Consequently, their well-documented requirements read either like a wish list or–worse yet–a rigidly defined spec sheet that ultimately contains more internal contradictions and paradoxes than a high tea chat with Lewis Carroll’s Mad Hatter. Increasing conflict, confusion and cost become inevitable.
The obvious thing to do is to roll one’s eyes, grit one’s teeth and try not to be too condescending to clients who want the world for $1.50 a function point. After all, they know not what they do. How can they? Even we can’t be sure what a purportedly innovative app will really run like before it’s implemented–so how could they know? We’re not good at predicting the future. No one is. So shall we hazard a guess as to how much IT executive time and ingenuity is spent on correcting mismanaged expectations?
Indeed, IT conversations would be profoundly different if we banished the word requirements from our software vocabularies and substituted expectations in its place. Instead of “requirements analysis,” we’d be doing “expectations analysis”; instead of “prioritizing requirements,” we’d be “prioritizing expectations.”
This more honest IT approach would recognize that clients are, in fact, acting rationally when they game requirements: They are responding all-too-logically to the peculiar and perverse economics of requirements-driven software development. Requirements inherently create a world where clients have unambiguous incentives to avoid rigorous thinking, shun risk management and kick difficult design trade-offs to IT. This defines dysfunction.
Think about it: How much does it really cost a client to come up with yet another “good” requirement? The answer is, almost nothing. So why should anyone be surprised by the surfeit of requirements, enhancements and improvements that inevitably materialize as development proceeds?
I’m not embarrassed to say that I’ve made a better than comfortable living advising software development groups to stop gathering requirements after the first 20 to 25 and then do a quick and dirty prototype to lure the client into codevelopment. Why? For two excellent market-tested reasons: You tend to get better quality requirements when they’re generated by ongoing client interaction with a constantly improving prototype. Prototype-driven requirements ultimately lead to better apps than spec-driven prototypes.
The second excellent reason relies on Psychology 101: Clients are happy to cavalierly reject your work. They tend to think twice, however, before throwing out their own work. In other words, when clients are vested in software development with more than just money, you get both a better development process and a better software product. The economics of software prototype-driven requirements are inherently less dysfunctional than the economics of requirements-driven software development.
To be sure, CIOs and the IT organizations do occasionally get to work with savvy clients who know what they want, know what they need and know how to define requirements in a way that makes both economic and technical sense. However, they’re not the problem. To the contrary, they’re the people who make being a CIO both fun and important.
Unfortunately, most CIOs today also confront clients and colleagues who have allowed the perverse economics of requirements to create unrealistic expectations and dysfunctional business behaviors. Requirements should be a means to an end, not the end itself. Responsible CIOs had better start requiring their client-IT teams to spend more time creatively designing the right software requirements than rigidly requiring the right software designs.
