Good Governance - Effective use of IT

Written evidence submitted by Anonymous (IT 02)

1. Outline of problems

· Lack of IT understanding at Manager level

· Excessive reliance on large external software houses

· Culture of Big Bang instead of Incremental Development

2. I have 40 years experience in IT, including 25 years as a freelance consultant.

I have worked on:

· Development of large Tandem based systems for Banking Systems

· Testing of Health Systems

As much of this work is subject to confidentiality restrictions, names of organisations are not given in this submission, however all examples given are from my own experience. For this reason please do not publish my name in connection with any of the examples listed below.

3. Working on various large IT systems, mainly Tandem Guardian based, I have observed significantly worse performance by both public bodies and large commercial organisations when developing IT systems. My experience is that a distinct pattern is present in failing systems.

4. Management of the Public bodies is at all levels recruited mostly from non-IT backgrounds. Typically the managers possess long experience of the needs of the Organisation, but not of the issues raised by the development of an IT system. This leads them to make errors of judgement on IT policy.

Example: a policy decision was made that users should be given whatever they asked for and implementation and performance issues were to be ignored. The result was serious implementation delays and when the project finally went live, users experienced response times of up to 15 minutes on some online queries.

5. Not having understanding of IT issues, Management tend to look to outside solutions:

· Structured Methodologies

· Software Houses

Both of these have a place, but both require understanding of IT within management. They are worthwhile but they are not the answer to the maiden’s prayer.

6. Structured Methodologies can contribute significantly to the quality and timescale of a project. They are not, however, a replacement for experienced and competent staff, and they do not guarantee a quality product, especially when used without understanding. Used without proper understanding of their purpose they can become a source of unnecessary delays and a barrier to progress.

Example: Issuing a ‘specification’ consisting of an inch thick folder of highly stylised information flow diagrams to a set of busy managers, who had no IT orientation, and asking them for comments within a few days. The specification was signed off by people who did not understand the implications of the system they were agreeing to.

Example: A project to handle new accounts required 6 months to specify and at least another 6 to implement. The delays became serious enough that one weekend a manager wrote his own system on his home computer, which ended up as the interim system. (I examined the program. It had many drawbacks, but two critical advantages, it was available when it was required and it worked.)

7. Software Houses can provide valuable external staff to cover peaks in workload. They can also bring in experience lacking in the internal management. They are however commercial organisations, providing staff at a substantial mark-up and not immune to unethical behaviour.

Example: Selling a system to a client on the basis of the Software House’s experience on similar systems. I was responsible for system design, and I was a newcomer with no experience of their software. The "experienced" programmers who worked the system were new employees who first had to learn the programming language involved. No-one on the project had the experience claimed by the Software House. None of this was revealed to the client.

8. Freelance consultants, such as myself, are less costly, and do not produce the same risk of being tied-in to one supplier. Consultants are not however a substitute for competent internal management. They should rather be viewed as a valuable resource requiring strong and knowledgeable management for effective use. They should never be viewed as taking away the need to build up a strong body of in-house experience. Example: I have known cases of costly external contractors being on the same job, on the same project for years at considerably more cost than an employee.

9. There is an understandable and reasonable desire by the internal management to tie outside suppliers down to a rigid formal specification, so that the product delivered may be assessed for quality. IT projects are however notorious for project creep, sometimes by genuine changes in user requirements, sometimes by technical issues which come to light during development. These contribute to increased costs, and provide an opportunity for the software house to exploit the client, who is now tied into them and has no bargaining power.

10. The above problems are exacerbated by a common belief that a Big Bang is the best way to develop a system. All IT systems, once gone live, are found to require unanticipated changes. The larger any phase of development is, the greater the risk of large and critical changes being required urgently once the system goes live. This produces more project creep, with additional costs and delays. Successful systems are always, in my experience, associated with an incremental approach, whereby each step is small enough that in the worst case it can fail, without causing significant problems, and in the best case a working system forms the basis for the next phase of development.

11. Strict standards are essential for good IT design. However standards must be relevant and fit for purpose. There is a tendency, in response to a genuine concern about slipshod and substandard work, to produce massively detailed standards, which either impede progress, or alternatively become ignored by tacit agreement.

Example: A Quality Protocol for paperwork which resulted in a delay of 5 days in releasing details of a program fix which had frozen payment to several thousands of recipients. The reasons for rejection included the font size of the date in the document footer. (In fact delays were avoided by giving the client the information verbally and off the record.)

January 2011