Lessons from the Failure

and Subsequent Success of

a Complex Healthcare
Sector IT Project
David Greenwood, Ali Khajeh-Hosseini,
Ian Sommerville

ST ANDREWS
DEPENDABLE SYSTEMS ENGINEERING GROUP
 October 26th 1992

• Disaster Strikes!
– An attempt to automate a pre-existing manual system to
dispatch ambulances fails!

• Lives are Lost

– Estimate of 20-30 people died as ambulances arrived too
late on the scene

• Money
– LASCAD cost £20 million to develop & deploy and was
decommissioned within 10 days (26/10/92 - 4/11/92)

• Jobs
– LAS Chief Exec John Wilby resigns within 72 hours of go-live

2
 September 1996

• Success is in the air!!

– the project was turned around
– the system was delivered resulting a
60% reduction in ambulance dispatch
time

3
 The Mystery

• What happened in those 3 years and

11 months that turned a disaster into
a success story?

4
 Condensed Abstract

• “IT failures diagnosed as errors at the

technical or project management level are
often mistakenly pointing to symptoms of
failure rather than the project’s socio-
complexity which is usually the actual
source of failure.”
• Tools that enable practitioners to
systematically elicit socio-complexity
derived project risks reduce a project’s
risk of failure
5
 1.1 The Case study - LASCAD

• London Ambulance
Service
– An NHS Trust providing an
ambulance service to the whole
London area (620 sq miles)
– In 1990s involved in a
protracted pay dispute with
workers’ union
– In 1991, 268 senior
management posts in the LAS
were cut to 53
– Restructuring caused a great
deal of anxiety to employees

6
 1.2 The Case study - LASCAD

• London Ambulance
Service Computer Aided
Despatch (LASCAD)
– Is an exemplar of an IT enabled
work-transformation project
– Comprised the automation of
ambulance dispatch from call taking
to ambulance dispatch
– The need for automation was noted
in the 1980s but a first attempt
failed in 1987

7
 1.3 The Case study – LASCAD92

• A second attempt was initiated in

October 1990 and failed in October
1992 (LASCAD92)
– The planned implementation date was
Jan 92 but by March 1992 live trials of
the system were suspended due to lack
of confidence
– On 26th October 1992 the system
crashed spectacularly

8
 1.4 The Case study – The Fall out

• Following a public enquiry the project was

revitalised under new management
– Lack of disciplined technical approach
(Page, 1993) (Finklestein, Dowell, 1996)(Hougham, 1996) (Beynon-Davis, 1999)

– Poor user involvement and ownership

(Page, 1993) (Beynon-Davies 1995)(Finklestein, Dowell, 1996) (Beynon-Davis, 1999)

– Irrational persistence to continue

(Page, 1993)(Beynon-Davis, 1999)

– Lack of adequate testing

(Page, 1993)(Beynon-Davies 1995) (Finklestein, Dowell, 1996)

– Limited training
(Page, 1993)(Beynon-Davies 1995) (Finklestein, Dowell, 1996)

9
 1.5 Case study – LASCAD96

• A radically different approach was adopted

• COTS solution rejected -> in-house development
• Participative prototyping adopted
• Incremental development subject to user approval
• The consequence:
– In September 1996 the project was successfully
turned around resulting a 60% increase in
productivity

10
2. The Problematical Situation
– During an IT development project trade-offs are
made due to constraints (such as technical
limitations, time and budget) resulting in some
stakeholders benefiting/losing more than others

– As a consequence different people have

different views of how much resource a project
should be given and what/how trade offs should
be made and whether or not they will support
the project in its current form

– The complicatedness of a project can therefore

be understood in terms of
• technical complexity
• socio-complexity (human/organisational/social
complexity)
 2. The Problematical Situation

• Socio-complexity is a construct that

represents the complicatedness of
interactions between a project’s
stakeholders
• It is important as the socio-complexity of
IT projects is known to adversely affect IT
project performance in terms of scope,
time, budget and user satisfaction far
more than technical complexity

12
3. A perspective to make sense of the
mess

• A conflict perspective was adopted in order to

make the study of socio-complexity
manageable
• This means that to get a better understanding
of the phenomena, research was focused on
stakeholder interactions that comprise conflict
• This proved to be a break through as it revealed
some of the constituent parts of socio-
complexity at an actionable level of abstraction

13
3. A perspective to make sense of the
mess

Individual Intra-group Inter-group

Perceived
Injustice

Values &
Satisfaction,
Status

14
 4. A tool for practitioners to manage
the mess
Input: Tasks
• Stakeholder Impact Information
about
Analysis proposed
changes.
Assess impact
Time
of ∆

– an approach to E.g. Who,

what, how
Resources

Capabilities
identifying sources of Process:
Assess Values
socio-complexity (latent changes to
existing tasks Satisfaction

potential conflicts) and

processes to
Status

– therefore identifying predict/identif

y risks of
Multiple Roles

Justice
socio-complexity resistance/co
nflict.
Output:
derived risks Specific Specific Identified
identified risks Risks
of resistance
&opportunities
15
 5. Method

• The LASCAD case study was used to

evaluate the effectiveness of Stakeholder
Impact Analysis (SIA)
– Test 1: Do risks identified using SIA in LASCAD92 map
onto the sources of failure identified in other accounts?
• If true this provides some support that the socio-
complexity derived risks account for the symptoms
identified in other accounts
– Test 2: Were risks identified using SIA in LASCAD92 were
mitigated in the successful LASCAD96 project?
• If true this provides some support that SIA identifies
risks that adversely affect IT project performance

16
 6. Results

• Test 1
– All sources of failure identified in accounts of
the LASCAD disaster map onto identified
socio-complexity derived risks
• Test 2
– Almost all the risks identified in the failed
LASCAD 92 project were mitigated in the
successful LASCAD 96 project
17
 Why LASCAD92 went so wrong

• Source: LAS Management • Source: LAS

were fearful for their jobs if Management distrustful
they did not deliver LASCAD.
of control room staff &
• Resultant: reluctance to
report negative information ambulance crew due to
to executives previous conflict.
• Resultant: Negative
information discounted
as political
manoeuvring

Consequent: ‘an irrational persistence to continuing’

18
 Why LASCAD92 went so wrong

• Source: The system was not explicitly designed taking into

account Ambulance crews values of rapid response

• Resultant: The system did not take into account crew experience
or local knowledge

Consequent: Ambulance crew resisted the system once it was deployed

as its directives and automated selections did not match crew values.

19
 Why LASCAD92 went so wrong

• Source: The system was not explicitly designed taking into

account Control Room staff status & job satisfaction

• Resultant: Software was perceived by staff to reduce their status

& satisfaction by automating their work and removing many
elements of skill/local knowledge that existed

Consequent: Control room staff opposed the system in March 92

20
 Why LASCAD96 went so right
• Source: LAS • Source: • Source:
Management were Executives Development
given a flexible resolved pay & process required a
deadline conditions dispute sign-off from
• Resultant: no with ambulance control room staff
disincentives to crew & control prior to go live
report negative room staff • Resultant:
information to • Resultant: Negative
executives Negative feedback about
feedback taken functionality could
seriously not be ignored &
testing needed to
be convincing

Consequent: ‘a rational persistence to continuing’

21
 Summary

“IT failures diagnosed as errors at the technical or

project management level are often mistakenly
pointing to symptoms of failure rather than the
project’s socio-complexity which is usually the
actual source of failure.”

“Tools that enable practitioners to systematically

elicit socio-complexity derived project risks
reduce a project’s risk of failure”

22
Questions

23
 5. Method

• Data Collection:
– Data on the LASCAD was collected from 5 separate
sources and verified that each account broadly
corroborated one another
• Data Analysis:
– 1. Key stakeholders were identified
– 2. Changes to key stakeholders work activity were identified
– 3. The consequences of these changes were hypothesised on the stakeholder’s
time, resources, capabilities, values, status and satisfaction
– 4. These changes were interpreted within the wider context of relational factors
(e.g. tense relationships between individual & groups)
– 5. It is hypothesised whether stakeholders will perceive the change as unjust
(either procedurally or distributively) based upon nature of change and relational
context

24