Case Study: London Ambulance Service Fiasco

Problem Definition

In October of 1992, the new computer aided dispatch system of the London Ambulance Service (LASCAD) failed to meet the demands of use and brought their operations to a standstill. Dispatchers could no longer locate ambulances, multiple ambulances showed up for the same calls, errors built up in the queue slowing the system down further, and callers became frustrated as the hours went by with no ambulance showing up (London Ambulance Service Unofficial, n.d.). In addition, it has been targeted for causing the deaths of approximately 20-30 people in the process, due to excessive wait times for transport to the hospital. This unfortunate incident is one of the poster children for examples of the ramifications of poor management and lack of process in software development.

Problem Justification

After scrapping an Ј7.5 million project to computerize its system, the London Ambulance Service put the project out for bid again. The new budget for development was one-fifth the cost of the prior project that failed and to be done in one-third of the time of the prior effort. Only one of the over 30 respondents was able to come in at or under that Ј1.5 number with the desired development timeframe (Beynon-Davies, 1999). That alone should have been an indication that something was wrong in the project. However, as typical with government/union type projects, the lowest bidder was selected to complete the project and work began.

A comedy of errors then ensued as the development of the new system continued. According to Beynon-Davies (1993), most of the errors found in the investigation lead directly to project organization, summarized as follows: overambitious timetable, insufficient investigation of winning developer, inadequate project management, incomplete and unstable software, and improper training delivered to the end user. Despite these numerous red flags that appeared throughout the project, development with System Options continued and the system was put into production on October 26, 1992.

On that day, as the call load increased slightly above average on that day, a number of errors occurred in the system. Senior staff would take a preferred ambulance rather than the one that they had been assigned, improperly trained staff pressed the wrong buttons, callers would call back repeatedly increasing the call load and vehicles got lost in the system. As seen in Figure 1 below, the errors compounded on one another leading to the complete meltdown of the system.

Figure 1: Model of the LASCAD Failure (Beynon-Davies, 1993)

Alternative Courses of Action

Numerous articles and case studies have been written in depth on the failure of the LASCAD system, and ways it could have potentially been adverted. The methods and theories are endless and there is not one solution to the problem. However, there are some very simple steps that could have occurred that would have negated this tragedy.

1. Use of an iterative software development lifecycle rather than an incremental one

2. Addition of a UAT clause into the contract by London Ambulance Service

3. Proper Use Case Modeling

4. Adherence to the PRINCE Project Management Method

Evaluation of Alternatives

Alternative Strengths Weaknesses

Use of an Iterative Software Development Cycle * Flaws in system could have been discovered early on with first release

* Certain functionality would be available sooner to streamline the London Ambulance Service * Not all requirements would be met with the first release.

* Multiple releases could possibly result in additional end user training, additional costs and a longer delivery time for the final product

Proper Use Case Modeling * Would have documented the real scenarios that needed to occur, rather than what the System Options contractor thought should occur

* Use cases could have been transferred to the testing phase as test cases. * Could add time to the development lifecycle and additional cost to the end product

* May have increased friction between the staff and management if they were allowed to participate in the development of the product.

User Acceptance Testing Clause * Actual users of the system would have performed testing and tested the system as a whole prior to the launch. According to the Inquiry report, (Page, Williams & Boyd, 1993) various systems elements were tested, but never as a fully integrated whole. * Could add time to the development lifecycle and additional cost to the end product