LASCAD

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

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