COMP3470 IS33 PeopleCentred Information Systems Development

1
COMP3470 IS33 People-Centred Information Systems
Development
School of Computing FACULTY OF Engineering

• Week 1 Lecture 2
• IS Failure Case Studies

2
Is this you?

• A Software Engineers approach to correcting
  systems failure ? http//www.sei.cmu.edu/cbs/monog
  raphs/case.study.correcting.pdf

Good! But can you do more?
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 groups expectations

Source Lyytinen Hirschheim (1987), IS Failures
- A Survey and Classification of the Empirical
Literature, Oxford Surveys in IT, Vol 4,
pp.257-309
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
5
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
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.171-184
• Report of the Inquiry into the London Ambulance
  Service (Feb 1993), access via http//www.cs.ucl.a
  c.uk/staff/A.Finkelstein/las.html

7
The old way

• Read pp.176/177 of Beynon-Davies paper on the
  manual ambulance despatch system
• Error-prone and inefficient .need
  computerisation!

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

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

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