London Ambulance Service Computer Aided Dispatch System
The London Ambulance Services is a reputed firm that has been in service for a long time. Their major aim is to provide professional ambulance service especially within the city of London. As of January 1993, LAS had a staff of 2,700 serving a population of about 7 million. The firm had 800 vehicles supported by one helicopter making about 2 million journeys every year.With an income of about 70 million UK pounds, the London Ambulance Service (LAS) management saw a need to invest in information technology to streamline their services while offering them a competitive advantage. They settled for a computer-aided dispatch (CAD) system that was supposed to help streamline their service provision. The system was expected to process the primary control functions at LAS. These functions would typically include:
- Management of the strategic positioning of equipped ambulances to minimize response time whenever an emergency occurs
- Effecting communication to the targeted dispatch units as quickly as can possibly be achieved.
- Identification of the ambulances to dispatch to areas of greatest demand.
- Reception of incident calls and identification of their location
The board at LAS contracted System Options Ltd in August 1991 to initiate the project. The project was worked on by the contract analyst assisted by the systems manager who had earlier produced the specification. However, the ambulance crew was never consulted during this process. LAS during tendering indicated that the system supplier would take full responsibility for the delivery of the system. Even though from the onset System Options Ltd (SO) appeared inexperienced to handle a project of such magnitude, the board turned the responsibility to them and sanctioned that they take over and initiate the project. Soon it became apparent that the CAD dispatch system was not progressing as expected. There was no well-defined project team. The members also lacked the technical know-how on project management. Lack of a properly structured approach meant that the benefits of projects in a controlled environment (PRINCE) management methodology would not be of many benefits to the team. Further still, no clarification was available on how this management methodology would benefit the project. There was no communication plan in place even as the temporary team members remained uncommitted to meetings. The trust that senior management gave to inexperienced System Options Ltd generated a false impression as far as the health of the project was concerned. The single-sourcing policy by the board shut out competitive bidding that eventually affected the quality and delivery of the system. Inadequate testing meant that integration processes were not well addressed and flaws would soon emerge. The hurried implementation cut short any adequate user tests and maintenance which would later affect the working of the system. Seemingly, there was no experienced project manager as a role and instead was LAS contract analyst with other mid-level LAS managers who did not have prior knowledge on project management (Finkelstein, 1993).
Explicit risk identification
The following table below summarizes four explicit risks that affected this project.
Implicit risks and their assessment
The table here below summarizes other risks identified for the failed LASCAD system.
Ranking using the following assumption 1= Highest impact, 5= Lowest impact.
Conclusion and recommendation
This case study reveals some of the factors contributing to failed IT projects even today. One of the factors contributing to failed projects is the human factor (McConnell, 1997). It can be noted that this factor was the largest contributor to the failure of the LASCAD project 1992.
According to the IT project risk framework, most of the risk sources were internal. This involved the people as stakeholders within the project, which eventually affected the quality, schedule, and budget of the LASCAD project. Organizational policy where Systems Option Ltd (SO) was single-sourced to take complete responsibility for the project disregarding their experience and technical expertise was one of the factors in the genesis of the failure of this project. Research reveals that the main causes of project failure are ranked as poor communication within the project team and externally at 57%, lack of adequate project planning at 39%, and poor or inadequate quality control at 35%. Notably, externally delivered solutions’ success largely depends on the client-supplier relationship (IT Cortex, 2010). Other contributory factors include weak business cases, lack of support by the top management, poor project management, and lack of attention on human and organizational aspects of IT.
The success of any project will largely depend on established risk monitoring and control procedures (Marchewka, 2009). As in any other process, IT projects have risks that will need a well-defined risk management strategy to address the explicit and implicit risk. The most obvious impediment as far as the LASCAD project was concerned was the inability of the poorly constituted project team to understand the risk of inadequate or limited user involvement. Further still a risk assessment and management strategy that is a very vital component for any project was absent. LASCAD project would undoubtedly have succeeded had there been a well-defined risk management strategy incorporated within the project management process.
References
Finkelstein, A. (1993). Report of the Inquiry into the Ambulance Service. Web.
IT Cortex. (2010). Project failure statistics. Web.
Marchewka, J.T. (2009). Information technology project management (3rd ed.). London:Wiley & sons.
McConnell, S. (1997). Software Project Survival Guide (1st ed.). Redmond, Washington: Microsoft Press.