Case Study: London Ambulance Service Fiasco Essay Example
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
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