The London Disaster: The LAS Case StudyDescription of the Case SituationThis case describes the process by which the London Ambulance Service has over the last 20 years attempted to implement a new IT-based ambulance service system. There were different phases and parts of the project, and if you look back today, the period is characterized by chaos and problems. Starting in the early 1980s when LAS realized that their manual system needed to change due to inefficiency, too high a level of human staff dependency and problems managing the national three minute activation standard. The proposal was a computer-aided dispatch system with computer map display and automatic vehicle tracking system. The design and development began in 1987 but after three and a half years the project was finished with both time and cost overruns. After a review of the first design LAS began looking for an operational dispatch system, but none met the LAS requirements. They had to develop a new system and decided to adopt one that went even further than the first attempt at human independence. With the intention of doing better than the first time, plans for the new software were developed with an eye to saving costs and more importantly time, and this created a framework for choosing the contractor. In March 1991 Apricot was chosen as the main contractor for the hardware, while System Options was responsible for software development. There were early signs that both Apricon and System Options were facing a bigger challenge on this project than they had ever faced before, and LAS did not consider references that stated both a lack of technical expertise and the ability to maintain the limits of time. In the period between this and 8 January, when the system was due to be completed, the LAS encountered some internal problems with reductions and restructuring of both budget and staff which led to a lack of stability and less satisfactory working conditions. Employees were not involved in the development process and no training or education was provided. At the same time they understood that the system was not working as expected and that they would not set time limits. Based on this they had to draw up a new program in which they divided the remaining work and the necessary implementation processes into three phases. This breakdown of the implementation structure and rush of implementation led to immediate software failures, equipment failures, and other problems. However they did not prioritize software testing and the backup system was not cleaned.