London Ambulance Services (LAS) In a state of Emergency

ANAG THE DIGITAL FIRM
November 2, 2014
Prepared By:
Andrew Considine | Fegbada Jude
Monzer Alshaikh warak| Paul Ong
Under supervision of Dr. Kamna Malik
London Ambulance Services (LAS)
In a state of Emergency
ACTION LEARNING PROJECT
Enterprise Systems Development

1
LondonAmbulanceServices(LAS)InastateofEmergency|11/2/2014
Contents
INTRODUCTION ......................................................................2
THE PROBLEMS RELATED TO REQUIREMENTS THAT PREVENTED THE SUCCESSFUL
ROLLOUT OF THE LAS SYSTEM .....................................................2
LESSONS LEARNED FROM “LONDON AMBULANCE SERVICES PROJECT” ......4
CONCLUSION .........................................................................7
REFERENCES...........................................................................7
APPENDIX 1: LEADING CHANGE: WHY TRANSFORMATION EFFORTS FAIL .8

2
Introduction
The London Ambulance Service's (LAS) decision to migrate from a highly manual
and inefficient dispatch system in the early 1990s to an automated Computer Aided
Dispatch (CAD) system was a critical decision for a service facing increasing issues
related to legacy systems and manual processes. From the beginning of the project
major issues were evident with the LAS
ignoring best practice and qualified industry
advice in the development of both it's
requirements and overall objectives and the
selection of it's supplier to build, deliver and
launch the CAD system.
This paper will outline some of the key issues
involved in the project including:
 The development and definition of the CAD project’s requirements
 Additional issues arising both prior to project launch and throughout the
lifecycle of the project
We will then conclude with our recommendations on process for the LAS, or a
similar organization, should follow with a technology project such as the CAD
project.
The problems related to requirements that prevented the
successful rollout of the LAS system
The problems related to the successful rollout of the CAD system by the LAS were
many and varied as clearly shown in the associated case study. We believe that these
can be broken down in to four main areas:
 Requirements
A clear lack of a deep and thorough investigation of the end-to-end
requirements of all stakeholders of the project.
 Planning
An unrealistic expectation on implementation timeframes and project deadlines.

3
 Resources & Capability
A lack of clarity in regards to the Project "Owner" (Project Manager) and clear
gaps in skillsets on both the supplier and client side.
 Execution
A haphazard approach to system updates, testing and infrastructure preparation.
One of the most consistently blamed factors for system development project failures,
despite years of research on the subject, is poorly defined or investigated
requirements (Verner & Cerpa, 2005). Going one step further project failure can
usually be traced back to the practice and techniques used to gather requirements
and a lack of end-user involvement and understanding (Gahi & Kaur, 2012).
We’d argue that this was one of the key factors in the failure of the CAD Project.
The case study demonstrates that the key stakeholders from the LAS involved in
defining the CAD Project and evaluating responding suppliers proposals did not
have relevant and in-depth experience in running major software development
programmes. This led to unrealistic expectations on deliverables and outcomes –
even to the point of ignoring expert advice from the industry.
Though on the surface the LAS appeared to have a relatively clear vision of the
functionality they desired there were multiple gaps in the end-to-end evaluation of
the requirements including:
 With the systems requiring 100% precision there was a lack of clear definition
of requirements across each LAS department involved and not enough analysis
of "what-if" scenarios like user error, incorrect data, malicious activity and
network failure.
 The scope of the project was large and complex and thus would require a stable,
scalable and performing network infrastructure. Very little thought was given in
the requirements gathering process to the LAS network's ability to handle the
additional load of the new systems at idle let alone peak volume periods.
 There was no business case or analysis of costs of each requirement at each
stage of the project thus there was no prioritization or phasing of the
requirements not a justification decision made for each. This led to the situation
where the LAS (and their poorly equipped vendor) were trying to develop a
supersized project as opposed to a phased project, which would potentially have
made the development process simpler and achievable.

4
A more detailed, and end to end analysis coupled with a best practice approach to
the requirement gathering (such as provided by the Prince2 Methodology for project
management - identified as a clear skill gap in the LAS and vendor teams) would
have led to better project planning, including requirements gathering, and potentially
a more successful outcome for the project.
Lessons learned from “London Ambulance Services project”
In this section we cover additional lessons learned from the LAS’ CAD project in
regards to the planning of large and mission critical information system
projects.
1. Pricing, while important from a budgetary perspective, should not be the sole
factor in the selection of a supplier.
2. A clear process should be defined and executed for reference checking short-
listed suppliers.
3. NFRs (Non-Functional Requirements) should be considered early in the
development process.
4. A project should not be launched until all stakeholders are across the
requirements and scope of the project with clear sign off and agreement of the
objectives and outcomes.
5. Checkpoints should be defined throughout the lifetime of the project and all
work should be carefully documented to capture issues, success metrics and
learnings.
6. Project stakeholders, especially the overall Project Manager(s) should be
agreed on prior to Project launch.
7. An agreed Project Governance Framework should be
agreed on and followed throughout the Project (i.e.
PRINCE/PRINCE 2).
8. A Change management Plan must be enacted and
followed in a Project with multiple stakeholders and
impacted parties.
9. If the skills are not available internally the
engagement of a 3rd
party consulting firm or expert

5
should be considered to run an independent audit of the Project requirements,
vendor selection and Project delivery.
10.Project deliverables should be based on a well executed Analysis & Design
process (PRINCE2) and not on arbitrary orders from management or a “wish
list” from individual stakeholders.
11.A Project’s critical success factors & acceptance criteria should be defined
and agreed early.
12.A phased approach to large scale Projects is advisable as this will lead to
management development and implementation cycles along with structured
testing of each “drop” of a SW system.
Actions that organizations should take to avoid the kind of
pitfalls faced in the case of LAS
The issues that plagued the LAS were many and we have covered them in detail in
points 1 and 2 above. The issues can be broadly classified into four main areas:
1. People
2. Systems
3. Processes
4. Governance
Many of the issues were project management related and although the PRINCE
Project Management Methodology was selected, the team had little or no experience
of applying the framework. In light of this, organizations are well advised to pay
serious attention to their project management capabilities when embarking on
significant projects.
Organizations would also benefit if they have SDLCs in place. “Software life cycle
models describe phases of the software cycle and the order in which those phases are
executed. Each phase produces deliverables required by the next phase in the life
cycle. Requirements are translated into design. Code is produced according to the
design which is called development phase. After coding and development the testing
verifies the deliverable of the implementation phase against requirements.”

6
There are following six phases in every Software development lifecycle model:
1. Requirement gathering and analysis
2. Design
3. Implementation or coding
4. Testing
5. Deployment
6. Maintenance
By following SDLC, organizations minimize the chances of something going awry.
There are laid out plans, activities, tasks, processes and work parcels in each step of
the SDLC. The SDLC should also cover the project governance structure e.g.
Project steering committee including a Project director, Project sponsor, project
manager and working teams. The governance will lay out the ground rules as to how
the project and the project team will function. Roles, responsibilities, deliverables
and accountabilities are clearly identified so that every person is aware of their role
in the Project. To prevent a recurrence errors that occured in the LAS case, the
SDLC should be administered by the PMO. Organizations should also consider
having a separate PMs for IT and Business respectively and these two PMs could
work together and support and complement each other within the project.
Transformation is about changing the status quo. With this in mind, another key
takeaway for organizations from the LAS case is that in any major transformation, it
is imperative to win the hearts and minds of all stakeholders when trying to induce
behavioral changes. Kotter (2007) in his seminal research on transformation posited
that most change initiatives fail miserably as managers do not realize that
transformation is a process and not an event. The transformation process is a series
of 8 steps that build on each other and this entire process takes time. There are no
short cuts and each stage needs to be played out before another stage begins.

7
Conclusion
It is clear that the LAS CAD Project was a failure and in this document we have
outlined that this was due to:
 Poorly captured and understood requirements.
 A lack of Project Management skills and clarity in terms of Project leadership,
which led to the selected Project methodology (PRINCE) being largely
ignored.
 Poor supplier selection due to a haphazard approach to Procurement process.
 A lack of planning and end view of the outcomes of the project.
 Attempting to run the Project as a single Phased events as opposed to building
it out over multiple manageable phases.
 Supplier selection based on low cost and rapid delivery with both being
identified as unrealistic expectations.
Our recommendation is that the LAS start the project again with a realistic vision on
timelines, deliverables and cost and to recruit the right professional team internally
and select a vendor with a proven track record and motivation to deliver
successfully.
References
1- Verner, J., Cox, K., Bleistein, S., Cerpa, N., 2005. Requirements engineering and software project success: An industrial
survey in Australia and the US. Australian Journal of Information Systems, vol. 13, pp. 225-238
2- Ghai, S., & Kaur, J. (2012, November, 2012). Analysis of User Requirements Gathering Practices in Agile and Non-Agile
software Development Teams. International Journal of Computer Applications, 58(8), 13-18.
3- Lawrence Chung, A Summary of Report of the Inquiry Into The London Ambulance Service
4- “What are the Software Development Life Cycle (SDLC) phases?” URL: http://istqbexamcertification.com/what-are-the-
software-development-life-cycle-sdlc-phases/ accessed 31 October 2014
5- Kotter, J.P., Leading Change: Why transformation efforts fail, Harvard Business Review, January 2007, Reprint R0701J
6- Michael McDougall, CIS 573,The Failure of the London Ambulance Service, November 16th, 1999

8
Appendix 1: Leading Change: Why Transformation Efforts
Fail
The table below shows the 8 steps prescribed by Kotter (2007) with the antecedent actions
to be taken and pitfalls to watch out for at each identified stage. Management and
organizations are well advised to take heed of Kotter’s definitive work on change.
Stage Actions Needed Pitfalls
Establish a
sense of urgency
 Examine market and competitive realities for
potential crises and untapped opportunities
 Convince at least 75% of your managers that the
status quo is more dangerous than the unknown
Underestimating the difficulty of
driving people from their comfort
zones
Becoming paralyzed by risk
Form a
powerful
guiding coalition
 Assemble a group with shared commitment and
enough power to lead the change effort
 Encourage them to work as a team outside the
normal hierarchy.
No prior experience in teamwork at
the top
Relegating team leadership to an
HR, quality, or strategic-planning
executive rather than a senior line
manager
Create a vision  Create a vision to direct the change effort.
 Develop strategies for realizing that vision.
Presenting a vision that’s too
complicated or vague to be
communicated in five minutes
Communicate
the vision
 Use every vehicle possible to communicate the
new vision and strategies for achieving it.
 Teach new behaviours by the example of the
guiding coalition.
Under communicating the vision
Behaving in ways antithetical to the
vision
Empower others
to act on the
vision
 Remove or alter systems or structures
undermining the vision.
 Encourage risk taking and non-traditional ideas,
activities, and actions.
Failing to remove powerful
individuals who resist the change
effort
Plan for and
create short-
term wins
 Define and engineer visible performance
improvements.
 Recognize and reward employees contributing to
those improvements
Leaving short-term successes up to
chance
Failing to score successes early
enough (12-24 months into the
change effort)
Consolidate
improvements
and produce
more change
 Use increased credibility from early wins to
change systems, structures, and policies
undermining the vision.
 Hire, promote, and develop employees who can
implement the vision.
 Reinvigorate the change process with new
projects and change agents
 Declaring victory too soon – with
the first performance
improvement
 Allowing resistors to convince
“troops” that the war has been
won
Institutionalize
new approaches
 Articulate connections between new behavior and
corporate success.
 Create leadership development and succession
plans consistent with the new approach.
 Not creating new social norms
and shared values consistent with
changes
 Promoting people into leadership
positions who don’t personify the
new approach

9

London Ambulance Services (LAS) In a state of Emergency

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to London Ambulance Services (LAS) In a state of Emergency

Similar to London Ambulance Services (LAS) In a state of Emergency (20)

More from Monzer Osama Alchikh WARAK

More from Monzer Osama Alchikh WARAK (19)

Recently uploaded

Recently uploaded (20)

London Ambulance Services (LAS) In a state of Emergency