Improvement of London Ambulance Service (LAS) - Case Study Example

It is easy to dive into IT projects thinking they are the solutions one has been seeking. Technology is merely a tool and not a solution in itself. It is the first step towards finding the solution. In business, one is perpetually looking for solutions to problems. With the emerging technology, it is natural for businesses to turn to IT to find a solution. IT can help to cut costs, automate certain menial tasks, improve productivity, and even enhance communication but one should be careful before looking beyond these fields. It invariably brings discredit to technology because people have very high expectations without realizing how to use it as a tool. The London Ambulance Service IT project was too ambitious and is an apt example of failure where technology was mistaken to be the solution. The London Ambulance Service (LAS) was responsible for accepting emergency medical calls and for dispatching ambulances as appropriate. LAS employed a computer aided dispatch (CAD) system to understand the emergency, resource the ambulance and dispatch. The ambulances were also fitted with an automatic vehicle location system (AVLS) which facilitated the CAD to track its progress in fulfilling a particular requirement. This project to make a CAD first started in 1987 with a budget of 3 million pounds. The objective was to automate human intensive processes of manual dispatch systems. It was abandoned in 1990 when the costs overshot but then a new management team was appointed in January 1991. After many deliberations, the system did go partially live a year later only to shut down in October 1992. LAS was the largest in the world, which covered 600 sq miles, 7 million people and had a fleet of 700 ambulances. Founded in 1930, LAS attended to 1600 emergencies per day. Government changes in NHS from mid-80s onwards led to pressure on LAS due to internal market, which led to management restructuring and disputes over working practices (London Ambulance Service Case Study). The magnanimity of the service did cause bottlenecks. Communication errors, difficulty in identifying the right locations, human judgment in identifying duplicate calls were disrupting services. To bring about overall efficiency computerization was sought. Various factors were responsible for the failure of the project, which include management ethos, bad procurement process, timetable, inexperience of suppliers, inadequate testing, poor quality assurance, poor training, and finally inadequate project management. The biggest mistake that occurred was the decision to switch over from completely manual to completely automatic system in one go. The project sought to computerize maps, track vehicles, automate allocation of vehicles, and identify duplicate calls. Perhaps this could have been taken up in phases after the success of each step. The attempt to remove human errors through complete automation resulted in its failure. With the new technology, the Call Allocator (CA) received the calls and then entered the details in the CAD. The location details including the phone number were automatically found by the CAD. The location could be pinpointed, recorded details compared so that ambulances could be mobilized. LASCAD was built as an event based system using a rule-based approach in interaction with geographical information systems (GIS). Systems Options (SO), the company who were awarded the contract used their own GIS software (WINGS) running under Microsoft windows. This was the CAD design: The technology was based on the client-server workstation model using three servers (one operational and two backups). Most of the processing was undertaken by 25 MHz Intel 486 PC and the decision making code was written in ‘C’. The usability was expected through the windows 3.0 operating system. The Project Management Methodology (PRINCE) was chosen, despite neither LAS nor contractors having experience in it. The software that was used failed to identify the closest ambulance at hand. It also failed to recognize every 53rd vehicle in the fleet. This was caused by an error in a formula provided by Datatrak to SO. Communication channels became overloaded and inaccurate vehicle locations were generated. The workstations started being locked up and the system was too slow to respond for CAs. Error messages were not dealt with timely and the status information received from the ambulances were found to be unreliable. The crew used ambulances different from what was allocated which compounded the confusion. The system slowed down largely and lead to increase in load. It became a vicious circle because increase in load leads to slowing of the system. This resulted in calls not reaching the ambulances. The system was unable to identify duplicate calls, and calls were being lost in the system. Service deteriorated and the staff and public lost confidence in the service. The GIS software that was used did not relate the geographical distance to time. The technology used could not calculate the closest vehicle especially when the resources are few. The software bugs in the resource proposal software caused this failure to locate the nearest resource. Whether the load could cope with excessive demand was not to put to test before implementing it. The functional aspects were not understood; the Radio dispatch and communication system never tested -- live operation would provide opportunity for "full review of radio network capability." The two backup servers and rest of backup system were never tested. The operational problems were ignored. It was designed on the assumption that no duplicate calls would come, the ambulance crew would never press the wrong button or that no locations would be unknown. Failure of backup servers was due to the changes in the system design that were continually required, and that were often implemented on only the main server -- rendering the backup servers obsolete without anyone apparently realizing it. Among other things, the inefficiencies of the system caused ambulance dispatch to be so poor that one ambulance arrived after the patient had already died, and been taken away by the undertaker. The AVLS failed due to an unusually high call volume. Had the system been designed to handle load spikes this would not have occurred. The design of the AVLS was so poor that even in normal operational conditions it was close to its maximum capacity, which immediately created overload. The system was in a state of unstable equilibrium. There was no provision to detect the failures in the early stages so that rectification measures could ensure smooth operations. The system could then remain there until an operator could debug and resolve the problem. There was no back up system. Once problems were detected, it was impossible for the operators to use any of the system. The resilience of the hardware was not tested under full load. There were outstanding problems with data transmission to and from the mobile data terminals. There were too many imperfections in the system. The project team was under pressure to achieve a quick and successful implementation of the project. We can thus conclude that the prime reason for this project failure was imposition of the solution without investigating the problems. It is important to understand the problem before suggesting solution. Conceptualizing and communicating is vital before building a system. The chart above illustrates the various reasons that lead to IT project failures. Following the London Ambulance IT Project failure, other companies should derive a lesson from it before venturing into technology. It is necessary to understand because it is only through an understanding of failed systems that we can formulate a view of what a successful system would be and, perhaps, the role of specification and design in this context. The lessons that can be derived are that part of the failure boils down to perception and communication. Learning by rote is not important. What matters is the right application of the knowledge, which can differ from situation to situation. People do get excited at the prospects of being able to use technology and automate systems but deeper insight is called for. As is evident from the LAS failure lack of accountability, lack or trained people to operate the system, inexperienced suppliers all contribute to the failure. IT systems do not actually do what we want them to do. Any IT project must involve a proper consultation between the management, the staff and of course the technical experts. The field workers cannot be ignored because it is they who are responsible for the successful operations. In fact, they can bring to light the problems to be handled. At the same time, they should be receptive to new ideas. Another important to bear in mind is that IT projects cannot be implemented under pressure. It has to be constantly tested at each stage, which means a systematic transition is advisable. All possible failures and lacunae in handling and input of data have to be considered. Experience of suppliers is necessary and the latest software has to be used. While accountability is important in such projects, the top-level management should not keep the reins in their hands. It is the second level of management that should be responsible because they do the actual work in such cases. The top-level management are only the policy makers. Importance should not be given to low cost but to performance and experience when awarding contracts. Projects fail when attention is not paid to project risks and when the process is inadequate and inappropriate. Repeated IT failures remain a pressing concern in the industry. It is not merely a technical issue, which can be resolved with technology. It is a business issue, which requires accountability, proper communication, commitment, and understanding of the problem. One has to be prepared for the numerous problems that can occur. The time frame and expectations both have to be realistic, and the objectives outlined. LAS perhaps had a dream to use a single leading edge technology to fix all its problems overnight. They wanted to improve poor performance and automate the staff problems. The system that was designed was under the premise that merely using CAD could change local practices. Such a dream indicates a naïve approach to the use of technology. References: London Ambulance Service Case Study, URL: < http://www.eee.bham.ac.uk/lonsdalepr/teaching/HCI/las.html> accessed 14 Oct 2005 Read More