The road to applications development hell is paved with rigid code requirements.
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 behaviour 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 per cent of the desired functionality for less than 1 per cent 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.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.