Stephen Castell, in his opinion piece (Computer Weekly, 13 September), related an all too familiar chain of events leading to a systems disaster, and eight points at which warnings should be seen. The problem almost certainly started way before his first warning flare, the statement of requirements (SoR).
From the first commercial use of electronic data processing, systems have been sold to boards on the basis of cost savings that rarely appear, at least not to the original extent forecast when the CIO or CFO presented the case.
This contrasts with the early years of electronic data processing, where code breaking demanded solutions yesterday and required innovative custom development - whatever the cost. That level of skill, funding and risk taking is not sustainable in the commercial market, and so we all accepted a heavy compromise.
Early commercial systems were led by hardware design, with software a painful and expensive area of custom development. Packaged software seemed like manna from heaven - known cost, immediate availability and the pain of prototyping suffered by someone else.
Software took over as the development leader and prices continued to fall dramatically. In the process we came to accept regular failures as a normal part of computing. CIOs continued to preserve the 'mysteries' of information technology, with other senior managers taking perverse delight in maintaining their level of technical illiteracy.
That situation, together with a general lack of real strategic planning, has made it very difficult to start towards the SoR from a sound and reliable base point. As a result, there may have been significant losses and embedded problems in the process leading to the issue of the SoR.
As every enterprise has unique attributes, the best solution, potentially, is custom-engineered, but that means much higher costs and implementation delays.
The "easy" solution has always been to compromise in line with the culture of the enterprise. Senior managers often convince themselves the low-budget, off-the-shelf package they decided to pay for is really the high-quality custom system that they needed.
Disappointment is built in from the start and lurks in the SoR. In an increasingly litigious world far too many enterprises wait until everything goes seriously wrong, and then hope the lawyers will make it better. The reality is that another area of cost has been introduced which will not provide an operational solution either.
Specs need to be jargon-free
Before embarking on procurement, the management board needs a functional specification that is devoid of technology and jargon. To be effective and reliable, the specification must relate to the enterprise policy and the risk policy, providing a method of achieving operational objectives at an acceptable risk.
Logically, the SoR will then be built through discussion between the project sponsors and the potential suppliers. This needs to be adequately documented and will include a record of each decision and the reasons behind it.
As the process unfolds through to implementation and operation, the project can be managed and it will be possible to see each milestone. Also visible will be any warning signs, sighted before the deficiencies become a disaster when everyone involved reaches for their lawyers.
For many enterprises, the board may produce many excuses for not planning anything strategically. For the buccaneers, that approach works as they keep just ahead of the consequences of multiple disasters. For the conservatives, anything that departs from the way that it has been done for years is a painful voyage of discovery.
Between the two extremes, the majority of enterprises continue to compromise and attempt to deal with an increasingly complex world, where the promises of the market can be all too seductive. In most cases, rigorous testing uncovers problems that could have been avoided at any of the stages up to the drafting of the SoR, and at any of the eight warning points from issue of SoR.
Ian Johnstone-Bryden is a consultant with the Firetrench Consortium, an international co-operative of specialists working on aerospace and defence projects, and is the author of a number of books on risk management.
This was first published in October 2005