Week 1 (2) 2008IS33 IS Failure Cases 1 COMP3470 IS33 People-Centred Information Systems Development...

Week 1 (2) 2008 IS33 IS Failure Cases 1

COMP3470 IS33 People-Centred Information Systems Development

Week 1 : Lecture 2IS Failure Case Studies

School of ComputingFACULTY OF Engineering

IS33 IS Failure Cases 2Week 1 (2) 2008

Is this you?

A Software Engineer’s approach to correcting systems failure ? http://www.sei.cmu.edu/cbs/monographs/case.study.correcting.pdf

Good! But can you do more?


Categories of IS failure Process Failure: no workable solution

produced &/or cost of the delivered IS over run

Correspondence Failure: design objectives not met

Interaction Failure: poor levels of user satisfaction or acceptance

Expectation Failure: the inability of an IS to meet a specific stakeholder group’s expectations

Source: Lyytinen & Hirschheim (1987), IS Failures - A Survey and Classification of the Empirical Literature, Oxford Surveys in IT, Vol 4, pp.257-309


Different degree of failures

Total Failure – system not operational Partial Failure Type 1 – Goal Failure (main

stated goals not attained) Partial Failure Type 2 – Sustainability Failure

(succeeds initially but then fails after a year or so)

Partial Failure Type 3 – Zero-Sum Failure (succeeds for one stakeholder group but fails for another)

Richard Heeks, IDPM, University of Manchester


A classic case – LASCAD project

LASCAD = London Ambulance Service’s Computer Aided Despatch

How to conduct a case study?- get the facts on what happened

(primary & secondary sources? others?)- investigate context, cause & effect- analyse using some kind of ‘framework’- lessons learned (recommendations)


Sources of information

Beynon-Davies P (1995), “ Information systems ‘failure’: the case of the London Ambulance Service’s Computer Aided Despatch project”, European Journal of Information Systems, Vol. 4 pp.171-184

Report of the Inquiry into the London Ambulance Service (Feb 1993), access via http://www.cs.ucl.ac.uk/staff/A.Finkelstein/las.html


The old way …

Read pp.176/177 of Beynon-Davies’ paper on the manual ambulance despatch system

Error-prone and inefficient ….need computerisation!


LASCAD project – what happened

Key dates Late 1990 – Feb 1991 : writing system

requirement spec 7 Feb 1991 : invitation to tender June – July 1991 : systems design spec Aug – Sept 1991 : contracts (2 suppliers) signed Jan 1992 : original planned implementation 26 Oct 1992 : full implementation (problems

started - a flood of 999 calls swamping operators’ screens – some went missing – lots of automatic alerts generated …etc.)

4 Nov 1992 : system crashed!

From the Inquiry Report


How LASCAD should work

Read Beynon-Davies’ paper p.177

(p.178 has a cause-&-effect diagram too)

So what went wrong? – p.179


Context NHS was under reform and there was

already ‘a climate of mistrust and obstructiveness’

LAS management was under pressure to improve performance and to meet standards set

Staff was alienated to the changes rather than brought on board

2 earlier unsuccessful attempts with CAD (early 80s and 1989/90)


People issues as the framework for analysis Individual – inadequate training; system assume

perfect condition at coal face; Group – change of layout in control room (the usual

peer-support lost); no fall back position; management’s hope to use the system to bring about the desired change of working practice automatically;

Organisation – both systems and users were not ready for full implementation; poor fit between system and organisational structure and operational procedure; over-ambitious scoping and timetable; the process of awarding CAD contract dubious; poor project management


Recommendations by the Inquiry Team Continue to implement a CAD Better IT procurement guidelines (more than financial

aspects) CAD should be follow these imperatives

Reliable/resilient Total ownership by management and staff Timescale which allows consultation, QA, testing and

training Staged delivery with maximum benefits first

Re-training of control room staff Establish a project subcommittee of the LAS Board

and recruit an IT Director who will have direct access to LAS Board


For next week!

Write down on a piece of paper a list of ‘people issues’ raised in this article:Dennis A R, Carte T A and Kelly G G, “Breaking the rules: success and failure in groupware-supported business process reengineering”, in Decision Support Systems, Volume 36, Issue 1 (Sept 2003), pp.31-47, Elsevier Science Publishers B.V.

Go to http://www.leeds.ac.uk/library/


Need some help in speed reading?

Workshops by Skills Centre

Effective Reading (in Oct / Nov)

Develop your writing skills

(and others….?)

More info from

http://www.skillscentre.leeds.ac.uk/workshops.php

Week 1 (2) 2008IS33 IS Failure Cases 1 COMP3470 IS33 People-Centred Information Systems Development...

Documents

Transcript of Week 1 (2) 2008IS33 IS Failure Cases 1 COMP3470 IS33 People-Centred Information Systems Development...