Transcript General

LASCAD
Human Factors in System Design
A Case study by P Beynon-Davis
HFSD Case Study
Introduction
• LASCAD was one of the most important IS failures in
recent years
• BBC reported that up to 30 lives lost
• Widespread media attention
• ‘Moral panic’ re IS systems
• Systems designers ability & professionalism
questioned
• Sytems design method questioned
• LAS Chief resigned few days after the event
Public Inquiry into the system
• 80 page report published Feb 1993
• Reasons for failure complex - Social Technical
Environmental and Political factors all present
Background to need for CAD system
• Many Problems related to manual systems
• Most relate to the time consuming and error prone
nature of activities such as:– Identification of the precise location of an incident
– The physical movement of paper forms
– Maintaining up to date vehicle status information
– Communicating with vehicle crews
– Identifying duplicate calls
• CAD system seen by many as a means of overcoming
these problems and improving service
Requirements of the CAD system
• Call Taking - acceptance verification & location of
incident
• Resource Identification - Which ambulance?
• Resource mobilisation - communicate incident details
to ambulance
• Resource management - positioning of resources to
minimise response times
• Management information - monitor & assess
performance & HR planning
The System
• BT route calls to LASHQ in Waterloo
• 18 HQ ‘receivers’ collect and record incident details name location etc
• Information transmitted over LAN to an ‘allocator’
• System pinpoints location on a map display
• System expected to monitor location of ambulances
every 13 secs
• Nearest ambulance is then determined
The System (Cont)
• Dispatcher provided with details of nearest three
chooses one
• Selection relayed to crew via vdu on dash - crew
confirm response
• System monitors and alerts controllers if ambulance
is going in the wrong direction
The System (Cont)
•
•
•
•
Built as an event based system
Used GIS technology
Developed by small software house
Used their own GIS software running under
Windows
• The GIS communicated with Datatrack’s AVT system
• Ran on series of networked PC’s and file servers (Apricots)
The Event
• Flood of calls 2900 v 2300 normal
• Operators screens swamped
• Many calls ‘wiped’ from screen before being dealt
with
• Resulted in mass of automatic alerts being generated
to indicate that calls were not being dealt with
• Some ambulances were taking over 3 hrs to respond
to the call
• Re-organisation of sector desks the previous
weekend may have also contributed
The WEB and Sauers model of IS failures
• Benyon-Davis from extensive analysis of the
LASCAD concludes that IS failure is due to a WEB of
complex inter- relationships
• Therefore difficult to provide simple answers to IS
failures
• Sauers model portrays IS failures around 3
components
– the project organisation
– the information system
– the projects supporters
The WEB and Sauers model of IS failures
(cont)
• Arranged in a triangle of dependencies
• Triangle is not a closed system
• Contextual factors also play a part
– Eg Cognitive limits the environment politics
history etc..
The Project Organisation
• Systems Options the Software House had no
previous experience of developing CAD systems
• LAS had previously scrapped a 7.5 million BT system
in 1990 due to faulty software
• SO substantially underbid an established supplier
• Strong political pressure to deliver quickly to time
and budget
• Live trials in March 1992 were stopped following
union claims of fatal delays
Report Findings
• LAS ignored overambitious project
• Procurement document put price before quality
• Report by Anderson Consulting in 1990 asking for
more time & money was surpressed
• LAS Board misled over experience of SO
• Confusion also over who was the project leader SO or
Apricot
• PM was inadequate - SO did not use the PRINCE
method as prescribed for PS projects
• The software was incomplete and unstable
• Participation was very poor
Technical Issues
• Technically complex & unique
• Links between communication logging and
dispatching via the GIS were meant to be automated
• When first implemented loads were light
• Staff could cope with errors - crews pressing wrong
buttons!
• As load increased staff were unable to cope
Technical Issues (Cont)
• Increase in errors meant that the system:– made incorrect allocations
– had fewer ambulance resources to allocate
– place calls that had not gone through the correct
procedure on a waiting list
– generated exception messages for incidents it had
received incorrect status information
Technical Issues (Cont)
• This compounded the problem and led to :– staff being unable to clear the queues
– the system getting slower
– messages scrolling off screen & being lost
– increase in time to allocate resources
– ambulance crews being frustrated resulting in
» pushing the wrong buttons
» taking the wrong vehicle
The People
• Two major stakeholder groups
– LAS Management & HQ & Ambulance services
staff
• Each group had its own perspective
• LAS Management - control and efficiency
• HQ Staff - Unnecessary interference in decision
making
• Ambulance Staff - Lack of trust in the technology
The Environment - NHS
• No unitary power structure
• Complex network of power relations among different
players
• No agreed strategic vision for exploitation & control
of IT
• Piecemeal development
– Region emphasise management & administrative
systems
– Hospitals & GP’s emphasise clinical applications
– District emphasise operational & administrative
applications
The Environment LAS
•
•
•
•
History of labour and industrial relations problems
Rationalisation of LAS management
Pressure for management to succeed
Internal tensions due to pace of change & NHS
reforms
• Climate of mistrust & obstructiveness
• Underestimation by management of process of
change
IR at LAS
• Protracted conflict between:– Management Unions & Government
– Evidence that management failed to modernise
the service
– Lack of investment in the workforce
» training
» career advancement
IR at LAS
• End of 1990 after long dispute LAS was in need of
major change
• Jan-April 1991 reduction in senior and midmanagement posts (268 - 53)
• Little evidence of consultation with workforce over
restructuring
• Led to anxiety and mistrust
• Enquiry team believed system was viewed by
management as means of:– overcoming outmoded practices - crews or stations decided
– gaining control
– increasing efficiency
IR at LAS
• Management naive in thinking that:– implementation of the system would change
working practices
• Crews and stations employed range of strategies to
resist changes including:– failing to mobilise
– sending a different resource
– failing to acknowledge or report status
Conclusion
• Failure was due to a complex mix of factors
• Participation alone is not sufficient but helps!
• Expectation of failure plays a part
– does not meet the needs of the stakeholders
• Systems should strive to meet the shared goals &
needs of the different stakeholders
Further Reading
• Benyon-Davis P 1994(a) Information Management in
the British NHS Int Journal of IM
• Benyon-Davis P 1994(b) The LASCAD A case study
(Course handout)
• Sauer C Why Information Systems Fail A case study
approach. Alfred waller Henley on Thames