Pergamon

International Journal of Project Management Vol. 14, No. 2, pp. 103-110, 1996 Copyright 1996 Elsevier Science Ltd and IPMA Printed in Great Britain. All rights reserved 0263-7863/96 $15.00 + 0.00

0263-7863(95)00067-4

London Ambulance Service computer-aided despatch system*

Michael Hougham
Greenlands Management and Engineering Consultants, Great Missenden, HP16 OJT, UK

This paper illustrates the dangers of trying to implement high technology projects, without sufficient technical research and development, adequate management organisation and due regard to social factors. The London Ambulance Service is the largest in the world. During the early 1990s, it attempted to introduce a computer-aided despatch system. This system was finally commissioned in October 1992, about 9 months late and failed within 2 weeks. This case study traces the history of the project and identifies the flaws that led to its failure. Copyright Elsevier Science Ltd and IPMA
Keywords:hightechnologyprojects, LondonAmbulanceService, computer-aideddespatch, cultural change, business process re-engineering, information technology

The London Ambulance Project arose from a need to increase performance and reliability of a service which had an extremely large, complex task to execute. The organisation of the service had remained largely stagnant for 10 years and had been demoralised by a debilitating industrial relations dispute. The project attempted to introduce a computerised system to receive emergency calls and send ambulance crews to required destinations. At the same time, new techniques were introduced to monitor the location and availability of the emergency services. A 'big-bang' approach was adopted with all systems intended to go live on 8 January 1992. This was attempted, despite the known existence of major flaws in the system and the lack of trials that could have demonstrated other serious inherent problems. The implementation on day 1 was not successful and a phased introduction was adopted. Some actions taken to retrieve the situation made problems worse. The project passed the point of no return and for various reasons the situation could not be recovered. The contingency action taken in the early part of 1992 could not compensate for the fundamental shortcomings of the technical solution, together with inadequacy of the management organisation. A major crisis point was reached in October of that year. There were a large number of reasons why the system failed, many of which would not have been serious on their own. Taken collectively they proved to be catastrophic. The main reasons were: The management did not appreciate that this was a

business re-engineering project and tried to run it as a project for the purchase and installation of information technology. Due to external pressure to achieve results, insufficient time was allowed for development and proving of the extremely complex technical solution. There was a lack of disciplined technical approach. There was little attempt to manage the changes in the organisation's culture as part of the project. These all contributed to the problem but perhaps the single most important factor was the inadequacy of the organisation to control such a large and technically complex operation.

Background to the project

The London Ambulance Service is the largest in the world but could not meet its performance requirements. A computerised despatch system was seen as a solution, but was that all?
The London Ambulance Service

*Entrant for the Sir Monty Finniston Award 1995 sponsored by IBM

The London Ambulance Service (LAS) was founded in 1930, and was expanded to take in all or part of eight other services in 1965 when the Greater London Council was also established. From 1974-1990, (when the project began), LAS had been managed by the South Thames Regional Health Authority (STRHA) on behalf of the National Health Service. It was a quasi-independent body with its own board, managed only at arm's length by the RHA. Little change had been made to their way of operating during the 10 years preceding 1990. 103

London Ambulance Service computer-aided despatch system: M Hougham

LAS covers an area of just over 600 sq miles (bounded by the M25 motorway) and serves a resident population of 6.8 m people, increasing considerably during the working day, particularly in Central London. It receives 2 0 0 0 - 2 5 0 0 telephone calls per day, o f which between 1300 and 1600 are emergency '999' calls. It provides a patient transport service for 80 hospitals and community units within London. During the course of a year, LAS makes 0.5 m accident and emergency and 1.3 m patient transport service journeys. The Service has 2700 staff and over 750 ambulances (Tables 1 and 2). Its budget in 1992/3 was 69.7 m (the largest ambulance service in the world). emergency services. The situation was also complicated by a lack of information concerning the location and status o f each ambulance and the poor quality of communication with the crew when they were away from their stations. The management team believed that they required a radical and fast moving agenda to improve the provision of ambulance services to patients in London substantially. A computer-aided despatch system, combined with an automatic vehicle location system, full integration with mobile data terminals and a radio interface system was seen as a solution to this problem. Although not stated, it was probably also seen as a solution to other problems associated with organisation, over-manning and operational cost reductions. The LAS Board was therefore seeking a solution to a problem of considerable technical difficulty but which was also compounded by a complex human situation. This becomes more clear when the context of the project is reviewed.

Climate and culture

Within LAS there was a deeply ingrained climate of mistrust and obstructiveness between management and staff. Part o f the culture was an almost military management attitude with stiff upper lips and an expectation that orders would be carried out without question. Many managers and staff saw deadlines set by top management as being rigid, inflexible and not to be challenged. On the part of the ambulance crews, there was a pride in getting to the scene quickly, picking up the casualties and transferring them to hospital. Their emphasis was on patient care, regardless of the impact of their actions on other parts of the organisation. The industrial relations climate in 1990 was at an all time low after a very damaging national dispute over pay. There was a lack of middle management, this void being filled largely by the trade unions. It was therefore virtually impossible to fire or otherwise discipline personnel for anything but the most serious offences.

The computer-aided despatch system

The LAS was well aware of the deficiencies of a completely manual system and had attempted to introduce a computeraided despatch system in the early 1980s. This had included a new radio infrastructure and was expanded to include mobile data terminals. However, the project was abandoned in 1990, after load testing revealed that it would not cope with the demands likely to be placed on it. (The mobile data terminals and radio interface system were later further developed and integrated into the new system). A new team was then formed in 1990 under the Director of Support Services to create a totally automated system. The new management was under considerable pressure to improve the performance of LAS substantially. They had inherited a service where performance standards were extremely low and came nowhere near to meeting the nationally agreed ORCON standards for ambulance response. The Executive Board saw a new computer-aided despatch system as the prime means to improving these standards. There was therefore considerable self-imposed pressure to implement a new system that they saw as being such an important factor in improved performance. Unfortunately this view was not initially shared at all levels, as we shall see later.
What was LAS trying to achieve?

Performance requirements
The nationally recognised standards of performance for ambulance services issued by the Operational Research Consultancy (ORCON) call for the time taken from receipt of an emergency call to the issue of instructions to an ambulance station or crew to be no more than 3 min. An ambulance is required to arrive at the scene within 14 rain. This is an onerous requirement that could not be met by LAS with its existing manual system o f activating the
Table 1 Staff numbers Staff category Numbers Ratio %

Operational (accident and emergency) Operational (patient transport service) Control assistants Managers (accident and emergency) Managers (patient transport) Administration and clerical Maintenance and ancillary

1400 560 200 115 100 100 115

54 22 8 4 4 4 4

LAS was trying to introduce a major innovation. How different was it and what were the risks? In order to understand the new computerised system it is first necessary to look at the manual system that the computerised version was intended to replace.

Table 2 Number of vehicles Vehicle type Number Ratio %

Answering a call for help--the manual system The manual system is illustrated in Figure l. When a '999'
305 445 2 4 9 8 2
1

Accident and emergency ambulances Patient transport service ambulances Emergency control vehicles Emergency equipment vehicles Rapid response units Driver training units Motorcycle response units Helicopter 104

39 57

call comes into Central Ambulance Control, the call taker, a control assistant, writes the details on a form. A book of maps is used to locate the incident and provide a reference. The completed incident form is placed on a conveyor which transports it to a central collection point. The forms are collated and the details reviewed to eliminate duplication and assigned to a resource allocator, based on the three London divisions--north east, north west and south. Each resource allocator has an 'activation box' containing forms

London Ambulance Service computer-aided despatch system: M Hougham

999 H Call Received

Call Recorded onForm

Reference
Added

toCentral Point

,.~

~oou,~e,o H Mobilise Determined

~o~ov,~ H toResource Allocator

Resource Allocator H Determined

Eliminated

D pa~ uil e Callsc t

__

FomaMoved N to Resource Despatcher

Detemlines ifResource isMobile

FormMoved H to Radio Operator

Resource Despatched byRadio

Resource I Despatched by Telephone Figure 1 Operation of the manual system giving the status and location of their resources. This information is provided continuously by a radio operator. The allocator examines the forms for his/her own area and decides which resource should be mobilised. He/she notes this on the form and then passes it to a despatcher who then telephones the relevant ambulance station or passes mobilisation instructions to the radio operator if the ambulance is already mobile. There are some obvious problems with a totally manual system: At times a caller gives incomplete or inaccurate details; the identification of the precise location can be difficult and a number of alternatives have to be explored in the book of maps. The physical movement of paper forms around the control room is inefficient. Maintaining up-to-date vehicle status and location data is slow and laborious, relying on allocators' intuition and reports from ambulances as relayed through the radio operators. Voice communication with ambulances is time consuming, leading to mobilisation queues at peak times. Identification of duplicate calls is prone to error relying on human judgement and memory. Call-backs are not handled efficiently, with call administrators leaving their posts to talk to allocators. The identification of special incidents requiring a rapid response unit, a major incident team or a helicopter, relies totally on human judgement. However, there are situations where human brain power is superior to computer logic. These are where the human operator knows other unrelated information (such as the existence of a local football match or a major road works) and can apply it effectively to the current situation. The reduction of the facility for human intervention in the allocation of resources was to prove a major disadvantage in the troubled times ahead.

The aims and objectives of the new computerised system The aim was to create an almost totally automatic system, so the majority of calls to Central Ambulance Control could be dealt with by the call taker, who would despatch the most suitable ambulance resource. Only in the most complex cases would an allocator be needed to identify and allocate the best resource (and he/she would have superior tools at his/her disposal). All other allocations would be carried out by the call taker, who would take the call and see the incident through to completion. The computerassisted despatch system was therefore to provide the following command and control functions automatically:
Call taking and verifying incident details including location. Resource identification, determining which ambulance to send. Resource mobilisation, communicating details of the incident to the ambulance to be dispatched. Ambulance resource management, primarily the positioning of suitably equipped and staffed vehicles to minimise response times. Provision of management information to assess performance and help in medium- and long-term resource management and planning. The new system was to provide computer-aided despatch, computer map display and an automated vehicle location system. These new elements should interface with the existing mobile data terminals (installed as part of a previously aborted system) and integrated communications 105

London Ambulance Service computer-aided despatch system: M Hougham

Datatrak ] AutomaticVehicle Location

Servers I

Sites

(5 ofO

Radio ~ " - p ~ l Network I I

Mo ech I--

Interface System

Radio

Station Printers

Public Telephone Network

Automatic

I D' trib tr I

Call Taker

Emergency Call

Figure 2 Operation of the new computer-aided system

would be provided through a new radio interface system. The items which were already under development would be the subject of a new contract, not just a carry-on from the previous one. A diagram of the system is given in Figure 2. It was recognised that this would be a 'first'--no other emergency service had attempted to go so far. Carried out in one step it would equate to a quantum leap in the use of technology within the service. Nevertheless LAS needed something like this to help them meet the challenge of London. The LAS management saw this as the way to create optimum efficiency in the command and control process, and to help meet the requirements of the ORCON standards. button in the right sequence chaos could result (as was discovered at a later date).

New equipment and software

The new equipment and software was innovative to the Ambulance Service. However, the computerised data handling equipment, the quality of the technical communications (both voice and data), would be particularly important. If there were any corruption or delays to transmissions, the system would be thrown into disorder.

Time scale
The LAS was under significant pressure from all directions to achieve a rapid improvement in their service. Accordingly, the target programme dictated by their senior management was as shown in Table 3. With this short time scale it was inevitable that the programmes for policy making, planning and implementation would overlap. We shall review how this programme evolved in the next section.
Table 3 Milestone Milestone competition dates

Operational working changes

The operational working changes were to be dramatic and included the following: Replacement of paper system with almost fully automated computerised system. Replacement of subjective human judgement by computer logic. Replacement of the human radio operator contact with the ambulance crews with an automatic communication system. Reduction in staff levels. A new management structure would be required together with appropriate systems technical expertise (hitherto only available on a small scale within LAS). The operational working method for the ambulance crews would change in a most important way. The new mobile data terminals, in addition to providing instructions, would also be relied on to report position and status. This would reduce usage of radio time and eliminate radio congestion. It should therefore have been imperative to gain the full co-operation and joint ownership of the system from the ambulance crews. If they did not press the right 106

Date February 1991 July 1991 8 January 1992

Completion of system requirement specification Completion of system design specification System implementation

Project execution and what happened

The project moved ahead but the target date of 8 January 1992 could not be achieved. A phased introduction was then implemented, but this went disastrously wrong and resulted in a complete failure of the system in October 1992. What were the underlying reasons?

London Ambulance Service computer-aided despatch system: M Hougham Project management and control
A team was set up to prepare the system requirements specification, (SRS), composed of: Director of Support Services (chair) Systems manager A contract analyst The control room services manager Staff representing training, communications and other areas administrator. Other departments appear to be well represented but in the face of the major deficiencies inherent in the technical solution, they were powerless to prevent the problems soon to be revealed. The computer-aided despatch system and its software development were to be carried out using the PRINCE project management methodology. No clarification was made as to how this was to be applied and there were no personnel in the LAS team experienced in its application. A short training course was carried out but this proved to be insufficient and the disciplines of PRINCE were not adhered to or enforced. Throughout the contractor selection process, there had been ambiguity over the managerial role of the contractor. LAS had intended that the contractor's associate in the consortium, a large hardware manufacturer, would take the role of prime contractor and lead the project. In the event, the contract was placed with a small software house who subcontracted the hardware back to the other party. The contractor was therefore not prepared or set up to execute a prime contractor role and rapidly withdrew from activities of this nature. Responsibility for the overall coordination therefore reverted to the Director of Support Services who found himself spending more and more of his own time doing low level co-ordination and progress chasing. He had no middle management level personnel to do this for him. The Director of Support Services found his time increasingly under pressure as he had to carry out his normal duties as well as managing the project. With a more experienced professional project manager, many of the problems would have been identified earlier.

Invitations to participate were given to union representatives but there was little involvement from ambulance crews as there were problems with the staff consultation process at the time. The contract analyst did most of the work with direct assistance from the systems manager. As part of the development of the system requirements specification a companion paper containing a revised operational method of working was produced. This was aimed at both the Central Ambulance Control staff and ambulance crews but although it would impact seriously on the way they worked there was little consultation with the latter. A small sub-team consisting of the contract analyst and the systems manager was set up to handle the contract placement with additional help from a supplies manager from regional recruitment. The prime responsibility for the technical evaluation of the tenders fell on the contract analyst and the systems manager. The experience of the representative from regional supplies was in procurement in its most general sense rather than specific IT procurement. The systems manager was a career ambulance man who had taken over responsibility for LAS systems and communications some years before. Thus, a contractor and a systems manager (who incidentally, was arguably unsuitably qualified and knew that he was to be replaced and made redundant) were put in charge of the procurement of an extremely complex and high-risk computer system. An audit of the selection process was carried out by the systems manager of the Scottish Ambulance Service. The technical aspects of the tenders should have been adequately covered, however there was no one with specific project management or contract management experience involved in the process. This gave rise to serious deficiencies: Choice of a small IT contractor to manage a major programme. Acceptance of a programme which proved unachievable. Lack of definition of contractors' responsibilities. Acceptance of a contract price which, although close to the available budget, was unrealistic in comparison with the other quotations. When the project moved into the development stage, the project team was changed to: Director of Support Services LAS contract analyst Control room services manager Director of operations Training manager Public affairs manager CTS representative (communications) Administrative support Supplier representatives

Technical development
Work on the preparation of the system's requirements specification (SRS) went ahead in 1990 against a background of the recent abandonment of a previous computer-aided despatch system dating from the 1980s which could not technically handle the demands placed on it. It was an ambitious document, the functionality of the proposed system being greater than that available from any existing system. There was no evidence of any formal sign-off of the SRS. Other ambulance services do have systems support, but none of them could meet the LAS requirement. They were therefore discounted. The SRS was very detailed and contained a high degree of precision on how the system was intended to operate, being quite prescriptive, reflecting the culture of the organisation and providing little scope for additional ideas to be incorporated from prospective suppliers. However, as is normal in any SRS, there were areas not fully defined; notably details on the relationship and interfaces to other LAS systems such as: Radio interface system Communication system Patient transport system The full systems design specification (SDS) was prepared by the contractor during June and July 1991. The computer hardware was considered to be very powerful and generally resilient. The LAS network was not large in comparison with those of other organisations. The workstations were 486-based, running at 25 MHz using a Microsoft Windows environment that allowed an attractive and friendly graphical user interface and simultaneous 107

It is noticeable that there was no direct representation from the ambulance drivers (the users) and no contract

London Ambulance Service computer-aided despatch system: M Hougham

multi-tasking of applications. The programs, however, were designed for functionality rather than speed. All screen dialogues were written in Visual Basic, a relatively new tool designed for rapid systems development, rather than the development of fast systems. The way in which the operators used the multi-tasking Windows environment placed great demands on the processing power and memory available within the workstations thus reducing performance. It is probable that the unproven combination of Visual Basic and Windows 3.0 caused some of the early system failures. The processing power required for calculating time and distance increased considerably as the distance between incidents and the available resources grew larger. In effect, as available resources became fewer and more distant due to the number of incidents, the system inevitably slowed down. Change and configuration control were not maintained well and were one of the most important contributors to the complete system failure that occurred on 4 November 1992. The system, which needed near-perfect information, could not operate in an imperfect world. This was the penalty of using theoretical computer systems personnel to design a system and manage a project with so many interfaces to real life. It was also the penalty of trying to do too much in an unrealistic project time scale.

The programme
It is clear that neither the computer-aided despatch team, the users nor the hardware were ready for commissioning of the system on the due date of 8 January 1992 or on the revised date for full implementation of 26 October 1992. Significant facts, dates and activities were as follows: (a) Work on a previous system that had been on-going since the early 1980s was abandoned in 1990 due to its lack of capacity for dealing with the anticipated workload. (b) The new management team was formed in 1990 and the system requirement specification was completed in February 1991. (c) The system development and procurement contract was first advertised in the European Journal on 7 February 1991. The recommendation to award the contract was endorsed by the LAS Board on 28 May 1991. The contract for the radio interface system was placed on 16 September 1991. (d) The contractor prepared the full system specification during June and July 1991. He then had 5 months to achieve full system implementation by the due date of 8 January 1992. (e) By mid-December 1991 it was clear that this date could not be achieved. At that point the computer-aided despatch software was incomplete and largely untested. The radio interface system hardware and software were not fully delivered and tested. The installation of the ambulance tracking equipment (Datatrak) was incomplete and its reporting accuracy under question. (f) In January 1992 attempts were made at functional and load testing of the system. These tests were inconclusive and, over the next few months, various system elements were tested, but never as a fully integrated whole. (g) During the first 9 months of 1992 the system was implemented piecemeal across different London Ambulance divisions. (h) The system was fully implemented at 07:00 hours on 26 October 1992. As the day wore on the system became overloaded and it was necessary to revert to semi-manual operation. This solution worked with reasonable success up to the early hours of 4 November at which time it slowed significantly and then locked up altogether.

Key system problems

The system was designed to identify the nearest available resource (ambulance) with the correct status based on the information it had about status and location. The quality and reliability of the technical communications (both voice and data) would be a particularly important factor. If there were any delays or corruption in these transmissions, the system would be thrown into disorder. Despite the knowledge that at the initial tendering stage some of the unsuccessful bidders had expressed concerns about the validity of the communications infrastructure and its ability to cope with the anticipated load, no proper systematic investigation of this potential problem had been carried out. (Even though after experiencing problems with communications during the initial operating period, the Director of Operations had expressed his intention to carry out a 'full review of the radio network'.) Some of the poor allocations may have been attributable to errors in the allocation routines, but it is believed that most were due to the system not knowing the correct location or status of other vehicles which may have proved more appropriate. The system did not have perfect information for a number of reasons, including: (a) It was unable to catch all the data, partly due to poor coverage of the radio system (blind spots), and partly due to failure of ambulance crews to press the correct status buttons. This was assumed to be either due to inadequate training and the nature and pressure of certain incidents or because they became frustrated with re-transmission problems. (b) There were radio communication bottlenecks, particularly during busy periods or when crews changed shift and tried to log on via their vehicle mobile data terminals. (c) There were problems with crews taking different vehicles to those they were logged on to, or different vehicles and crews responding to the allocations made by the system. (d) Insufficient personnel taking calls and poor interfaces between the operators and the system and between the various parts of the system. 108

System testing and commissioning

What were the technical reasons for such a catastrophic failure? There were two aspects to the testing which were required to be carried out on the system: Functional testing to ensure that it does what is expected of it. Load testing to test the ability of the system to perform under maximum load. Unfortunately, the completeness and quality of the system testing were always in doubt due to the eventual

London Ambulance Service computer-aided despatch system: M Hougham

piecemeal delivery of equipment and implementation. It was recognised that testing a complete system as complex as this was never going to be easy, particularly when problems such as Datatrak location fixing inconsistencies and communication failures happen in real time and cannot easily be simulated. However, it should have been possible to factor into an automated test script an appropriate number of such failures and inconsistencies. There is no evidence that this was ever done. Following the first attempt at system testing in January 1992, the project group decided to implement a partial solution whereby call taking routines were implemented and the incident reports printed for manual allocation and voice despatch. The gazetteer was also to be brought into service, enabling control assistants to identify more easily locations of incidents. This was broadly successful but the printers used were not part of the original specification and gave rise to several system failures such as screens locking up and occasional server failures. This tended to undermine staff confidence, and was one of the inevitable consequences of a short-term expedient to show positive progress at an already published implementation date. Over the next few months, while work on all aspects of the system continued, various elements of the system were trialled. In particular, vehicle location and communication systems were tested in the north east division. This identified the following problems: Frequent incomplete status reporting by ambulance crews caused by inadequate training, communication failures and alleged misuse. Inaccurate Datatrak ambulance location fixes and problems with mobile data terminal information caused by faulty equipment, transmission black-spots and software errors. Inability of the system to cope with established working practices such as the taking of a vehicle different to the one allocated by the system. Overload of communication channels, particularly at crew shift change. Continued problems with hardware, especially the freezing of workstations and perceived system slowness. Software bugs in the resource proposal software causing it to fail to identify the nearest available resource. Over the first 9 months of 1992 the system was implemented piecemeal across the different London Ambulance divisions in three main phases, generally as follows: the first place rather than added out of desperation. A properly controlled organisation would not have allowed the next phase to be implemented until there was confidence in the previous one. During these months the system was never stable as changes and enhancements were made continually. There was no opportunity for the project team to stand back and commission a full system test. However, a positive decision was taken to go for full implementation in one phase on 26 October 1992, despite the fact that at that time there were at least two project issue reports which identified severe service degradation and that the system would not function in the operational environment until they had been rectified. There were also some 44 reports that identified operational problems which would result in poor quality of service to the patient.

Full system implementation The key changes made in order to enable the system to go live were:
Re-configuring the control room, separating resource allocators from radio operators. Installing more terminals and radio interface screens. Discontinuing the use of the manual paper activation box back-up system. Operating over the whole of London rather than in three divisions. Only using system proposed allocations with call takers able to allocate resources directly if they were less than 11 min away from the incident. Separate allocators handling 999 calls, doctors' urgent calls and patient transport calls. When the full system was implemented, instructions were given for minimal use of voice radio communications. The physical changes to the control room meant that staff were working in unfamiliar positions, without paper backup and less able to work with colleagues with whom they had previously jointly solved problems. The system itself did not fail in a technical sense, but much of the design had fatal flaws that cumulatively led to the symptoms of system failure. The system needed perfect information. However, because of the problems with communications, vehicle status and location reporting, it rapidly knew the correct status and location of fewer and fewer vehicles. The changes to Central Ambulance Control prior to going live made it extremely hard for staff to intervene. Furthermore, the restrictions placed on voice radio communications removed the essential feedback loop of real information. The overall effect on 26 October 1992 was that, as the day's normal workload increased, the whole system rapidly became unusable. A major reason for this was that errors could not be identified or corrected, which had the following impact: The system made incorrect allocations, sending multiple vehicles to the same incident or not selecting the closest vehicle. The system had fewer and fewer resources to allocate and did not know their correct status. Failures due to incorrect or missing information caused the system to generate large numbers of exception messages. Unrectified exception messages themselves generated more 109

Phase /--Using the call-taking software and gazetteer to help with the recording and location of incidents. Printers would then pass information to the allocators, who, using their traditional methods would mobilise the crews by radio or telephone. Phase 2 - - A s Phase 1, but with vehicle locations reported by Datatrak and mobilisation notification using the mobile data terminals. Human allocators would determine the optimum resources to be used as previously. Phase 3--Full implementation, whereby call takers would allocate using automated resource proposals provided that resources could arrive within 11 min of activation. Otherwise the allocators would identify and allocate the most suitable resources. Phase 3 was designed to operate without paper backup.
This phased implementation should have been planned in

L o n d o n A m b u l a n c e Service c o m p u t e r - a i d e d despatch system: M H o u g h a m

exception messages which added to the queue of items requiring attention. The congestion that could not be cleared became so great that it was found necessary to abort full implementation and revert to the semi-manual system of operation. All then went reasonably well until the early hours of 4 November, when the system slowed significantly and then locked up altogether. Attempts to restart it failed and Central Ambulance Control, on advice from senior management, reverted to a fully manual, paper-based system with voice or telephone mobilisation. (a) What was the cause o f the failure? The single technical fault (which was the final item to make the system inoperable) was a minor programming error. Three weeks previously a programmer had inadvertently left a programme code in the system that caused a small amount of server memory to be used up and not released each time a vehicle was mobilised. Over a 3-week period this had gradually used up all available memory, causing the system to crash. (b) Why did the back-up server not then come into operation ? This was due to the addition of the printers that had never been envisaged for the paper-less system and were added as a short-term expedient to implement partial operation on 8 January 1992. The fall-back to the second server was never implemented as part of this level of operation.

The former Chief Conciliation Officer of the Advisory Conciliation and Arbitration Service. Appropriate support was utilised from other personnel and confidential evidence was taken from a range of organisations associated with the project. The report was issued in February 1993. Several recommendations were made covering a range of topics including the functions of the LAS Board, management responsibilities, industrial relations and the immediate and future resource implications of the implementation of the report, and number of conclusions were drawn and recommendations made. The most significant conclusions were: LAS should continue to plan the implementation of the computer-aided despatch system. A suitably qualified and experienced project manager should be appointed immediately to co-ordinate and control the implementation of the first stage of computer-aided despatch and an IT director, with direct access to the LAS Board, should be recruited. Any new system should be introduced over a reasonable time scale, must have total ownership by managers and staff and be introduced in a stepwise approach. Where possible, steps giving maximum benefit should be introduced first. A renewed attempt at implementing the system is now proceeding, taking full account of these recommendations.

The enquiry
An enquiry team was set up by the South West Thames Regional Health Authority in November 1992: 'To examine the operation of the computer-aided despatch system, including: the circumstances of its failures on Monday 26 October and Wednesday 4 November 1992; the process of its procurement; and to identify lessons to be learned for operation and management of the LAS against the imperatives of delivering service at the required standard, demonstrating good working relationships and restoring public confidence.' The team comprised: The Chief Executive of South Yorkshire Metropolitan Ambulance and Paramedic Service NHS Trust. A senior computer audit partner from a reputable firm of consultants.

Bibliography
The material used in the preparation of this case study was taken from the report of the Inquiry into the London Ambulance Service dated February 1993.
Michael Hougham 's early career was in military electronics with GEC. He moved into construction engineering project management in 1977 and worked with both John Brown E & C and Stone & Webster Ltd on a wide variety o f projects in the north sea, on land in the UK and overseas. His specialisation is project management controls. For the past three years he has managed Greenlands Management & Engineering Consultants Ltd. He has recently accepted the position of Executive Officer with the Association of Project Managers.

110