This paper will analyze one of the very most prominent computerized system failures in the past 10 years- the failing of the London Ambulance Service Computer Aided Dispatch system-hereafter referred to as LASCAD. Unlike the common one dimensional explanations for system inability that view Information systems as mainly a natural technical artifact ( Klein and Hirscheim, 1987), this newspaper will attempt to explore the more multi-faceted characteristics of systems inability which is nearer to the reality that system can be found in. This analysis will be anchored in the principles of holism and emergent properties as explained by Francis and Roland Bee (2005), Taking care of Information and Information, 2005, whereby the methodology taken to evaluation emphasizes the machine relationships and processes and results of its relationships. References will be produced to existing frameworks used to research system failure in particular the Sauer model Sauer (1993). Details of the information of the system and the failure will be attracted mainly from a paper on Information System failure and risk Evaluation by Paul Beynon Davis (Computer studies technological report University of Glamorgan, 1994b). Out of this investigation existing ways of preventing or solving software systems failure will be explored in the context of the LASCAD system to consider tips and lessons learned to avoid such failures. This will particularly focus on risk controlling as suggested by B. W Boehm ( 1991) and the Goal Question Metrics by Solingen and E. Berghout (1999).
The LASCAD system was a computer aided ambulance dispatch system established at the head quarters of the London Ambulance Service. Relating to Web page et al (1993), the expected functions of the system are referred to below:
Call taking: Approval of telephone calls and event details
Resource Id: Particularly which ambulance to send to the incident
Resource Mobilization: Communicating details of an incident to the correct ambulance
Resource Management: The setting of suitably equipped and staffed vehicles to minimize response times
Management Information: This calls for the collation information to determine performance, reference management and planning.
This system was likely to solve the issues related to manual dispatch systems including time consuming and error vulnerable identification of the complete event location, paperwork and maintenance of current vehicle position information.
The LASCAD system goal was to automate these manual real human intensive jobs by using an situations centered and ruled based way and integrating a Geographical Information System (GIS) to provide location details. In this technique the callers, occurrence and patient details would be registered and transmitted to the dispatchers. Through the use of radio alerts and GIS the machine can determine the ambulance nearest to the individual. After dispatch the ambulance team was likely to acknowledge the dispatch meaning and the machine would then identify if the ambulance was headed in the right direction. Finally the system would warn the controller on the ambulances appearance to the world, hospital so when it becomes free again.
Figure1: LASCAD circulation chart (Paul Beynon Davis, 1994)
This reason of prospects of the systems efficiency is rather linear and even simplistic but on closer assessment one is able to construe the complexities that are involved in delivering such anticipations. This will become more noticeable in the following section highlighting the machine failure and down the road the events resulting in the failing.
Between 26th and 27th October 1992 (Paul Beynon Davis, 1994), the system started to are unsuccessful. It had been reported that therefore of a overflow of emergency calls bogged down the machine and this resulted in erratic behavior of the machine involving cell phone calls being wiped off the display screen and automatic alerts indicating unacknowledged cell phone calls to ambulances.
According to the Guardian publication, 1992, it was stated that 20-30 people may have lost their lives scheduled to ambulance delays. Indeed the impact of this failure was incredible and needlessly to say triggered various reactions in regards to what was the cause of the failure. Corresponding to Donaldson and Jenkins (2000) in their newspaper on System Failures: An Approach to understanding what can go wrong, the sources of system failing are sophisticated and interact with the other person and occasionally a single factor may select the challenge while in others a mixture of many small and seemingly insignificant factors are to blame. This only says that it's difficult to investigate causes of systems inability which would only be strongly known through multi cause evaluation stemming from the smooth systems methodology. It also becomes clear that everything is not always as it seems, an example is the Arriane V rocket (ESA Press release Nr 33-96-July 1996) which failed courtesy of its navigation software being improper for the rockets design. This is not actually a software inability as might have been though in the outset but a difficulty with the entire incorrect assemblage of the rocket. Since it were the program performed to its specs. This is akin to expectation failure which Lyytinen and Hirscheim (1987) describe as the inability of an IS system to meet specific stakeholder communities expectations, they symbolize a space between an existing situation and a desired situation for members of a specific stakeholder group.
This is further enhanced by Donaldson and Jenkins (2000) system failure analysis describing high open public expectancy of computer technology, Fashion/reputation of systems obscuring its basic goals and the differing stakeholder hobbies creating different perceptions of the system.
Following these outline of the system failing and prelude of expected troubles in studying system failure this section will attempt to shed detailed insight into the failure. The analysis will follow Sauers model (Sauer, 1993), of looking into system inability which is dependant on a triangle of dependencies between:
The multi-faceted aspect of systems failing alluded to in the release means that even this triangle is not a shut down system but is influenced by other contextual factors of which regarding to Sauer consists of cognitive limits-(e. g. limitations of communication), technological process-( constraints from organised character of computerized systems or development strategy), environment-(constraints by customers, suppliers, competitors, regulators), Politics, inner project structure and history associated with earlier information system assignments.
In light of the LASCAD task failure the job group from inception is very hoping. Firstly carrying out a public inquiry survey on the failure (Webpage et al, 1993), it is claimed that the London Ambulance Service (LAS) management put price before quality and committed to an over ambitious task timetable. This is evidenced by the selection of a dealer who does not have any experience in building ambulance dispatch systems but acquired significantly underbid a far more established supplier. This was compounded by the management placing the dealer under huge pressure to provide the machine quickly.
Secondly the project management team did not follow the PRINCE (Assignments in Controlled Surroundings) project management method recommended for open public sector tasks.
Thirdly it was discovered that the machine was imperfect and unstable and particularly the emergency backup system was untested. This is further compounded by inconsistent and incomplete user training.
In conditions of the information system dimension the statement of the public inquiry (Page et al, 1993) suggests that the failure had not been a result of technological issues since on overall the system have what it was made to do. It goes further to make clear that at the onset the loads on the system were light and the control staff could easily deal with various issues associated with ambulance crews pressing incorrect buttons, radio black areas, communication hand-shaking problems etc. When these occurrences increased inappropriate vehicle location and position information received by the controllers also increased resulting in the failure to cope with the load leading to fewer resources to allocate to incidents and subsequent delays in response times.
As identified by Paul Beynon Davis (1995), followers/stakeholders thought as people showing a pool of principles that define the particular desirable top features of an information system and how they must be obtained. The stakeholders have different views and expectations of the machine of which such a mismatch in perceptions in this case added to the failing. This is depicted below:
The London Ambulance Service (LAS) management viewed the system as a way to improve service to patients by putting in place mechanisms that could ensure objective and impartial tool mobilization through automation. The LAS management was also inspired by a past experience involving a failed computerized dispatch system task and pressure from organization-wide restructuring that put them under enormous pressure to succeed
Control room staff:
The personnel in the control room found the machine to be too complicated and didn't trust the motives in back of applying a computerized system
The ambulance crews were convenient with the air call systems that they had been used to and did not have confidence in the new system as they didn't see the need for it and found it too complicated
The personnel union found that there have been no essential consultations done prior to making the decision to obtain the system and as such the already strained marriage between management and personnel was worsened.
Hardware and software suppliers:
The system suppliers were not sure how to put into action the system in the first place which was compounded by limited deadlines from what they thought to be a disorganized client.
Related to these perspectives are contextual factors relating to political environment thanks to the overarching influence of the Country wide Health Service (NHS) on the London Ambulance Service which is the LAS oversight body (Beynon-Davis 1994). The NHS is seen as a the lack of a unitary power structure and comprises of a network of different health organizations. The implication on a fresh information system is an extremely careful politics balance in the impact the impact the machine will have on the romantic relationships in this network (Checkland and Scholes, 1990).
As posit by page et al, (1993), the LASCAD job was greatly affected by interior tensions in within the NHS which got commissioned major reforms in the London Ambulance Service including restructuring that resulted in the reduction of middle management from 263 to 53. It is clear that this resulted in strained connections and an environment of mistrust and obtrusiveness when it came up to any changes, which influenced the LASCAD task.
So far what's clear is the multifaceted nature of the failure that results from various causes of the failing that is common in computerized information systems, which Paul Beynon-Davis identify as web-like in dynamics. It's been reported that 92% of all system failures engaged failures of technological conversation with cognitive /organizational factors (Mackenzie, 1994).
This as it were it is essential to trace the real causes of the system failure. One way of doing this is through multi cause diagrams as stated in the section above or Petri nets which use talk about and event focused graphs.
The LASCAD project failing is depicted below by using a multi cause diagram to explore the occurrences and claims on why the failure occurred:
As indicated above using Sauers model (Sauer, 1993) of looking into system failing, the dependencies between the project organization, information system and its supporters have come out very plainly. Using the information system dimension the failure is not related to technical issues in any way, which should go against common place failing attribution of computerized information systems. This begs the question, what takes its system failure? Lyytinen and Hirschein (1987) categorize system failure into four:
Correspondence failing: There's a disjoint between your design objectives of the system and what's practically being achieved by the system.
Process inability: That is characterized by runaway jobs that either do not provide a workable system or overrun finances and time.
Interaction failing: This targets utilization of the system i. e. a highly utilized system is considered a success and one that is rarely used is failing.
Expectation failure: As mentioned earlier this is the inability of the machine to meet a specific stakeholder groups objectives. The LASCAD system falls into this category as it appears it didn't meet various stakeholder group expectations. Donaldson and Jenkins (2000) talk about a 3 dimensional picture in which a system totally fails, partly fails or temporarily goes down.
In the situation of LASCAD it is considered as a partial failure caused by a number of flaws that are rectifiable and therefore this is not a total failure.
The rectification will mainly involve a reassessment of the complete job taking mainly concentrating on the role of risk assessment. Risk is the likelihood of a negative final result. Negative end result is in essence a relative concept as Wilcocks and Margetts (1994) suggest the chance of a negative result only becomes a salient problem when the results is pertinent to stakeholder concerns and hobbies. Different options and stakeholders will dsicover different effects as salient.
The proposed platform to use in risk examination practices Wilcocks and Margetts (1994) who put across the pursuing categories to be used in studying the development, benefits and use of information systems, these are:
History: Past activities with information system development.
Outer framework: The surroundings where the organization is working e. g. economy, markets, government
Inner context: The characteristics of the organization e. g. composition, strategy
Content: For instance task size and difficulty
Processes: For example task management and staffing
Outcomes: Planned and expected results.
The proposed risk assessment platform would be implemented through the development, release and use of information systems. This will be used to complement an overarching software management methodology including the Goal Question Metrics (GQM) stated in the benefits and the Capability Maturity Model which outline good techniques in task management to ensure project success. In the context of LASCAD the GQM will particularly address these failure characteristics in the evaluation section through the next phases in development:
Setting specific goals in light of goal perspective and environment
Refine goals into quantifiable easy to understand questions
Derive requisite metrics and data to answer the questions
There are various methods that can be used in preventing or handling computerized system inability the ability maturity model and Goal Question Metrics mentioned above are in no way exhaustive nor are they prescriptive. Organizations are different contextually and specific projects also change in proportions and complexity and therefore would require methods the methodologies to be customized and scaled for specific organizations and tasks. THE ABILITY Maturity model is a leading example that targets improvement in software functions toward a specific target- maturity level that the business is working toward.
On the other palm there may be need to put emphasis on risk management beyond the main one dimensional complex orientation to encompass the complexities of computerized systems as seen through the zoom lens of Wilcocks and Margetts (1994) risk management platform.
The LASCAD system is a good example that portrays the truth of the sophisticated and multi-faceted dynamics of systems failing. The various perspectives of the system and congruent expectations make even the explanation of the failure unclear. This specific case outlined the politics and social factors behind the failing, what has been described as contextual factors. Sources to various frameworks have been made in the analysis of the failing -Lyytinen and Hirscheim (1987), especially expectation failure and dependencies in the 3 dimensional Sauers model (Sauer, 1993). The failing research provided the distillation of the machine failing characteristics which illustrate the true causes of the failure. This is done using wealthy pictures to support differing perceptions and expectations and multi cause diagrams to explore the various causes of the failure.
Lessons learnt and future remediation of systems failing is devoted to risk management and job methodologies making sure good practice in the development, advantages and use of information systems. As advised in this paper these should consider contextual/ organizational issues aside from technical aspects of the system.