The Disaster in London-The LAS Case study
Description of the case situationThis case describes the process where London Ambulance Service throughout the last 20 years has tried to implement a new and it-based despatch system. There have been several phases and parts of the project, and when looking back at it today the period is characterized by chaos and problems.Starting in the early 1980’s with LAS realizing their manual system had to change because of inefficiency, too high level of human dependence and problems with managing the national three minute activation standard. The proposal was a computer-aided dispatch system with a computer map display and automatic vehicle location system. The project and development started in 1987 but after three and a half years the project was terminated with overruns on both time and costs.After a review of the first project LAS started to search for an operating dispatch system, but none satisfied LAS requirements. They had to develop a new system and decided to go for one which would go even further than the first try in human independence. With intention of doing better than first time the plans for the new software was developed with an eye to saving cost and especially time, and this created an outline for choice of contractor. In March 1991 Apricot was chosen as main contractor for the hardware, while System Options was in charge of software development. There were early signals that both Apricon and System Options in this project were facing bigger challenge than they’d ever met before, and LAS did not consider references that claimed both lack of technical skills and ability to keep the time limits.In the period between this and January 8 when the system was to be finished LAS experienced some internal problems with reduction and restructuring in both budget and staff which led to lack of stability and less satisfying working conditions. The employees were not involved in the development process and there were no training or education provided. At the same time they understood that the system wasn’t working to expectations and that they wouldn’t make time-limit. On basis of this they had to make a new schedule were they divided the remaining work and needed implementation processes into three phases. This break down of implementation structure and rush of implementation led to immediate software errors, equipment failures and other problems. Still they did not prioritized testing of software, and the backup system was not cleared.