1. Human Factors in System Design A Case study by P Beynon-Davis
LASCAD
Human Factors in System Design
A Case study by P Beynon-Davis
HFSD Case Study

2. 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

3. Public Inquiry into the system
80 page report published Feb 1993
Reasons for failure complex - Social Technical Environmental and Political factors all present

4. 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

5. 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

6. 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

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

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

9. 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

10. 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

11. 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..

12. 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

13. 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
Training was incomplete & inconsistent

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. IR at LAS
End of 1990 after long dispute LAS was in need of major change
Jan-April 1991 reduction in senior and mid-management posts ( )
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

22. 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

23. 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

24. 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