Failure of the London Ambulance System - Case Study Example

 ABSTRACT Human errors and systems failure have been prominent in IT projects in UK. Risk analysis is seldom resorted to by the IT projects. IT projects are also undertaken without adequately training the personnel handling the system. To a large extent the failure of LAS can be attributed to failure in applying the PRINCE project management method specified for public sector projects. The success of Terminal 5 project lies in the identification and application of tools and techniques to solve the problems of project development. Flexibility in finance and time scales is essential in any project, which was another important reason for the success of Terminal 5 and the failure of LAS. IT projects must be constantly tested at each stage and have a systematic transition. There has to be a balance between formal procedures and social attitude to minimize risk. Innovatively and positively integrated team with shared values can make a major contribution to the success of the project. Table of Contents 1. Introduction 5 2. Details of Projects London Ambulance System 7 Terminal 5 Program 10 3. Reason for success/failure 11 4. Importance of IT 15 5. Learning Outcomes 16 6. Conclusion 17 7. References 18 INTRODUCTION IT projects in any organization support the operation, management, analysis and decision making function within an organization but research has also shown that many IT projects have to be abandoned. Amongst the high profile IT project failures features the London Ambulance System (LAS). One factor consistent with all IT projects is the fact that only 30% of the organizations applied risk analysis in their IT investment and project management processes (Bacarrini, Salm & Love, 2004). Risk analysis was limited to financial calculations. Organizations need to improve their ability to manage IT projects so that projects can be delivered successfully. The failure of LAS contains within it failure of the development problems and problems in use. It highlights that the nature of information systems failure is multi-faceted. In the construction industry, the design process and the people differ significantly from the stylized models. To this is added uncertainty, which demands specialization and the need to communicate with experts (Demaid & Quintas, 2005). The formal process of design and bidding is common to all projects, be it in the IT industry or the construction industry. Risk analysis for any project is equally important. There has to be a balance between formal procedures and social attitude to minimize risk. Terminal 5 (T5) program is one of the great engineering success of the 21st century, which will be completed on time, under budget and with no impact on airport’s day to day business operations (Mottmac, 2006). For T5 the goal was to create “the world’s most refreshing interchange” (Lane & Woodman, n.d.) while the purpose of LAS was to automate the human-intensive process of manual dispatch systems. In trying to pursue its goal, projects fail to recognize the need for flexibility to adapt to the changing market conditions and technology advancements. This report will highlight the details of the two projects while projecting the reasons for their respective failure/success. It will also suggest how the failure could have been avoided and finally the lessons learnt from the success and failure of these two projects. PROJECT DETAILS LONDON AMBULANCE SYSTEM (LAS) LAS was one of the largest of its kind in the world receiving on an average 3200 calls per day. The city is split into seven sectors and each sector team managed the work of about 35 ambulances from 10 ambulance stations (Blandford, Wong, Connell & Green, 2002). The control room had a separate section for call taking and dispatch. There were 24 call takers’ position and there was no communication among the call takers. The dispatch area was organized around the seven sector desks. Each sector desk comprised of 3 or 4 people and the sector head allocated the vehicle or personnel for each incident. The radio operator maintained contact with the crew on the road; the telephone dispatchers communicated with the hospitals, police or the patients. Radio operators and telephone dispatchers were performing the same function but used different technologies. In addition the radio operator acted as second in command to the sector controller. This project was an attempt to build the computer-aided dispatch (CAD) system, which would normally include call taking, resource-identification, resource mobilization, resource management and management information (Beynon-Davies). Once the call is received, the control assistants write down the details of the incident including location of a printed form and place it on the conveyor belt which brings all the forms to a central collecting point. The resource allocator studies the form and decides which resource to be mobilized. The status information of the forms is updated regularly from information received via the radio recorder. The resource is recorded and the original form passed on to the dispatcher. The dispatcher then either telephones the nearest ambulance station or passes mobilization instructions to the radio operator if an ambulance is already mobile in that sector. The purpose of the LAS was to automate many human functions in the above procedure. It was built as an event-based system using a rule-based approach in interaction with a geographical information system (GIS). The GIS communicated with Datatrak’s automatic vehicle tracking system. The system ran on a series of network PCs and file servers supplied by Apricot. On the night of 26th October 1992 things started to go wrong at the LAS headquarters. It was estimated that about 999 calls swamped the operators’ screens and many reported calls were being wiped off (Beynon-Davies, 1999). This led to a mass of automatic alerts that the calls to ambulance had not been acknowledged. It is believed that 20-30 people may have died due to late arrival of the ambulance. Ambulances were taking over 3 hours against the government recommended of 17 minutes. Minor problems could be managed by the staff but the as the number of ambulance incidents increased, the amount of incorrect vehicle information recorded by the system increase. The system started making incorrect allocations on the basis of the information received. The increased volume of calls, too few takers of calls, slow system all together caused further delays in responding to calls and incidents. Due to the work pressure and disturbance, the crew might have not pressed the right button to display the current status. Crew frustration also contributed to greater volume of voice radio traffic. There was radio communications bottleneck, which slowed down the communications and added to crew frustration. The system was caught in a vicious circle of cause and effect. A reorganization of the sector desk during the previous week may have added to the loss of local knowledge. TERMINAL 5 PROGRAM Heathrow is the world’s busiest airport and according to British Airport Authority (BAA), Heathrow Airport will handle 87 million passengers a year by 2015 if it continues to operate within its existing limits and thereafter 90-95 million passengers a year (SEEDA, 2005). BAA also forecasts an increase in cargo from 1.36 million tons to 1.8 tons by 2015. The T5 construction at Heathrow Airport is currently one of the largest construction sites in Europe. The construction started in September 2002 and the terminal is scheduled to open in 2008. The T5 site covers 260ha and entails an investment of £4.2 billion. It will take 37 million-person hours to complete the project (IEMA, n.d.). This required two rivers - the Duke of Northumberland River and the Longford River – to be diverted from their original alignment through the middle of the site. This diversion also involved the realignment of the live carriageway. The construction requires the movement of 6.5 million cubic meters of earth. The project includes the main terminal, two satellite terminals, and an air traffic control tower, apart from connections to public transport, road works, rails, and tunnels. REASONS FOR SUCCESS/FAILURE There were a large number of contributing factors that surrounded the LAS failure. The very factor that caused the failure of the LAS is responsible for the success of T5 program. Risk analysis was completely ignored for the LAS while BAA’s sustainability focus is on understanding risk and planning responses to these (BITC, 2006). T5 adopted an integrated team approach (Mottmac) while LAS project was primarily handled by the contract analyst with assistance from the systems manager (Beynon-Davies). The new system would impact the way the staff carried out their jobs but the ambulance crew was not consulted. T5 has created an environment where innovation and inspiration lead to novel solutions resulting in new levels of efficiency. T5 project team consults with external experts for advice and to challenge its approach. It also conducts regular meetings with the regulators. T5 project has not even ignored the environmental impact and environmentally preferable options have been specified. The transition from manual to the automated system was done at one go for the LAS which has been attributed to one of the major reasons for failure. The ambulance crew who were handling the operations had no prior exposure to computers and was not given the appropriate training. T5 program on the other hand, witnessed no disturbance to the smooth operations at the airport. Even during the 20-month closure of the Piccadilly line between Hatton Cross and Heathrow T4, passengers were provided with regular shuttle bus services throughout (TFL, 2006). Lane & Woodman emphasize BAA adopted a long-term partnering approach with its suppliers that has enabled an integrated team including designer, manufacturer and assembler of all the primary systems. The prototypes were undertaken within fixed time scales. At LAS mounting pressure imposed tight time-scales, and hasty selection was made for the lowest bidder without taking into consideration of the IS practices like testing, quality assurance, project management, user and stakeholder involvement (Goulielmos). This resulted in problems even before the system was delivered. Flexibility, so essential to the success of any project was ignored. Contract was granted to the lowest bidder at LAS without taking into account the performance credentials and past experience in delivering such projects. Systems Options, the company supplying the major portion of the software, is reported as having no prior experience of building dispatch systems for ambulance services (Beynon-Davies). An open tender was floated where most suppliers raised concern over the time allotted for supplying the system but they were informed that it was non-negotiable. System Options scored on the price tag as well as the delivery schedule. There is no evidence of key questions being asked by the selection team or raising concerns why System Options were significantly lower than others and how they could deliver the system when all others disagreed to do so. This implies that the tenders were not evaluated properly. The representative in charge of supplies had no technical expertise in information technology. A contractor and an unsuitably qualified systems manager were given the charge to procure an extremely complex and high-risk computer system. Reports suggest that System Options had substantially underbid an established supplier and they were put under pressure to deliver the system quickly. Evidence also suggests that a competing software house sent several memoranda to LAS management describing the project as ‘totally and fatally flawed’. The systems requirements specification (SRS) contains a high degree of precision but certain areas were not defined. There were no details of relationship with the communications interface. Links between communication, logging and dispatching via a GIS were meant to be automated. BAA on the other hand, adopted the Last Responsible Moment (LRM) which provided maximum flexibility without compromising on costs (Lane & Woodman). Information flows between systems and the dates were established by working backwards for end dates for each major system of the project. Information is required before activity can be started and each activity produces information once it is completed. This concept was totally overlooked in the case of the LAS project as the board members were misled about the key supplier. The top management at LAS was defensive when discrepancies about the tender were pointed out and they justified that things would be sorted out once the system was in place. Understanding, tracking and controlling flow of information is critical to any project. Sufficient time has to be allocated to achieve the right output. Risk factors enable to understand sustainability (Demaid & Quintas). The stakeholders in the T5 project were allowed to seek different solutions as they explored the divergent and convergent aspects of their views. At LAS, neither the suppliers’ voice against the time frame for supplies was heard, nor was the ambulance crew provided any motivation to operate and run the system efficiently. At T5, it was an integrated approach with shared values, where they started rethinking together. LAS exhibited organizational decline. There was cohesiveness amongst the partners in the T5 project whereas the workforce at LAS was demoralized; there was an environment of mistrust and a polarization between management and staff. They regarded computerization as the only chance for turnaround, grossly overestimating the ability of the organization to integrate IT system (Goulielmos, 2003). They were under pressure to achieve national response targets and improve cost efficiency. Leadership was accused at LAS of shaping a culture that lead to fear of failure and of pressure for success. IMPORTANCE OF INFORMATION SYSTEM The technology used was the latest at LAS but it failed to deliver the service required. The end result was that the technical factors had very little do with the IS failure. It was basically a failure of the organization which was not able to execute any major project successfully. There were too many problematic situations and no problem could be viewed in isolation. The organization lacked a perspective for addressing these organizational issues influencing the development issues. The computer system did not fail in the technical sense because it did what it had been designed to do. The design had fatal flaws which led to the failure of the system. Reasons cited for failure were: 1. A report by Anderson Consulting that the project called for more finance and timescales was ignored by the project managers. 2. The LAS board was misled by the project team about the credentials of System Options. 3. The project management was inadequate. It did not use the PRINCE project management method as prescribed for public sector projects. 4. The software was incomplete and unstable. The emergency backup system was untested. 5. The training was inconsistent and incomplete. Staff morale was low because they had no prior experience of using computers. LEARNING OUTCOMES The prime reason for the failure of the LAS was imposition of a solution without investigating the problem. Part of the failure also 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. 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. An integrated team approach with shared values can turn the situation. Results should not be expected overnight. IT projects cannot be implemented under pressure. It has to be constantly tested at each stage, which means a systematic transition is advisable. The top-level management is policy maker but the implementation should be left to the second-level management. Performance and experience have to be considered while awarding contracts. CONCLUSION The success or failure of a project depends upon long-term vision, flexibility, risk analysis, the ability to cope with changes, motivated personnel wiling to accept change, and the right process at the right pace at the right time. 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. The CAD system was an over ambitious project and was developed and implemented against an impossible timetable. References: Beynon-Davies, P (1999), Human error and information systems failure: the case of the London ambulance service computer-aided despatch system project, Interacting with Computers 11 (1999) 699–720 Blandford, A Wong, B L Connell, I & Green, T (2002), Multiple Viewpoints On Computer Supported Team Work: A Case Study On Ambulance Dispatch, People and Computers XVI: Proc. HCI’02. 139-156. Springer BITC (2006), BAA - Sustainability at Heathrow Terminal 5, 06 Nov 2006 Demaid, A & Quintas, P (2005), Sustainability and the Designer; Knowledge across Cultures in the Construction Industry, For Sustainable Urban Environments: Vision into Action. Birmingham, 2005. Goulielmos, M (2003), Outlining organizational failure in information systes development, Disaster Prevention and Management, Vol. 12 No. 4 pp. 319-327 IEMA (n.d.), BAA – Sustainable Construction at Terminal 5, < http://www.iema.net/download/library/casestudy/BAA%20%20Sustainable%20Construct ion%20Terminal%205/BAA%20%20Sustainable%20Construction%20Terminal%205.pd f.< 06 Nov 2006 Lane, R & Woodman, G (n.d.), “WICKED PROBLEMS, RIGHTEOUS SOLUTIONS” BACK TO THE FUTURE ON LARGE COMPLEX PROJECTS, Mottmac (2006), Heathrow Terminal 5, UK, 06 Nov 2006 SEEDA (2005), Heathrow Airport Master Plan Consultation, < http://www.seeda.co.uk/About_SEEDA/Board_Members/Board_Meetings/papers/Sept20 05/Item7-He athrowAirportSept05.doc.> 06 Nov 2006 TFL (2006), Tube one step closer for Heathrow Terminal 5, 06 Nov 2006 Read More