1 / 14

COMP3470 IS33 People-Centred Information Systems Development

School of Computing FACULTY OF Engineering. COMP3470 IS33 People-Centred Information Systems Development. Week 1 : Lecture 2 IS Failure Case Studies. Is this you?. A Software Engineer’s approach to correcting systems failure ? http://www.sei.cmu.edu/cbs/monographs/case.study.correcting.pdf.

zuzana
Download Presentation

COMP3470 IS33 People-Centred Information Systems Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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? IS33 IS Failure Cases

  3. 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 IS33 IS Failure Cases

  4. 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 IS33 IS Failure Cases

  5. 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) IS33 IS Failure Cases

  6. 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 IS33 IS Failure Cases

  7. The old way … • Read pp.176/177 of Beynon-Davies’ paper on the manual ambulance despatch system • Error-prone and inefficient ….need computerisation! IS33 IS Failure Cases

  8. 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 IS33 IS Failure Cases

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

  10. 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) IS33 IS Failure Cases

  11. 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 IS33 IS Failure Cases

  12. 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 IS33 IS Failure Cases

  13. 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/ IS33 IS Failure Cases

  14. 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 IS33 IS Failure Cases

More Related