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

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

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 mid-management 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