The London Ambulance fiasco

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Configuration management
©Ian Sommerville 2004Software Engineering Case Studies Slide 1 The London Ambulance fiasco l The London Ambulance Service (LAS) Computer Aided Despatch.
The Failure of the London Ambulance Service Michael McDougall CIS 573 November 16 th, 1999.
Edward S. Shapiro Director, Center for Promoting Research to Practice Lehigh University, Bethlehem, PA Planning for the Implementation of RTI: Lessons.
Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
Project What is a project A temporary endeavor undertaken to create a unique product, service or result.
Delivery Business Solutions April 29, Nashville PMI Symposium April 29, 2013 Stephanie Dedmon, PMP Director, Business Solutions Delivery Department.
WHY THEY FAILED AND LESSONS TO BE DRAWN Samuel Franklin G53QAT: Quality Assurance and Testing Famous Software Failures.
Chapter 19: Network Management Business Data Communications, 4e.
1 Software Testing and Quality Assurance Lecture 2 Software Verification & Validation.
1 SWE Introduction to Software Engineering Lecture 3 Introduction to Software Engineering.
SWE Introduction to Software Engineering
Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department Southern Illinois University Carbondale.
Evaluating And Negotiating An IT Contract — The Buyer’s View Allan P. Weeks Attorney-At-Law Law Office of Allan Page Weeks Insert your logo in this area.
Topic 10Summer London Ambulance System Some of the slides created by Sommerville.
Development and Quality Plans
Chapter 2 A Strategy for the Appraisal of Public Sector Investments.
© 2008 Prentice Hall11-1 Introduction to Project Management Chapter 11 Managing Project Execution Information Systems Project Management: A Process and.
Project Execution.
Maths Counts Insights into Lesson Study 1. Mairead Murphy, Kevin Carey, Pat Brennan Second year Junior Certificate Taxation: Does your answer make sense?
Sharif University of Technology Session # 4.  Contents  Systems Analysis and Design Sharif University of Technology MIS (Management Information System),
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Extreme Programming.
Systems Life Cycle A summary of what needs to be done.
CS 4310: Software Engineering
Enhancing ERP System with RFID: Logistic Process Integration and Exception Handling Dickson K. W. CHIU Senior Member, IEEE Eleanna Kafeza Athens University.
Introduction to Information System Development.
CNJohnson & Associates, Inc An Overview of Chargeback Best Practices.
Lecture # 22 Software Evolution
S/W Project Management
CHAPTER 5 Infrastructure Components PART I. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: The need for SQA procedures.
Copyright Course Technology 1999
Commercial Database Applications Testing. Test Plan Testing Strategy Testing Planning Testing Design (covered in other modules) Unit Testing (covered.
1 CAPACITY BUILDING AND TRAINING ON PROCUREMENT Session 9 – The World Bank Procedures for IT Procurement September 21, 2005 by Arif Hassan.
Information Management in British Telecom Jon Hill.
Computers & Employment By Andrew Attard and Stephen Calleja.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Acceptance Testing Senior Design Fall 2013
INFO 637Lecture #81 Software Engineering Process II Integration and System Testing INFO 637 Glenn Booker.
9/12/2015Dr Andy Brooks1 Lecture 3 London Ambulance System (LAS) 26 & 27 October and November FOR0383 Software Quality Assurance.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
1 This workshop is part of our commitment to periodically provide you with updated information about BPA’s contracting and project management processes.
Evaluation of the SEND Pathfinder Programme: Early Findings Graham Thom and Meera Prabhakar May 2012.
S7: Audit Planning. Session Objectives To explain the need for planning To explain the need for planning To outline the essential elements of planning.
Creator: ACSession No: 16 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 (Software Quality) Configuration Management CSE300 Advanced.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
Audit Planning. Session Objectives To explain the need for planning To outline the essential elements of planning process To finalise the audit approach.
1 Activities covered by project management Feasibility study Is project technically feasible and worthwhile from a business point of view? Planning Only.
Lecture 11 Managing Project Execution. Project Execution The phase of a project in which work towards direct achievement of the project’s objectives and.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
What is Failure. “an IS system is some combination of hardware, communication technology and software designed to handle information related to one or.
I Power Higher Computing Software Development The Software Development Process.
13 Step Approach to Network Design Steps A Systems Approach 8Conduct a feasibility Study 8Prepare a plan 8Understand the current system 8Design.
Post Implementation Review The Post Implementation Review is carried out once the system is fully operational. The Post Implementation Review is carried.
Pre-Project Components
1 Institute for Software Research, International Methods of Software Development Problem Frames 3 (This lecture is largely based on material graciously.
The London Ambulance Service Case. The Manual System 999 call to BT Call switched to LAS call takers –Record details & map reference onto a form Send.
SE Joint Firelink and FiReControl Project. CFO Martin Burrell FiReControl and Firelink Project Director CFO Martin Burrell FiReControl and Firelink Project.
CS223: Software Engineering Lecture 18: The XP. Recap Introduction to Agile Methodology Customer centric approach Issues of Agile methodology Where to.
INFO 3: Use of ICT In The Digital World Topic 7: Developing ICT Solutions Factors that contribute to the success and failure of ICT Systems.
Software Design and Development Development Methodoligies Computing Science.
S TANDARDS, CERTIFICATION AND ASSESSMENT C HAPTER 23 Dr. Ahmad F. Shubita.
1 Software Testing and Quality Assurance Motivation and Review of Software Verification & Validation (2)
Personal Wheelchair Budget Programme
Case Study: The Accounting Software Installation Project
The Accident On October 26th 1992 the London Ambulance System failed.
Chapter 9 – Software Evolution and Maintenance
What is a System? A system is a collection of interrelated components that work together to perform a specific task.
The London Ambulance fiasco
Presentation transcript:

The London Ambulance fiasco The London Ambulance Service (LAS) Computer Aided Despatch (CAD) system failed dramatically on October 26th 1992 shortly after it was introduced: The system could not cope with the load placed on it by normal use; The response to emergency calls was several hours; Ambulance communications failed and ambulances were lost from the system. A series of errors were made in the procurement, design, implementation, and introduction of the system.

London Ambulance Service Managed by South West Thames Regional Health Authority. Largest ambulance service in the world (LAS inquiry report) Covers geographical area of over 600 square miles Resident population of 6.8 million people (greater during daytime, especially central London); Carries over 5,000 patients every day; 2,000-2,500 calls received daily, of which 1,300-1,600 are emergency calls.

Computer-aided despatch systems Provide one or more of the following: Call taking; Resource identification; Resource mobilisation; Ambulance resource management. Consist of: CAD software & hardware; Gazetteer and mapping software; Communications interface (RIFS). Radio system; Mobile data terminals (MDTs); Automatic vehicle location system (AVLS).

The manual system to be replaced Call taking Recorded on form; location identified in map book; forms sent to central collection point on conveyor belt; Resource identification Form collected; passed onto resource allocator depending on region; duplicates identified. Resource allocator decides on which resource to be mobilised; recorded on form and passed to dispatcher; Resource mobilisation Dispatcher telephones relevant ambulance station, or passes mobilisation instructions to radio operator if ambulance already on road; Whole process meant to take < 3 minutes.

Concept/design of the CAD system Existing systems dismissed as inadequate and impossible to modify to meet LAS’s needs Intended functionality “greater than available from any existing system”. Desired system: To consist of Computer Aided Dispatch; Computer map display; Automatic Vehicle Location System (AVLS); Must integrate with existing MDTs and RIFS (Radio Interface System). Success dependent upon: Near 100% accuracy and reliability of technology; Absolute cooperation from all parties including CAC staff and ambulance crews.

Problems: Procurement (i) Contract had to be put out to open tender Regulations emphasis is on best price; 35 companies expressed interest in providing all or part of the system Most raised concerns over the proposed timetable of less than 1 year until full implementation. Previous Arthur Andersen report largely ignored Recommended budget of £1.5M and 19 month timetable for packaged solution. Both estimates to be significantly increased if packaged solution not available; Report never shown to new Director of Support Services. Only 1 out of 17 proposals met all of the project team’s requirements, including budget of £1.5M.

Problems: Procurement (ii) Successful consortium Apricot, Systems Options (SO), Datatrak; bid at £937k was £700k cheaper than the nearest bid; SO’s quote for the CAD development was only £35k Their previous development experience for the emergency services was only for administrative systems. Ambiguity over lead contractor. 2 key members of evaluation team: Systems manager: Career ambulance man, not an IT professional, already told that he was to make way for a properly qualified systems manager; Analyst: Contractor with 5 years experience working with LAS.

Problems: Project management Lead contractor responsible Meant to be SO, but they quickly became snowed under, so LAS became more responsible by default; No relevant experience at LAS or SO. Concerns raised at project meeting not followed-up. SO regularly late in delivering software Often also of suspect quality, with software changes put through ‘on the fly’. Formal, independent QA did not exist at any stage throughout the CAD system development. Meanwhile, various technical components of the system are failing regularly, and deadlines missed.

Problems: Human resources & training (i) Generally positive attitude to the introduction of new technology. Ambiguity over consultation of ambulance crews for development of original requirements. Circumstantial evidence of resistance by crews to Datatrak equipment, and deliberate misleading of the system. Large gap between when crews and CAC staff were trained and implementation of the system. Inability of the CAC and ambulance staff to appreciate each others’ role Exacerbated by separate training sessions.

Problems: Human resources & training (ii) Poor industrial relations. Management ‘fear of failure’. CAD system seen as solution to management’s desire to reduce ‘outdated’ working practices. System allocated nearest resource, regardless of originating station. System removed flexibility in resource allocation. Lack of voice contact exacerbated “them and us”. Technical problems reduced confidence in the system for ambulance crews and CAC staff.

Need for near perfect information System problems Need for near perfect information Without accurate knowledge of vehicle locations and status, the system could not allocate optimum resources. Poor interface between crews, MDTs & the system There were numerous possible reasons for incorrect information being passed back to the system. Unreliability, slowness and operator interface Numerous technical problems with the system, including: Failure to identify all duplicated calls; Lack of prioritisation of exception messages; Exception messages and awaiting attention queues scroll off top of screen.

Configuration changes Implementation of the system on 26 October involved a number of significant changes to CAC operation, in particular: Re-configuring the control room; Installing more CAD terminals and RIFS screens; No paper backup system; Physically separating resource allocators from radio operators and exception rectifiers; Going ‘pan London’ rather than operating in 3 divisions; Using only the system proposed resource allocations; Allowing some call takers to allocate resources; Separate allocators for different call sources.

So, what happened? Changes to CAC operation made it extremely difficult for staff to intervene and correct the system. As a consequence, the system rapidly knew the correct location and status of fewer and fewer vehicles, leading to: Poor, duplicated and delayed allocations; A build up of exception messages and the awaiting attention list; A slow up of the system as the messages and lists built up; An increased number of call backs and hence delays in telephone answering.

Technically, the system did not fail on October 26th Why did it fail? Technically, the system did not fail on October 26th Response times did become unacceptable, but overall the system did what it had been designed to do! Failed 3 weeks later due to a program error - this was a memory leak where allocated memory was not completely released. It depends who you ask! Management; Union; System manager; Government.

Lessons learned Inquiry report makes detailed recommendations for future development of the LAS CAD system, including: Focus on repairing reputation of CAD within the service; Increasing sense of ‘ownership’ for all stakeholders; They still believe that a technological solution is required; Development process must allow fully for consultation, quality assurance, testing, training; Management and staff must have total, demonstrable, confidence in the reliability of the system; Any new system should be introduced in a stepwise approach.