Investigating an Instance of Information Technology Systems - Assignment Example

INVESTIGATING AN INSTANCE OF IT SYSTEMS PROJECT FAILURE By Name Course Instructor Institution City/State Date Question 1: How to characterise the failure of the CAD system project in terms of two IT systems failure taxonomies Correspondence failure Based on taxonomy one, Computer-Aided Despatch (CAD) system project endured correspondence failure, which occurs when a project fails to meet its predefined business objectives lay down by top management. Essentially, CAD system primary objective was to computerize numerous of the human-intensive procedures entailed in the manual despatch system. According to Davies (1996), the second live trials phase of LASCAD 1992 was perched because the system users did not have confidence in the system leading to the Nation Union of Public Employees to interfere. Furthermore, until 26 October 1992, the computerized system struggled to gratify its objectives causing ambulances to be programmed incompetently and the system was at last turned off in the subsequent two days (Davies, 1996, p.177). Consequently, LASCAD system was invented to resolve the issues associated with manual dispatch systems as well as lingering and fault prone recognition of the accurate occurrence location, formalities, and maintenance of present vehicle condition information, but it failed tremendously. Davies (1996) argues that the fact that LASCAD system failed to fulfil its primary objective such as automating manual human exhaustive tasks through events established and ruled established approach and connecting a Geographical Information System (GIS) to offer location details; thus, the system endured a correspondence failure. According to Davies (1996), the aspect that the project had, over-determined schedule led to the LASCAD failure in 1992 since major opinionated pressures carried them, and they failed to adopt extreme cautious approach prior to overtly allowing for a novel computer system. In addition, the developers failed to identify key issues that could create challenges during the development and overreacted with a comparatively strained timetable. Process Failure CAD system also endured a process failure, which is a failure attributed by substandard development functionality and occurs when the IS development process fails to generate a practical system or the generated IS system runs over stipulated budget. According to Landry (2009), process failure occurred on the night of 26th October 1992 when an inundation of 999 calls evidently mired operators’ screens and that lots of recorded calls were wiped off leading to generation of automatic alerts in high volume, which demonstrated that calls made to ambulances had not been approved. In essence, the operators had unable to handle the messages that the system was generating and were incapable to clear the queues that generated (Landry, 2009, p.169). Evidently, these queues decelerated the system and progressively more when ambulances finished a task they were yet to be cleared. Consequently, the system had diminutive resources to assign, which ultimately made the system to go through what reference attributed as a ‘ferocious circle of basis and influence’ that increasingly led to all the indications of process failure. Arguably, Landry (2009) posit that the system recognised the accurate location and significance of smaller number cars, leading to replicated and deferred allotments, development of exception messages and the pending notice list, and an augmented number of call backs and so setbacks in telephone answering. Furthermore, exception messages scrolled off the screens top making it complicated for the operators to extract them. At instance, a decision was received to wipe the exception report queue in an attempt to clear the system, but regrettably, this almost certainly had the result of producing even more exception messages (Landry, 2009, p.171). Interaction Failure CAD endured interaction failure, which is based on acceptance/use level and the extent of user satisfaction. In addition, interaction failure can take place if the enforced IT system are partially utilised or the end users discard the system due to deficient satisfaction reasons. Fitzgerald and Russo (2005) recognize four features in context of the 1992 staff/stakeholders that could have led into interaction failure: management distrust, low self-esteem, lack of system ownership, and an anti-computer predisposition. In 1992, the then chief executive desired to push through computerization hastily, in one go. Essentially, the file and rank of the company did not support him in his effort to inflict what was viewed as a hi-tech resolution to a wider set of managerial challenges and that was excellent pact of mistrust. According to Fitzgerald and Russo (2005), the setting of management distrust was somewhat the consequence of earlier history and especially a previous pay row, wherein the London based branch had stood firm in opposition to a state accord with relations amid the workforce and administration being deprived tremendously. Additionally, there were claims that 20 to 30 people had died because of ambulance arriving late; this to some extent reduced the public trust on the novel service making most of them prefer the traditional manual method (Fitzgerald & Russo, 2005, p.246). Development failure Fundamentally, CAD failure started at the development stage (development failure), which is a failure that occurs due to the stakeholders lack of ability to select appropriate technology, assign enough resources to the project, solve their existing differences, or organisational politics. Essentially, contractor issues that were recognized in 1992 are believed to have the main reason behind development failure (Beynon-Davies, 1995, p.171). Furthermore, it was felt that there existed some deceptive from LAS administration concerning their developers knowledge and perplexity over the responsibility of the key contractor and auxiliaries in the project. Some of the internal factors that could have resulted to development failure include deprived NHS and work relations setting, and lack of a tactical concept for the organisation. Other factors include the violent tempo of transformation, the lack of LAS investment, 'fear of failure' on the administration part, and the presumption that transformation in operational practices could routinely be attained thorough utilisation of information technology (Beynon-Davies, 1995, p.179). Moreover, an enormous deal of the LASCAD project shape was decided by the in-house tensions in the NHS'. Beynon-Davies (1995) posits that the then regime was trying to restructure the NHS to make it more competent and effectual with the launching of NHS Trusts and the prologue of more market-directed procurer and vendor relations. Beynon-Davies (1995) believes that these modifications were extremely litigious and viewed by some as a risk to the NHS subsistence. In essence, the NHS unions aggressively resisted these alterations and it had a harmful consequence in terms of confidence within LAS, leading to lack of support for the CAD project and an aversion towards administration (Beynon-Davies, 1995, p.181). Use Failure To some extent, CAD project endure use failure, which is a failure that occurs during working stage or when the stakeholder fail to expect in advance the unpleasant outcomes of the IT system project to the client’s work performance. Unluckily, in November 1992 CAD, was unsuccessful in printing out calls and immediately after these LAS went back to manual, paper established system, with voice or handset ambulance mobilisation (Finkelstein & Dowell, 1996, p.3). Fortunately, no solemn corollaries were reported as this took place in the early hours of the daybreak. Yet, it was an additional gust to the stressed LAS. In working terms, LAS was back officially to where it was before the 1992 system, that is manual operation by means of paper and pen. This continued to all intents and purposes until the prologue of the novel CAD system in 1996 though a number of setting alterations were being introduced. According to Finkelstein and Dowell (1996), the manual system seemed to be functioning practically well, undeniably it was reported in the Guardian newspaper almost one year after the fall down of the CAD system that the manual service was attaining its highest-ever reaction times courtesy of the modest pen and paper. Arguably, though some training had occurred, it was believed to have been too premature and by the time the system had been enforced the acquired skills had been forgotten (Finkelstein & Dowell, 1996, p.4). Taxonomy Type Does it apply to CAD Brief explanation Taxonomy 1 correspondence failure Yes the computerized system struggled to gratify its objectives comparatively strained timetable users did not have confidence in the system process failure Yes lots of recorded calls were wiped off operators were unable to handle the generated messages the system had diminutive resources to assign, interaction failure Yes Management distrust and low self-esteem Lack of system ownership and anti-computer predisposition Taxonomy 2 development failure Yes Contractor Issues lack of a tactical concept for the organisation use failure Yes LAS went back to manual, paper established system Lack of training Q 2a) four major factors that could have significantly contributed to the failure of the project Factor 1: Technical Issues During the time of LASCAD trial in a semi-manual method for three distinct divisions of the city, where operator were permitted to countermand diverse system decisions, a diversity of issues was detected. These entailed the failure to notice replicated calls, prioritise messages and stop them from scrolling off the screens, faults in allotting software resources, lockups and dawdling reaction times. According to Hougham (1996), the system was technically unique and sophisticated; the connections amid communication logging dispatching through the Geographical Information System (GIS) were intended to be automated. Initially, when the system was implemented loads were light; employees could handle with the errors, but when the teams started pressing incorrect buttons, the load heightened and staffs were in no position to cope (Hougham, 1996, p.105). In essence, augment in errors exhibited that the CAD system: made inaccurate allotments, had diminutive ambulance resources to allot, and place calls failed to pursue the right channel on a waiting list. In addition, the produced exception messages for occurrences it had received inaccurate status data. Arguably, Hougham (1996) posit that this increased the challenge and led to workers being incapable of clearing the queues, they started being slower, off screen scrolling of the messages, which became lost. Furthermore, the time for allocating resources increased, ambulance teams started irritated compelling them to start pushing the incorrect buttons and taking the erroneous vehicle. Based on the steady outcomes, the CAD system had diminutive information concerning the vehicles location and status, had unproductive and duplicated allotment of vehicles to calls, and a mounting messages backlogs pending for actions (Beynon-Davies, 1995, p.179). Factor 2: Poor Management According to Beynon-Davies (1999), management's insufficient connection with workforce and trade unions, minimal workforce participation and apathetic attitudes towards impending change, low training quality, system recognition, inspiration, and control are the absent fundamental factors that led to system failure. In essence, reforms in high management level such as Chief Executive (CE), Director of Human Resources, operation, and Finance was a further drastic change that contributed anxiety and agitation in the midst of employees (Fitzgerald & Russo, 2005, p.247). Furthermore, diminution of fifth employees with most of them being more knowledgeable led to entire change and lack of knowledge in LSA. Landry (2009) posit that in LAS performance levels were deprived, self-esteem was all-time low, top level personnel’s were changing, egotistical, and management technique was infuriating and insulting. Moreover, over dedication by the directors and fear of failure permitted occasions to pursue the path they were. The far-reaching change the “quantum leap” enforcement of novel technology from manual to entirely computer-established system characterizes over ambitiousness. According to Avgeriou et al. (2011), there was visibly an extreme profound fundamental distrust of administration in LAS and this had to be altered before any effort to bring in novel computer system. In essence, the management failed to construct bridges with the staff and display commitment. Furthermore, the management failed to take into account the fundamental element of preparing the project before working on it. This project according to reference was started with little care and no effort was dedicated to connecting the employees in the development of the project (Avgeriou et al., 2011, p.103). Factor 3: Human Issues According to Beynon-Davies (1999), the human factors facets entailed that employee who had diminutive or no confidence in the system and lacked training in the system operation. Essentially, there existed some uncertainty over the precision of the Automatic Vehicle Location System (AVLS) and employees, both within the ambulance crews and Central Ambulance Control (CAC) and, had no confidence in the system and none was trained fully. Wastell and Newman (1996) posit that the physical alterations to the design of the control room on 26 October 1992 indicated that all CAC employees were operating in unusual positions. With not paper support, and were unable to work with co-workers with whom they had in cooperation resolved issues before. Besides, there had been no effort made to predict completely the impact of imprecise or curtailed information accessible to the system that is behind schedule vehicle locations or status reporting. These flaws led to an augment in the exception messages amount that were yet to be dealt with and which as a result would lead to more enquiries and call-backs. Based on Systems Options, McGrath (2002) argues that the organisation providing the key element of the software for the system had no earlier experience of developing dispatch systems for ambulance based services. During the meeting based on vendors covering queries on the full requirement and solving other possible technological and contractual problems, it is clear that most of the vendors were worried over planned timetable, but they were all told that the timetable was preset (Beynon-Davies, 1999, p.711). Factor 4: Environment Issues Landry (2009) recognizes some of the environment factors that led to the 1992 failure and they include poor relationship environment between NHS and staff, the reduced tactical organization vision for the organisation and the hostile rate of change within the organisation. McGrath (2002) posits that changes that were taking place in NHS were extremely litigious and dangerous to its own existence. Initially, the NHS unions had enthusiastically opposed these modifications, which had an unfavourable impact to the staff morale within LAS. As result, the CAD project lacked support and there was hostility towards the top management. Furthermore, the poor trade affairs of the 1992 development were, as a minimum, still extremely awful during the following years. The verity that in general there was no IT liability in the LASCAD1992 has been emphasized as an environmental factor by Fitzgerald and Russo (2005), and probably if there had been such a purpose, there might have been several IT plan, controls, or sets, prepared that might have assisted excellently the 1992 development. Yet, such an entire IT liability in the NHS was not in place by 1992 and the novel system was developed devoid of the advantages that such a liability might have offered. In essence, this appears to indicate that whereas an entire NHS IT responsibility might have been supportive it was not an essential condition for the management (Fitzgerald & Russo, 2005, p.251). Factors Type of influence on CAD Brief explanations Remarks/My observations Technical Issues) very strong The failure to notice replicated calls Failure to prioritise messages and stop them from scrolling off the screens Augment in errors exhibited that the CAD system: made inaccurate allotments, had diminutive ambulance resources to allot, and place calls failed to pursue the right channel on a waiting list. Poor Management Strong Insufficient connection with workforce and trade unions Minimal workforce participation Top level personnel’s were changing, egotistical, and management technique was infuriating and insulting Human Issues Moderate Staff lacked lacked training in the system operation CAC employees were operating in unusual positions. With not paper support, and were unable to work with co-workers with whom they had in cooperation resolved issues before Environment Issues Weak The hostile rate of change within the organisation poor relationship environment between NHS and staff and the reduced tactical organization vision for the organisation Q 2b) Recommendation Recommendation 1 First, the management should select the team members correctly since the purchased system projects are triumphant when the organisation has chosen a product and a vendor that can fulfil the organisation’s present and future system requirement. Furthermore, the correct business executives, clients, and IS experts should be a fraction of the project team to make sure that the excellent package is procured from the top-rated vendor and that both industrial and business threats have been sufficiently well thought-out. Second, management should enhance the selection process, which can be achieved undertaking advanced research based on the vendor’s abilities. Fitzgerald and Russo (2005) believes that this will help to reduce vendors based on the issues endured by other users of the package, to determine insufficient record of accomplishment or organisation size of the vendor, or other interests concerning durable feasibility. Recommendation 2 Third, management should refine prerequisite specifications, which is aimed at overcoming the issue where the team lacked involvement by IS experts or end users that is essential in the system development. Other factors that management should take into account include making appropriate timetable and a backup replica, concentrating on the references from outside-based agencies such as consulting services, and evaluating project risks earlier (Avgeriou et al., 2011, p.121). Recommendation one 1 Management should select the team members correctly Management should enhance the selection process Recommendation 2 Making appropriate timetable and a backup replica Concentrating on the references from outside-based agencies such as consulting services Evaluating project risks earlier References Avgeriou, P., Grundy, J. & Hall, J.G., 2011. Relating software requirements and architectures. New York: Springer. Beynon-Davies, P., 1995. Information systems "failure": The case of the London Ambulance Service's Computer Aided Despatch project. European Journal of Information Systems, vol. 4, no. 3, pp. 171-84. Beynon-Davies, P., 1999. Human error and information systems failure: the case of the London ambulance service computer-aided despatch system project. Interacting with Computers, vol. 11, no. 6, pp. 699-720. Davies, P.B., 1996. IS failure: the case of London Ambulance Service’s CAD project. European Journal of Information Systems, vol. 4, no. pp. 174-84. Finkelstein, A. & Dowell, J., 1996. A comedy of errors: the London Ambulance Service case study. In In Proceedings Eighth International Workshop on Software Specification & Design IWSSD-8. Washington DC, 1996. IEEE CS Press. Fitzgerald, G. & Russo, N.L., 2005. The turnaround of the London Ambulance Service Computer-Aided Despatch system (LASCAD). European Journal of Information Systems, vol. 14, no. 3, pp. 244–57. Hougham, M., 1996. London Ambulance Service computer-aided despatch system. International Journal of Project Management, vol. 14, no. 2, pp. 103-10. Landry, J.R., 2009. Analyzing the London ambulance service's computer aided despatch (LASCAD) failure as a case of administrative evil. In SIGMIS CPR '09 Proceedings of the special interest group on management information system's 47th annual conference on Computer personnel research. New York. ACM. McGrath, K., 2002. The Golden Circle: a way of arguing and acting about technology in the London Ambulance Service. European Journal of Information Systems, vol. 11, pp.251–56. Wastell, D. & Newman, M., 1996. Information systems design, stress and organisational change in the Ambulance Services, A Tale of Two Cities. Accounting, Management & Information Technology, vol. 6, no. 4, pp. 283–99. Read More