THE INCEPTION AND DESIGN OF IT PROJECTS

Departments should ensure that they analyse and understand fully the implications of the introduction of new IT systems for their businesses and customers

19. Major IT systems cannot be introduced in isolation from wider changes to the business, and so it is essential that the implications of implementing a new IT system are analysed thoroughly. Failure to manage change is likely to lead to IT systems that do not meet business requirements, to delays in the implementation of key operations, or will mean that business users are unable or unwilling to obtain the most from the system.

Key lessons

20. Departments should ensure that they analyse and understand fully the implications of the introduction of new IT systems for their business and customers. In particular, it is important that:

• the introduction of new systems is seen to be based on a clear business need;

• departments have considered fully the implications of any other changes that may coincide with the introduction of a new IT system; and

• departments should base their project plans on ensuring that the identified business benefits are delivered by a high quality team with clearly defined roles and responsibilities.

National Insurance Recording System (Annex A No 2a and 2b) In our first report on the replacement National Insurance Recording System, we emphasised that departments should ensure that they understand fully the potential impact of delays on their business and customers. In our second report we commented that fifteen months after we first took evidence from the Contributions Agency the situation was much worse. The system was not fully operational, there were large backlogs of items waiting to be input to the system, and thousands of short term and long term benefits are being paid on an interim or emergency basis, and payments to personal pension holders continued to be delayed. The 1992 and 1998 Information Management and Technology Strategies of the NHS Executive (Annex A No 5) The Comptroller and Auditor General reported that the NHS Executive's 1992 and 1998 strategies did not have overall business cases. HM Treasury guidance did not require the NHS Executive to prepare an overall business case for the 1992 Strategy. But the Comptroller and Auditor General considered that such a business case would have been useful in demonstrating the value to NHS bodies of participating in all the projects and would have complied more closely with Treasury good practice. The 1998 Strategy also has no full business case. The Treasury, therefore, insisted on three steps: first, that there should be external expert review of the Strategy; second, that the Executive should prepare individual project business cases on the components of the strategy, and third, that the Executive recognises and manages the links between individual elements by developing a project management framework. The Comptroller and Auditor General considered that this approach suffered from the weakness of not demonstrating the interdependencies of the Strategy's individual elements.

Departments must consider carefully the scale and complexity of projects to assess whether they are achievable

21. The scale and complexity of projects is a major influence on success or failure. Departments should consider carefully whether projects are too ambitious to undertake in one go. This is particularly important if a project is to have an impact on the business operations of other parties, or where there is reliance placed on the parallel development of related IT undertaken by other parties. The number of project failures could be dramatically reduced by making use of a 'step by step' progression of relatively small projects (perhaps taking six months or less), with each successive one being considered in the light of the outcome of the earlier ones. The advantage of such a structured approach is that it helps to reduce the complexity of planning, monitoring and control.

Key lessons

22. Departments must consider carefully the scale and complexity of projects to assess whether they are achievable. In particular, departments should consider whether:

• the proposed timetable for a project is realistic;

• IT initiatives should be broken down into manageable projects, with each successive one being considered in the light of the outcome of the earlier ones;

• an incremental, as opposed to "big bang", approach to IT projects should be adopted, with regular milestones, each delivering an auditable business benefit. If there is no feasible alternative to the "big bang" approach, then they should ensure that the timetable for implementation is realistic;

• their overriding priority is to deliver the project to time, to cost, or to a particular quality specification;

• enough high level review points have been built in to the project to ensure that it is not allowed to continue if changing circumstances mean that the business benefit is no longer going to be achieved cost effectively; and

• senior management are sufficiently aware of the importance of halting a project that has been overtaken by events, rather than continuing to spend money.

Hospital Information Support Systems Initiative (Annex A No 15) Our predecessors noted that the NHS Executive had selected the three pilot projects under this Initiative within the very short period of two months. Subsequently, each of the projects suffered problems and delays. Our predecessors considered these delays may have stemmed, at least in part, from the Executive's failure to prepare the hospitals to run their projects, and they might have obtained better value for money had they taken more time to ensure hospitals were fully prepared. National Insurance Recording System (Annex A No 2a) In our first report on the National Insurance Recording System computer system in 1998, we expressed surprise at the delay in the Agency deciding that the replacement of NIRS1 would be carried out using a PFI approach. This delay meant that the timescale allowed for the PFI completion was very short. It also meant that the winning bidder had only twenty two months to deliver this large and complex system on which important new pensions arrangements depended. This proved to be inadequate. In addition, the Agency signed a contract with Andersen Consulting to develop the system in one stage. By January 1996, it became clear that Andersen Consulting had realised the system size and scope were bigger and more complex than originally thought and had therefore concluded that delivery of NIRS2 in accordance with the contract timetable was not the best approach. The company believed a phased approach would bring less development risk to themselves and less business risk to the Agency. The original contract was amended to provide for the replacement system to be phased in between February 1997 and April 1998. Ministry of Defence Trawlerman project (Annex A No 4) In our report on the Ministry of Defence Trawlerman project in 1999, we noted that it is essential when computer systems are introduced that the complexity of the requirement is properly recognised at the outset. We concluded that the Department failed to do this in the case of Trawlerman and that this was a key factor in the eventual decision to abandon the project and write off some £40 million. In our view the project had been over-ambitious and the Department relied too much on what the industry had told them it could deliver.

Delays in implementing projects place them at risk of being overtaken by technological change

23. In a number of cases technological developments have rendered projects obsolete even before they are in place. This has resulted in public funds being wasted on systems that cannot be used, and has led to delays in obtaining the benefits of computerised administration. The pace of change in recent years and the likelihood that this will continue, means that this is a significant risk. Falling behind limits the ability of government to respond appropriately to the expectations of customers, and may have an impact on the delivery of policy commitments.

Key lessons

24. Delays in implementing projects place them at risk of being overtaken by technological change. In particular:

• it is vital that project plans are sufficiently flexible to allow for the insertion of technological advances where relevant; and

• there are considerable benefits in introducing systems in phases.

The Crown Prosecution Service case tracking system (Annex A No 14) In 1998 we reported that the Crown Prosecution Service's new case tracking computer system had been implemented in only just over half of its branches by September 1997. Delays were experienced in implementation as a result of legislative and organisational changes, and technological advances. The system was modified to address weaknesses and make it more user—friendly. However, in 1997 the Service decided not to roll the system out any further as it did not have the capability or flexibility to meet its future needs. We reported that a new system is to be procured through a Private Finance Initiative project. Ministry of Defence: Project Trawlerman (Annex A No 4) In 1999 we reported that site acceptance testing of the Trawlerman system was finally completed in November 1993, more than two years later than originally planned. By May 1995 the system was ready to be used operationally, but general developments in IT, as well as health and safety legislation meant that the system could not meet the developing needs of the Defence Intelligence Staff. The original specification had not required that the system be capable of being linked to other systems, but by 1995 this requirement was viewed as essential. The Benefit Payment Card (Annex A No 11) The project to develop a Benefit Payment Card suffered considerable delays and setbacks, and a major review was commissioned to decide the best route forward. In May 1999 the Department of Trade and Industry announced a revised agreement with the suppliers to remove the magnetic strip payment card from the project. Given the delays experienced, it was now an outdated concept, with clearing banks already moving away from the magnetic strip in favour of smart cards.

The project specification must take into account the business needs of the organisation and the requirements of users

25. Projects are conceived and grow from identified business needs. However, what seems to be a clear objective at the beginning can easily become blurred and confused as events progress. In the end the product which is delivered might not be what was expected and this may result in significant wasted investment. The end users must be identified before the project commences so that their needs are taken fully into account during design. A system may deliver broadly what was desired, but not in a user-friendly way. Frustration at slow response times, for example, can result in staff not using the system as planned or even maintaining parallel clerical systems.

Key lessons

26. The project specification must take into account the business needs of the organisation and the requirements of users. In particular:

• business cases must be based on an analysis of requirements and priorities that have taken account of the reasonable needs and preferences of system users;

• desirable, but not essential, features should be kept out of the specifications, which must be focussed on delivering the core business benefits; and

• the benefits of using the new system must be sold to staff.

Northern Ireland Vehicle System Replacement Project (Annex A No 16) In 1997 the Comptroller and Auditor General reported that only a high level user requirement was requested as the replacement system was intended to convert the existing system, along with fixes of known faults and enhancements to meet changing needs. Over time, amendments to the user requirement were needed to correct misunderstandings, and these changes were cited as part of the reason for increasing cost estimates. A CCTA review recommended the preparation of a consolidated user specification covering the various change requests made during the lifetime of the project. This was designed to eliminate the confusion that had beset the project from the outset because of the approach of not carrying out a redesign based on users' business needs. The project board was advised in 1995 that additional work to complete the project would delay it further and increase the costs. Eventually the project was abandoned in 1996 and £3.7 million written off. Ministry of Defence: Disposal by sale of defence surplus equipment and stores (Annex A No 20) Our predecessors reported that the Department had installed a new computer system in April 1991 to aid the efficiency of the Directorate, but the costs of the system rose substantially and nearly three years later it was not functioning properly. One problem with installation of the computer system had been a lack of appreciation of the Directorate's requirements. There had been an internal 'disconnect' between the Directorate and the Department's computer organisation, and as a result, what was implemented had been inadequate. Hospital Information Support Systems Initiative (Annex A No 15) In our predecessors' report in 1996 on this Initiative, they noted that the project at Greenwich Health Authority had been successful. The NHS Executive told the Committee that a key factor had been the involvement of a senior clinician as project director. Our predecessors emphasised their belief that the commitment of clinicians is crucial to the success of such projects, and agreed with the NHS Executive's view that all users need to be involved in development of these systems.