David Greenwood

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


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


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


4/24

What happened in those 3 years and11 months that turned a disaster intoa success story?

The Mystery

4


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


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


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/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


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


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


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)


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


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


14/24

3. A perspective to make sense of themess

14

Individual Intra-group Inter-group

Perceived

Injustice

Values &Satisfaction,

Status


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


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


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


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


19/24


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.


20/24


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


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


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


23/24

Questions

23


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

David Greenwood

Documents

Transcript of David Greenwood