david greenwood
TRANSCRIPT
-
8/8/2019 David Greenwood
1/24
Lessons from the Failure
and Subsequent Success ofa Complex Healthcare
Sector IT Project
David Greenwood, Ali Khajeh-Hosseini,Ian Sommerville
ST ANDREWS
DEPENDABLE SYSTEMS ENGINEERING GROUP
-
8/8/2019 David Greenwood
2/24
Disaster Strikes! An attempt to automate a pre-existing manual system to
dispatch ambulances fails!
Lives are Lost Estimate of20-30 people died as ambulances arrived toolate 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
October 26th 1992
2
-
8/8/2019 David Greenwood
3/24
Success is in the air!!
the project was turned around
the system was delivered resulting a60% reduction in ambulance dispatchtime
September 1996
3
-
8/8/2019 David Greenwood
4/24
What happened in those 3 years and11 months that turned a disaster intoa success story?
The Mystery
4
-
8/8/2019 David Greenwood
5/24
IT failures diagnosed as errors at thetechnical or project management level areoften mistakenly pointing to symptoms of
failure rather than the projects socio-complexity which is usually the actualsource of failure.
Tools that enable practitioners tosystematically elicit socio-complexityderived project risks reduce a projectsrisk of failure
Condensed Abstract
5
-
8/8/2019 David Greenwood
6/24
London AmbulanceService An NHS Trust providing an
ambulance service to the wholeLondon area (620 sq miles)
In 1990s involved in aprotracted pay dispute withworkers union
In 1991, 268 seniormanagement posts in the LASwere cut to 53
Restructuring caused a greatdeal of anxiety to employees
1.1 The Case study - LASCAD
6
-
8/8/2019 David Greenwood
7/24
London AmbulanceService Computer AidedDespatch (LASCAD) Is an exemplar of an IT enabled
work-transformation project
Comprised the automation ofambulance dispatch from call takingto ambulance dispatch
The need for automation was notedin the 1980s but a first attemptfailed in 1987
1.2 The Case study - LASCAD
7
-
8/8/2019 David Greenwood
8/24
A second attempt was initiated inOctober 1990 and failed in October1992 (LASCAD92)
The planned implementation date wasJan 92 but by March 1992 live trials ofthe system were suspended due to lack
of confidence On 26th October 1992 the system
crashed spectacularly
1.3 The Case study LASCAD92
8
-
8/8/2019 David Greenwood
9/24
Following a public enquiry the project wasrevitalised 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)
1.4 The Case study The Fall out
9
-
8/8/2019 David Greenwood
10/24
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 successfullyturned around resulting a 60% increase inproductivity
1.5 Case study LASCAD96
10
-
8/8/2019 David Greenwood
11/24
2. The Problematical Situation
During an IT development project trade-offs aremade due to constraints (such as technicallimitations, time and budget) resulting in somestakeholders benefiting/losing more than others
As a consequence different people havedifferent views of how much resource a projectshould be given and what/how trade offs shouldbe made and whether or not they will supportthe project in its current form
The complicatedness of a project can thereforebe understood in terms of
technical complexity socio-complexity (human/organisational/social
complexity)
-
8/8/2019 David Greenwood
12/24
Socio-complexity is a construct thatrepresents the complicatedness ofinteractions between a projects
stakeholders It is important as the socio-complexity of
IT projects is known to adversely affect ITproject performance in terms ofscope,time, budget and user satisfaction farmore than technical complexity
2. The Problematical Situation
12
-
8/8/2019 David Greenwood
13/24
A conflict perspective was adopted in order tomake the study of socio-complexitymanageable
This means that to get a better understandingof the phenomena, research was focused onstakeholder 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
3. A perspective to make sense of themess
13
-
8/8/2019 David Greenwood
14/24
3. A perspective to make sense of themess
14
Individual Intra-group Inter-group
Perceived
Injustice
Values &Satisfaction,
Status
-
8/8/2019 David Greenwood
15/24
Stakeholder ImpactAnalysis
an approach to
identifying sources ofsocio-complexity (latentpotential conflicts)
therefore identifyingsocio-complexityderived risks
4. A tool for practitioners to managethe mess
15
Tasks
Assess impact
of
Resources
Capabilities
Values
Satisfaction
Status
Time
Multiple Roles
Justice
Input:
Information
about
proposed
changes.
E.g. Who,
what, how
Process:
Assess
changes to
existing tasks
and
processes to
predict/identif
y risks ofresistance/co
nflict.
Specific Identified
Risks
Output:
Specific
identified risks
of resistance
&opportunities
-
8/8/2019 David Greenwood
16/24
The LASCAD case study was used toevaluate the effectiveness of StakeholderImpact Analysis (SIA)
Test 1: Do risks identified using SIA in LASCAD92 maponto the sources of failure identified in other accounts?
If true this provides some support that the socio-complexity derived risks account for the symptomsidentified in other accounts
Test 2: Were risks identified using SIA in LASCAD92 weremitigated in the successful LASCAD96 project?
If true this provides some support that SIA identifiesrisks that adversely affect IT project performance
5. Method
16
-
8/8/2019 David Greenwood
17/24
Test 1 All sources of failure identified in accounts of
the LASCAD disaster map onto identifiedsocio-complexity derived risks
Test 2 Almost all the risks identified in the failed
LASCAD 92 project were mitigated in thesuccessful LASCAD 96 project
6. Results
17
-
8/8/2019 David Greenwood
18/24
Source: LAS Managementwere fearful for their jobs ifthey did not deliver LASCAD.
Resultant: reluctance toreport negative informationto executives
Why LASCAD92 went so wrong
18
Consequent: an irrational persistence to continuing
Source: LASManagement distrustfulof control room staff &ambulance crew due toprevious conflict.
Resultant: Negativeinformation discountedas politicalmanoeuvring
-
8/8/2019 David Greenwood
19/24
Why LASCAD92 went so wrong
19
Source: The system was not explicitly designed taking intoaccount 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.
-
8/8/2019 David Greenwood
20/24
Why LASCAD92 went so wrong
20
Source: The system was not explicitly designed taking intoaccount Control Room staff status & job satisfaction
Resultant: Software was perceived by staff to reduce their status
& satisfaction by automating their work and removing manyelements of skill/local knowledge that existed
Consequent: Control room staff opposed the system in March 92
-
8/8/2019 David Greenwood
21/24
Why LASCAD96 went so right
21
Source: LASManagement weregiven a flexibledeadline
Resultant: no
disincentives toreport negativeinformation toexecutives
Consequent: a rational persistence to continuing
Source:Executivesresolved pay &conditions disputewith ambulance
crew & controlroom staff
Resultant:Negativefeedback taken
seriously
Source:Developmentprocess required asign-off fromcontrol room staff
prior to go live Resultant:
Negativefeedback aboutfunctionality could
not be ignored &testing needed tobe convincing
-
8/8/2019 David Greenwood
22/24
IT failures diagnosed as errors at the technical orproject management level are often mistakenlypointing to symptoms of failure rather than theprojects socio-complexity which is usually theactual source of failure.
Tools that enable practitioners to systematicallyelicit socio-complexity derived project risks
reduce a projects risk of failure
Summary
22
-
8/8/2019 David Greenwood
23/24
Questions
23
-
8/8/2019 David Greenwood
24/24
Data Collection:
Data on the LASCAD was collected from 5 separatesources and verified that each account broadlycorroborated 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 stakeholderstime, 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 relationalcontext
5. Method
24