London Ambulance System

1
London Ambulance System

• Some of the slides created by Sommerville.

2
London Ambulance System

• Largest Ambulance System I the world
• Responsible for
• 600 square miles
• 6.8 million residents (plus visitors)
• Carries over 5000 patients a day
• 2000-2500 calls daily 1300-1600 911
  equivalent
• Computer-aided despatch
• handles call taking
• determines ambulance to send
• handles mobilization of ambulance, sends details
  of incident to ambulance
• manages ambulance resources

3
London Ambulance System

• Implemented Computer Aided Despatch (CAD) system
• Failed Dramatically on October 26th 1992 after 2
  days of operation
• Could not cope with normal load
• Response to calls was several hours (delays up to
  3 hours)
• 3 minute turn around expected
• Ambulance communications failed and ambulances
  were lost from the system
• Some claimed it could have been responsible for
  20 deaths chief executive resigned
• Errors from requirements through design,
  implementation and introduction of the system

4
Problems from the start

• Yes, there were programming errors.. But the
  system crash was not the worst of it
• Lack of communication
• Management and Staff had strained relationship
• Exceptional time and pressures
• Requirements
• Must be less then 1.5M
• Must be done in 11 months
• Anderson Consulting said
• 1.5M if they could find pre-packaged systems
• Much more if no pre-packaged systems
• 19 months
• 17 companies bid they went with the cheapest
  (lt1M )
• Hmmm whats wrong with this picture?

5
Concept/Design of the CAD system

• Existing systems dismissed as inadequate
• Desired system
• CAD Computer Map Display Automatic Vehicle
  location system
• Must integrate with MDTs(Mobile data terminals)
  and RIFs(Radio Interference system)
• Success dependent up on
• 100 accuracy and reliability of technology
• Cooperation from all parties

6
Problems in a Nutshell

• Strained relationships between Staff Management
• CAD system managements solution to outdated
  working practices
• Staff was not involved in the requirements
  process
• Bad assumptions made during specification process
• Staff needed to drastically change their work
  process
• Software was incomplete and untested
• high risk implementation approach
• Ambulance crews and Staff trained long before
  using the system
• Reorganization of control roomloss of local
  knowledge

7
These led to

• Inadequate requirements
• Ill thought out requirements or design
• Low cost expectation but high functionality
  expectation
• Human Computer Interface difficulties
• Documentation lacking

8
Project Management Problems

• Evaluation team
• System manager ambulance man not IT
• Analyst contractor 5 years at LAS
• Who got the contract?
• Systems Options, Datatrak, Apricot consortium
• Whos the lead dog?
• No relevant experience anywhere
• No Independent QA

9
Resulting system

• System removed flexibility in resource allocation
• System allocated nearest resource, regardless of
  originating station
• Lack of voice contact exacerbated us vs them
• Technical problems reduced confidence in the
  system for ambulance crews and staff
• No backup system
• No incremental deployment

10
Resulting System (2)

• Communication errors led to
• Radioed in blackspots
• Ambulance crews pushing wrong buttons
• and so on
• ... Resource confusion which led to
• Software could not identify nearest available
  resource.
• Multiply crews sent to the same location
• Inaccurate location information.
• Communication channels overloaded.
• Mobile data systems failed.
• Ambulance crews took different vehicles from one
  allocated

11
Resulting System

• Enormous exceptions led to
• Also due to
• failure to identify all duplicated calls
• Lack of prioritisation of exceptions
• Operator workstations locked up queues scrolled
  off the top of the screen
• Slower response
• Frustrated Callers
• More duplicate calls
• Not enough call takers
• More delays
• Frustrated Crews
• More mis-pressed buttons
• Greater volume of radio calls
• Bottleneck on Radio transmissions
• Crews taking wrong vehicles and on and on
• System slowed until it crashed.
• Outcome missing vehicles, lack of
  prioritisation
• duplication of call outs, calls lost.

12
LAS

• LAS did not fail because of the minor programming
  mistakes
• Reasons for failure
• project schedule was far too tight
• LAS management has little or no experience in
  software projects of this magnitude
• ditto for contractor
• they were far too optimistic in their assessment
  of risks
• they also assumed all people who would interact
  with the system would work with it exactly as
  specified
• Reorganization of control room made it difficult
  for staff to intervene
• Reasons for failure depend on who you talk to
• Management, Crew unions, system manager,
  government

13
Lessons Learned

• Development must allow fully for consultation,
  QA, testing, training
• Management Staff must have confidence in the
  system
• A new system should be introduced in a stepwise
  approach