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 (<£1M ) • Hmmm what’s 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 “management’s 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 room…loss 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 • Who’s 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