Topic 10Summer London Ambulance System Some of the slides created by Sommerville.

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

Topic 10Summer London Ambulance System l Implemented Computer Aided Despatch (CAD) system l Failed Dramatically on October 26 th 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 l Errors from requirements through design, implementation and introduction of the system

Topic 10Summer Problems from the start l Yes, there were programming errors.. But the system crash was not the worst of it l Lack of communication l Management and Staff had strained relationship l Exceptional time and $$$ pressures l Requirements – Must be less then £1.5M Must be done in 11 months l Anderson Consulting said £1.5M if they could find pre-packaged systems »Much more if no pre-packaged systems 19 months l 17 companies bid – they went with the cheapest (<£1M ) l Hmmm what’s wrong with this picture?

Topic 10Summer Concept/Design of the CAD system l Existing systems dismissed as inadequate l Desired system CAD + Computer Map Display + Automatic Vehicle location system Must integrate with MDTs(Mobile data terminals) and RIFs(Radio Interference system) l Success dependent up on 100% accuracy and reliability of technology Cooperation from all parties

Topic 10Summer Problems in a Nutshell l Strained relationships between Staff & Management l CAD system “management’s solution to outdated working practices” l Staff was not involved in the requirements process l Bad assumptions made during specification process l Staff needed to drastically change their work process l Software was incomplete and untested l “high risk” implementation approach l Ambulance crews and Staff trained long before using the system l Reorganization of control room…loss of local knowledge

Topic 10Summer These led to… l Inadequate requirements l Ill thought out requirements or design l Low cost expectation but high functionality expectation l Human Computer Interface difficulties l Documentation lacking

Topic 10Summer Project Management Problems l Evaluation team System manager – ambulance man – not IT Analyst – contractor – 5 years at LAS l Who got the contract? Systems Options, Datatrak, Apricot – consortium Who’s the lead dog? No relevant experience anywhere l No Independent QA

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

Topic 10Summer Resulting System (2) l Communication errors led to… Radioed in blackspots Ambulance crews pushing wrong buttons … and so on l... 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

Topic 10Summer Resulting System l … 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 l Frustrated Callers More duplicate calls Not enough call takers More delays l Frustrated Crews More mis-pressed buttons Greater volume of radio calls Bottleneck on Radio transmissions – Crews taking wrong vehicles … and on and on… l System slowed until it crashed. Outcome : missing vehicles, lack of prioritisation duplication of call outs, calls lost.

Topic 10Summer LAS l LAS did not fail because of the minor programming mistakes l 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 l Reasons for failure depend on who you talk to Management, Crew unions, system manager, government

Topic 10Summer Lessons Learned l Development must allow fully for consultation, QA, testing, training l Management & Staff must have confidence in the system l A new system should be introduced in a stepwise approach