The Impact of Technology Insertion on Organisations

More documents

Recommendations

Info

HFIDTC/2/12.2.1/1 Version 3 / 21 November 2007 • <strong>The</strong> role <strong>of</strong> the DoH was to develop and advise on strategic and policy issues and the performance <strong>of</strong> major tasks. <strong>The</strong>refore RISP should have been recognised as a high- risk project. It was left to a health authority with no previous experience <strong>of</strong> such projects. Most <strong>of</strong> the responsibility for technology procurement, project management and budgeting was left firmly on the WRHA’s shoulders; • Risk was further exacerbated by the WRHA’s lack <strong>of</strong> consideration <strong>of</strong> qualitative measures such as experience, past performance and reputation, when awarding their contracts; • <strong>The</strong>re were serious conflicts <strong>of</strong> interest at a senior level within the authority and it was not clear whether those suppliers recruited for the RISP project were the best available: ‘A Member <strong>of</strong> WRHA who was also a Director <strong>of</strong> IBM, promoted the Andersen Consulting bid.’ This was because the Andersen Consulting bid involved the procurement <strong>of</strong> IBM s<strong>of</strong>tware and terminals. <strong>The</strong> appointed auditor for RISP found no evidence that the region had undertaken a full evaluation <strong>of</strong> the alternative suppliers. 9.2.2 London Ambulance Service Computer Aided Despatch <strong>The</strong> main objective <strong>of</strong> the London Ambulance Service Computer Aided Despatch (LASCAD) project was to automate many <strong>of</strong> the human-intensive processes <strong>of</strong> manual despatch systems associated with ambulance services in the UK. In the 1990’s the London Ambulance Service (LAS) invested considerable money in order to implement an effective Computer Aided Despatch (CAD) project. LAS scrapped a development by IAL (BT subsidiary) at a cost <strong>of</strong> £7.5 million in October 1990. In June 1991, they signed a £1.1 million contract with Systems Options to provide a CAD system. This attempt failed in 1992. <strong>The</strong> system replaced a manual system for taking emergency calls and allocating resources to incidents. It relied on automatic vehicle tracking and ambulance crews reporting the status <strong>of</strong> the call using Mobile Data Terminals (MDTs) to allocate resources to incidents. On the night <strong>of</strong> Monday 26th October to the morning <strong>of</strong> Tuesday 27th October 1992 things started to go wrong at the HQ <strong>of</strong> LAS. It was reported that a flood <strong>of</strong> 999 calls (some 2900 instead <strong>of</strong> the usual 2300) apparently swamped operators’ screens. Many recorded calls were being wiped <strong>of</strong>f screens. This, in turn, caused a mass <strong>of</strong> automatic alerts to be generated indicating that calls to ambulances had not been acknowledged. <strong>The</strong> report <strong>of</strong> the public inquiry portrays a more complex picture <strong>of</strong> the so-called technical problems experienced by the LASCAD system than that reported either in the computing or general press. It is interesting that they conclude: ‘On 26th and 27th October the computer system did not fail in a technical sense. Response times did on occasions become unacceptable, but overall the system did what it had been designed to do. However, much <strong>of</strong> the design had fatal flaws that would, and did, cumulatively lead to all <strong>of</strong> the symptoms <strong>of</strong> systems failure.’ Various technical and HF issues resulted in communication difficulties that meant the system was <strong>of</strong>ten unaware <strong>of</strong> the location and status <strong>of</strong> resources. <strong>The</strong> result <strong>of</strong> this was that the system sometimes made incorrect allocations by: 51
HFIDTC/2/12.2.1/1 Version 3 / 21 November 2007 • sending multiple ambulances to the same incident; • sending ambulances that were not the closest ones to the incident; • not sending an ambulance, which was in fact available to be sent. This caused frustration to members <strong>of</strong> the public and ambulance crews who telephoned or radioed the control centre. Slow s<strong>of</strong>tware, user interface problems and understaffing in the control centre combined to increase telephone and radio traffic and resulted in the system slowing to unacceptable levels. On 4 November 1992 the system failed completely due to a programming error and the back up system, which had not been adequately tested, did not work. Claims were later made in the press that up to 20–30 people may have died as a result <strong>of</strong> ambulances arriving too late on the scene. Some ambulances were taking over three hours to answer a call, whilst the government’s recommended maximum is 17 minutes for inner-city areas. Arguably the LASCAD project was the most visible UK information systems failure in recent years. 9.2.2.1 Findings • <strong>The</strong> LASCAD report [209] states that ‘the size <strong>of</strong> the programme and the speed and depth <strong>of</strong> change were simply too aggressive for the circumstances.’ <strong>The</strong> Inquiry Team found that neither the CAD system itself, nor its users, were ready for full implementation on 26 October 1992. • <strong>The</strong> CAD s<strong>of</strong>tware was not complete, not properly tuned, and not fully tested. <strong>The</strong> resilience <strong>of</strong> the hardware under a full load had not been tested. <strong>The</strong> fall back option to the second file server had not been tested. • Staff both within Central Ambulance Control (CAC) and ambulance crews had ‘no confidence in the system and had not been fully trained’. <strong>The</strong> physical changes to the layout <strong>of</strong> the control room on 26 October 1992 meant that CAC staff were working in unfamiliar positions, without paper backup, and were less able to work with colleagues with whom they had jointly solved problems before. Control room staff had little previous experience <strong>of</strong> using computers; • Satisfactory implementation <strong>of</strong> the system required changes to a number <strong>of</strong> existing working practices. Senior Management believed that implementation <strong>of</strong> the system would, in itself, bring about these changes. In fact many staff found it to be an operational ‘strait jacket’; • <strong>The</strong>re were a number <strong>of</strong> basic flaws in the CAD system and its supporting infrastructure. In summary the system and its concept had several major problems: • it required near perfect input information from users • poor interface between crews and the system • slow response times for certain screen-based activities • lack <strong>of</strong> robustness <strong>of</strong> the system (including unreliability and system ‘lockups’). 52
Page 1 and 2:
The Impact
Page 3 and 4:
HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 5 and 6: HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 55: HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 87: HFIDTC/2/12.2.1/1 Version 3 / 21 No
show all

The Impact of Technology Insertion on Organisations

Create successful ePaper yourself

Delete template?

Save as template?