Presentation is loading. Please wait.

Presentation is loading. Please wait.

Week 1 (2) 2008IS33 IS Failure Cases 1 COMP3470 IS33 People-Centred Information Systems Development Week 1 : Lecture 2 IS Failure Case Studies School of.

Similar presentations


Presentation on theme: "Week 1 (2) 2008IS33 IS Failure Cases 1 COMP3470 IS33 People-Centred Information Systems Development Week 1 : Lecture 2 IS Failure Case Studies School of."— Presentation transcript:

1 Week 1 (2) 2008IS33 IS Failure Cases 1 COMP3470 IS33 People-Centred Information Systems Development Week 1 : Lecture 2 IS Failure Case Studies School of Computing FACULTY OF Engineering

2 IS33 IS Failure Cases2 Week 1 (2) 2008 Is this you? A Software Engineers approach to correcting systems failure ? case.study.correcting.pdf case.study.correcting.pdf Good! But can you do more?

3 IS33 IS Failure Cases3 Week 1 (2) 2008 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 groups expectations Source: Lyytinen & Hirschheim (1987), IS Failures - A Survey and Classification of the Empirical Literature, Oxford Surveys in IT, Vol 4, pp

4 IS33 IS Failure Cases4 Week 1 (2) 2008 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

5 IS33 IS Failure Cases5 Week 1 (2) 2008 A classic case – LASCAD project LASCAD = London Ambulance Services 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)

6 IS33 IS Failure Cases6 Week 1 (2) 2008 Sources of information Beynon-Davies P (1995), Information systems failure: the case of the London Ambulance Services Computer Aided Despatch project, European Journal of Information Systems, Vol. 4 pp Report of the Inquiry into the London Ambulance Service (Feb 1993), access via

7 IS33 IS Failure Cases7 Week 1 (2) 2008 The old way … Read pp.176/177 of Beynon-Davies paper on the manual ambulance despatch system Error-prone and inefficient ….need computerisation!

8 IS33 IS Failure Cases8 Week 1 (2) 2008 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

9 IS33 IS Failure Cases9 Week 1 (2) 2008 How LASCAD should work Read Beynon-Davies paper p.177 (p.178 has a cause-&-effect diagram too) So what went wrong? – p.179

10 IS33 IS Failure Cases10 Week 1 (2) 2008 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)

11 IS33 IS Failure Cases11 Week 1 (2) 2008 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; managements 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

12 IS33 IS Failure Cases12 Week 1 (2) 2008 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

13 IS33 IS Failure Cases13 Week 1 (2) 2008 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

14 IS33 IS Failure Cases14 Week 1 (2) 2008 Need some help in speed reading? Workshops by Skills Centre Effective Reading (in Oct / Nov) Develop your writing skills (and others….?) More info from


Download ppt "Week 1 (2) 2008IS33 IS Failure Cases 1 COMP3470 IS33 People-Centred Information Systems Development Week 1 : Lecture 2 IS Failure Case Studies School of."

Similar presentations


Ads by Google