London ambulance system academic essay assignment -

UNIVERSITY NAME

London Ambulance Service

[Type the document subtitle]

Your Name

9/28/2009

Top Grade Papers GET YOUR WORK DONE BY www.TopGradePapers.com

GET YOUR WORK DONE BY www.TopGradePapers.com

This paper is about the failure of a well known case of London Ambulance Service. It

is divided into two parts. The first part of the paper characterizes the type of

LASCAD project failure in light of the IT projects failure taxonomies. While the

second part, attempts to explore the deficiencies related to the nine areas of PMBOK

and how they contributed to the project failure.

The high failure rate for the IT projects is a world-wide phenomenon. Reasons for

failure have been attributed to technological difficulties, organizational and functional

problems, managerial issues, and many other reasons i.e. they could be process-

related, people-related or technical problems. One of the most extensive studies that

were deployed to study the root causes for IT project failure was conducted by group

of researches. Some software can be so large that thorough testing can be almost

impossible and so bugs in the software can go unnoticed (Panchamb, 1997). It was

conducted in three different settings in Hong Kong, Finland and United States. The

experts identified a list of 53 IT project risk factors initially. The most common

factors are:

Senior Management is not committed

Project team lacks required skills and knowledge

Incorrect methodology of project management

Inappropriate use of project management skills

Introduction of new technology

Changing scope and objectives

Not managing change properly

Traditionally, a project should deliver agreed upon functionality on time and within

estimated budget according to Keider (1974) and Saleh (2005). A study conducted by

Standish Group International in 1995, which included several thousands of IT project

revealed that only 16% of those projects were finished on time, and within the

estimated budget; 32% were terminated before they were completed, while the

remaining 52% involved costs higher than the original estimates and were completed

behind their schedule (Paul Beynon-Davies, 1999).



The case on hand is about the London Ambulance Service (LAS) who implemented a

computer-assisted dispatch system (LASCAD) to replace its manual dispatch systems

to improve its emergency response times. The system was built using a rule-based

approach in dealings with a geographical information system (GIS). It was built by a

small software house named as Systems Options using their own GIS software

running under Microsoft Windows (CAD Failure LAS, 1992).

It was developed by a small software house called Systems Options at a cost of

£937,463. The scope of the project included receiving calls, allocating ambulances on

the basis of available resources and monitoring the status of the requests. Some nine

days after implementation, the system recorded erroneous vehicle information caused

in part by crew pressing the wrong button. Incorrect vehicle allocations resulted.

Patients became frustrated with the delays and started making calls which were

already stored in the system. With increasing call volume and accumulating messages

awaiting action, the LASCAD was deluged and eventually came to an end. The media

which reported that 20 to 30 may have died as a result of the delay in ambulances'

arrival eventually led to the resignation of LAS chief executive. LASCAD was retired

and the original manual system was reinstated. It took another four years before a new

LASCAD system was implemented.

After reading the case of LASCAD, it revealed several factors that contributed to the

project failure. It is evident that the project failure was a mixture of people-related,

process related and technical problems. People-related because of inexperience

developer, process-related because of aggressive project's schedule and some

technical problems were also evident from the research.



Deficiencies related PMBOK Areas

Project Integration Management

It ensures that the project is properly planned, executed, and controlled, including the

exercise of formal project change control. As the term implies, every activity must be

coordinated or integrated with every other one in order to achieve the desired project

outcomes (John M.Nicholas, 2006).

The planning team of the project included Support Services Director, Project

Manager, contractor and the Services Manager. The planning process included the

several areas of LAS but they didn’t consider the ambulance crew. This wasn’t a wise

step because; the design of the system would directly affect them in any case.

This also shows that integration of the activities was not up to the mark. The deadlines

were not met since the initiation which shows a lack of control over the activities of

the project.

Project Scope Management

Changes to project scope are often the factors that “kill” a project. It includes

authorizing the job, developing a scope statement that will define the boundaries of

the project, subdividing the work into manageable components with deliverables,

verifying that the amount of work planned has been achieved, and specifying scope

change control procedures (John M.Nicholas, 2006).

The scope of the project included receiving calls, allocating ambulances on the basis

of available resources and monitoring the status of the requests. The system also

needed to be integrated with a number of other systems.

The necessities for the integration of these systems with the CAD software, did not

specify, the appropriate detail, for the accomplishment of this task. The team defined

the scope by investigating the systems that were employed by smaller ambulance



services. It is hard to understand why they did not investigate the ambulance services

of other large cities. Moreover, there were no formal change control procedures and

changes were made without any formal documentation. Project Time Management

Time management implies personal efforts to manage one’s time. For projects, it

refers to developing a schedule that can be met, then controlling work to ensure that

this happens. It is also referred as scheduling (John M.Nicholas, 2006).

Since from the beginning, the project's schedule was too aggressive. Warnings by

Anderson Consulting in late 1990 that the project needed a longer timescales were

completely ignored.

The project began with the process of contracting suppliers. The respondents were

supposed to send a copy of System Requirements Specification (SRS) with an

aggressive and non-negotiable deadline. The contract was awarded to System

Options.

After that, Systems Options (SO) initiated its working on a comprehensive System

Design Specification It took two months to complete the design specification. And

only six months were allocated for the implementation of the CAD software. As a

result, the project deadlines were not met. An official announcement was also made

by the project team and it was decided that the project will be implemented in phases.

Keeping in mind the breadth of the LAS, this schedule was too aggressive.

Project Cost Management

Cost management involves the cost resources, including people, equipments,

materials, and such things as travel and other support details. After this done, costs are

budgeted and tracked to keep the project within that budget.

The appropriate cost estimates are very crucial factor in the success of any project. T

he first step was to select a supplier. The contract was awarded to System Options at a



cost of £937,463. The System Options bid was lowest and they were awarded with the

contract without any further investigation.

Project Quality Management

Quality management included both quality assurance (planning to meet quality

requirements) and quality control (steps taken to monitor results to see if they

conform to requirements).

One of the common causes of a project failure is that quality is compromised or

sacrificed so that a tight deadline can be met. It is not very helpful to complete a

project on time, only to discover that the thing delivered won’t work properly. Same

goes with story of LAS.

IT projects like LASCAD, demands the quality which depends on the supplier’s

experience and skills. Keeping in mind, the scope of the project, it should be awarded

to a large and more experienced supplier. But the contract was awarded to System

Options that lacked both the experience and the resources.

For effective quality assurance, there must be a team which is not only independent

but also have the power to change anything to meet the quality standards. But

unfortunately, System Options assigned only assigned one part time personnel who

was responsible for the entire quality standards.

Project Human Resource Management

Managing human resources is often overlooked in projects. It involves identifying the

people needed to do the job, defining their roles, responsibilities, and reporting

relationships, acquiring those people, and then managing them as the project is

executed. PMBOK mentions that these skills are necessary, but does not attempt to

document them. Given that these are the most important skills that a project manager

must have, PMBOK is deficient in omitting them (John M.Nicholas, 2006).



As already explained, the contractor selected for the project was small software house

without any past experience in developing these kinds of systems. Furthermore, there

was only one person responsible for the quality assurance and more importantly he

was not independent of the developing team.

As a result, System options delayed the delivery of softwares on continual basis, and

whatever they deliver was not without any defects.

The users of the system were not properly trained. Even after the LASCAD had been

implemented, users were unable to use the system properly and committed mistakes

that ultimately led to its crash. This shows the people selected for the job were not

adequate and not much experienced for the handling of the job at hand.

Project Communications Management

It involves planning, executing, and controlling the acquisition and spreading of all

information relevant to the needs of all project stakeholders. This information would

include project status, activities, actions, that may affect other stakeholders or the

project.

As a first mistake, the project team excluded the ambulance crew, one of the

stakeholders of the project in the planning process. They should be included since

they are the people who would be most affected by the design of the system. The

design of the system adopted the operational working system and this kind of system

alter the duties of ambulance crew and the staff of call centres.These people were

again not taken into confidence before developing this kind of system.

The reasons mentioned above explain the fact that information was not properly

disseminated to the stakeholders of the project.

Project Risk Management



It is the process of identifying and quantifying and taking action to project risks. It

includes maximizing the chances of positive events while minimizing the chances of

adverse events to project goals. This is an extremely important aspect of project

management that sometimes is overlooked by novice project managers (John

M.Nicholas, 2006).

The project was too risky in the sense that human lives were at stake. Despite this

fact, throughout LASCAD development, the emergency backup system was untested.

Contractor without any prior experience, no quality standards, and no full time team

for the project, changes without any formal revision and review process and most

importantly inexperience project manger are the some errors which shows the poor

risk management for the project.

Project Procurement Management

Procurement of necessary goods and services for the project is the logistics aspect of

managing a job. It involves deciding what must be procured, issuing requests for bids

or quotations, selecting vendors, administering contracts, and closing them when the

job is finished (John M.Nicholas, 2006).

Procurement began with the process of contracting suppliers. However, contract was

awarded to the lowest bidder without taking into account the capabilities of the

bidder. As already explained, System Options was not a correct choice.This explains

why their bid was so low than other competitors. This shows that the procurement

process was faulty from the beginning.

References



John M.Nicholas (2006), “Project Management for Business and Technology

Principles and Practice”, Chapter 1.

Paul Beynon-Davies (1999), “Human error and information systems failure:

the case of the London ambulance service computer-aided dispatch system

project”, University of Glam organ, Pontypridd CF37 1DL, Mid-Glam organ,

Wales, UK.

Panchamb (1997), Why Software Systems Fail." Planet Papers.

Retrieved at September 25, 2009, Retrieved from:

http://www.planetpapers.com/Assets/1931.php

"CAD Failure LAS” (1992). Retrieved at: Sepetember 26, 2009. Retrieved

from: http://www.lond.ambulance.freeuk.com/cad.html



http://www.planetpapers.com/Assets/1931.php

http://www.lond.ambulance.freeuk.com/cad.html