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

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

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

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).

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.

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

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.

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.

Table 1 Staff numbers

Staff category

Operational (accident and emergency)

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

Numbers

Ratio %

1400
560
200
115
100
100
115

54
22
8
4
4
4
4

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

was

LAS

trying

to achieve?

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.

Answering a call for help--the manual system

The manual system is illustrated in Figure l. When a '999'

Table 2 Number of vehicles

Vehicle type

What

Number

Ratio %

305
445
2
4
9
8
2

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

,.~

~oou,~e,o
Mobilise H
Determined

__

FomaMoved N
to Resource
Despatcher

Call
Recorded
onForm

~o~ov,~
toResource H
Allocator

Detemlines
ifResource
isMobile

Reference
Added

toCentral
Point

DCalls
upcilate~

Resource H
Allocator
Determined

Eliminated

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

Mo ech I--

Radio ~ " - p ~ l
Network I I

Sites

(5 ofO

Station
Printers

Public
Telephone
Network

Automatic

I D' trib tr I

Servers I

Radio

Interface
System

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.

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

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 competition dates

Milestone

Date

Completion of system requirement specification

Completion of system design specification
System implementation

February 1991
July 1991
8 January 1992

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

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

It is noticeable that there was no direct representation

from the ambulance drivers (the users) and no contract

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.

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

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.

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

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.

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:

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

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

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.

110

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.