The Costs and Benefits Involved in the Implementation of Management Information Systems - Essay Example

Table of Content Table of Content 1. The Theory-Application Problem 2 1 Socio-Organisational Obstacles 3 1.2 Technical Obstacles 4 2 The Good Practices Concept 5 1.2.1 Social Aspect 5 1.2.2 Organisational Aspect 7 2 LAS Technologies and System Development Techniques 9 Figure 1: Envisioned IS Communication Flow and Operation 9 2.1 Skills, Communication and Negotiation 10 3 Recommendations 11 Figure 2: Data-Flow Diagram 14        14 Source: http://www.getahead-direct.com/gwbadfd.htm 14 4 Conclusion 15 5 Bibliography 16 In an article on the costs and benefits involved in the implementation of management information systems in organisations, David G. Wastell (1999) argues that a number of technical, environmental, and organizational factors, not to mention software related ones, can mitigate against successful implementation to the extent that costs vastly outweigh, even completely negate, expected benefits (p. 581). Socio-environmental and organizational factors, in fact, have increasingly proven to be a persistent cause of IS failure. This statement, supported by reference to numerous cases of such failure, ranging from software-related air traffic control disasters to the unmitigated failure of the London Ambulance Service experience, motivates Wastell to argue for the implementation of a specific set of operational requirements before sensitive industries, institutions and organisations are allowed to implement a software automation system (pp. 581-582). While the uninformed may find Wastell’s call quite extreme, a brief overview of the relevant failure-causal factors, provide ample justification for the stated. Prior to arguing that, however, a brief statement on the obstacles involved in the translation of theory into practice must be made. In other words, despite this being a mature organisation, the relative novelty of its IS structure and the unfamiliarity of emergency teams’ with the workings of the system, itself reflecting the failure of LAS’ IS department and manger, significantly contributed to the system’s failure. 1. The Theory-Application Problem Purvis et al. (2001) affirm that while the theoretical base and design of an information system may be relatively flawless, its implementation may result in costly failure consequent to the problematic nature of translating theory into practice (pp. 117-118). In essence, an Information System, such as that designed for the London Ambulance Service, may be mechanically flawless and, within the theoretical context, its implementation should enhance the efficiency of the processes involved in the execution of certain functions (p. 119). For greater clarification, one may draw attention to the fact that, in theory, the IS designed for the LAS was supposed to enhance dispatch efficiency and minimize request-response lag time. As Finkelstein and Dowell (n.d.) explain, with data on the location of ambulance and emergency medical teams, the system was supposed to automatically dispatch the nearest ambulance and team to the location specified in any 999 call (n.p.). The implementation of the system, however, only served to highlight the vast gulf which exists between theory and practice. As Finkelstein and Dowell report, lag time was substantially increased, with multiple ambulances dispatched to a single location and none to others, with the result being systemic failure and virtual system collapse. That failure was not immediately and wholly a result of IS flaws and mechanical errors but more so an outcome of the system’s being fed incorrect information by teams, most probably being due to unfamiliarity with the workings of the system. The stated unfamiliarity, reflective of the IS department’s dereliction in articulating system operation needs and of systematically and strategically preparing and planning for it, was effectively compounded and allowed to continue unabated for a significant length of time due to the fact that the LAS did not have a regular process evaluation in place and supposedly followed a planned organisational strategy, characterised by inflexibility and inability to correctively respond to failure in a timely manner. 1.1.1 Socio-Organisational Obstacles Theory does not translate well into practice because implementation confronts a number of factors which can only be defined as obstacles to success. Among the more noteworthy of these factors are the socio-organisational ones, as Wastell (1999) maintains (p. 582). This set of factors may be explicated as resistance to change among the work force and the organisation’s failure to extend IS training to staff, thereby overcoming the root cause of resistance and enabling a smooth transition from manual task execution to task automation (p. 584). It can also be explained as the failure of the organisation to establish a mechanism for IS management, implementation control, oversight and accountability (p. 584). This particular failure is a general characteristic of organisations which follow fixed strategic plans which are not subject to monitoring and continued evaluation, as is the case with LAS. 1.1.2 Technical Obstacles In addition to the socio-organisational obstacles to successful implementation of IS, there are a number of critical technical factors which act to impede positive exploitation of the system. These technical failure, as outlined by Bentley (2002) can best be defined as design flaws and/or failure to test the system through pilot programs and implement it only when the referred to system has successfully passed testing (n.p.). Further expounding upon this, Bentley (2002) argues that design flaws, the most common type of technical failure in IS projects, are sometimes not revealed in the testing phase but come to the forefront following implementation and as a direct result of overuse or over dependence upon the system. To this extent, he argues that technical faults, at least those immediately related to design flaws, have to be offset through incremental implementation. That means, the system should be gradually implemented and its use gradually expanded so to avoid the problem of overload or, at least, be in a position to recognize at precisely which stage the system began to suffer from overload. As one may note from the above, therefore, the technical obstacles to the implementation of IS projects often emanate from lack of proper testing for design flaws, combined with hasty implementation. This is precisely what occurred in the case of the London Ambulance Service as reported by Benyon-Davies (1995). 1.2 The Good Practices Concept As one may discern from the above, the failure of IS projects, concomitant with the phenomenon of costs vastly outweighing benefits, tend to emanate from poor practice. In other words, and as Purvis et al. (2001) contend, the exercise of poor practice vis-à-vis IS project implementation is akin to a guarantee for certain failure whereas the exercise of good practices can vastly minimize costs to the extent of negating the deleterious effects of a faulty system (p. 120). In justifying the stated, Purvis et al. (2001) draw attention to the fact that the exercise of good practice embraces system testing, in which case failures would be detected prior to the operationalisation of the system (p. 121). The validity of the stated is clearly apparent in the experience of LAS for, had the system been tested prior to implantation, problems would have been detected and corrective mechanisms would have been activated prior to implementation. Consequently, to the extent that Purvis et al. (2001) claim good practices to make the difference between the successful or the failed adoption of an IS project, one has to concede to the validity of the claim. However, the question regarding the components, or characteristics of good practices, remains. The succeeding paragraphs will attempt to elaborate upon that. 1.2.1 Social Aspect From the social perspective, good practices entail a thorough consideration, as explicated by Joshi (1991) of the purpose and nature of the IS project itself (p. 229). While one may assume such a consideration to be more technical than it is social, Joshi persuasively argues otherwise, contending that some IS projects may have an inherently social dimension insofar as their implementation targets a society (p. 229). In that instance, failure and success become inherently social insofar as the consequences of either are immediately discernable through effect on the targeted society (p. 229). Here, one may state that to the extent that the LAS operates within and for a specified society, the adopted IS project has an inherently social dimension insofar as its success would have positively contributed to the welfare of that society and failure would have negatively detracted from it. Within the context of discussing an IS project which is social by nature, Joshi (1991) outlines a number of good practices which may positively contribute to success. Among these she mentions the possibility of the Human Resource Department conducting tests to evaluate the attitudes of the work force towards the adoption of a specific technology or information system and determining whether or not reactionary attitudes are a consequence of unemployment fears (that the new technology will reduce the work force consequent to the automation of certain tasks) or, possibly, an outcome of weak IT literacy pr illiteracy even (pp. 231-232). Upon gauging attitudes and their base, it is good practice top work towards the resolution of reactionary attitudes, whether through assurances against unemployment or through IT training, depending on the root cause of the reaction (p. 232). When we come to evaluate the validity of the first defined good practice (social), we discover that the experience of the LAS effectively upholds that validity. In their discussion on the failure of IS implementation in LAS, Finkelstein and Dowell (n.d.) explain that failure was largely due to the fact that the system could not accurately trace the location of ambulances and emergency teams due to having been fed incorrect information (n.p.). Incorrect information had been entered into the system by the ambulance teams either because of poor IT skills extending to an inability to enter the correct information, or deliberately in an effort to sabotage the system (n.p.). The authors were unable to identify which of these two scenarios was at the ore of the systemic failure but, in either case, had the Human Resource Department gauged attitudes and tested the work force’s ability to use the system, the consequent disastrous outcome may not have occurred. Therefore, one may affirm here that good practices entail the gauging of attitudes and the extension of system use training. Apart from the two above explained good practices, one may note that another such practice includes the execution of a pilot program designed to evaluate public interaction with, and reaction to, a technological change. In explaining this last point, Joshi (1991) states that in as far as the service sectors, especially the health care sector is concerned, there is a high level of social interaction with the service providers. If the human service providers and operators are to be replaced by software or hardware, it is only good practice to assess whether or not clients will be able to interact with the system. In fact, where the service is health care, evaluating social reactions is extremely critical insofar as social rejection of, or inability to use, the new technology will effectively seal off use to many of those in need. Consequently, Joshi (1991) argues that the new IS project should first be conducted within a limited geographical area, or a representative section of society as a means of evaluating whether or not society is able to positively interact with the system (pp. 232-236). Depending on the outcome of the pilot study, Joshi (1991) recommends that implementation proceed as is or the system be designed with a more user-friendly interface (p. 237). 1.2.2 Organisational Aspect From the organizational perspective, Wastell (1999) recommends a number of good practices and highlights them as integral to the success of an IS project (p. 583). The first among these is preparation of the organisation to acceptance of a specified change. Organisations are either receptive or resistant to change depending upon the dominant culture. Forward-looking organisations which are committed to responsiveness to the demands of the external environment tend to have a flexible culture which positively responds to change. Organisations, however, that are set in their ways and are largely disconnected from the external environment, tend to have an authoritarian culture which reacts negatively to change (pp. 585-586). Within the context of the stated, Wastell (1999) argues that good practice dictates an assessment of the organisational culture and an evaluation of its potential for accepting change. If the culture is revealed as on responsive, internal cultural reorganization and formulation should be carried out prior to the introduction of change (p. 586). In other words, organisations should not implement change or adopt an innovative IS program without first ensuring a fit with the organisational culture. In case of there being a mismatch, effort should be expended into cultural reorganisation towards reception of the defined change. In addition to the above, Wastell (1999) holds that organisations need to gauge the impact of the adopted change on stakeholders and identify the reaction of stakeholder groups to the change (p. 586). If stakeholders are opposed to the change, that opposition will mitigate against success with additional good practice defining negotiation with stakeholders for acceptance of change prerequisite to implementation (p. 586). Insofar as the LAS stakeholders are concerned, Benyon-Davies (1995) identifies them as the staff working in the emergency dispatch service section. Benyon-Davies further claims that staff morale was low and there was little acceptance of change and, in fact, attitudes against it were quite reactionary (n.p.). To this extent, good practice would have dictated resolving negative attitudes towards implementation of the IS program before implementation. However, that was not done, partially accounting for latter system-wide failure ad systemic collapse. Additional good organisational practice maintains, according to Purvis et al. (2001) that the organisation establish a mechanism for the management of the IS project. That does not simply mean establishing an IT department but assigning a team within that department as responsible for the implementation, overseeing and control of the IS program. Not only that, but that team has to be held accountable for failure and rewarded for success (p. 123). In other words, accountability and responsibility for implementation and program success are good practices and these practices, as one may note were completely overlooked by the LAS. 2 LAS Technologies and System Development Techniques Theoretically speaking, and as one may discern from the analysis forwarded by Finkelstein and Dowell (n.d.), in the post-system implementation phase, everything that could gave gone wrong with the IS program, went wrong. This should not have happened as, despite the ambitious aims of the IS program, the task requirements were relatively straightforward and simple. The system was required to keep track of the location of the LAS’ numerous ambulance and emergency teams, log 999 calls and dispatch the teams closest to a particular location to emergency rescue and aid (n.d.). Figure 1: Envisioned IS Communication Flow and Operation However, efficient system functioning was predicated on the assumption that the various teams would accurately log on their location information and would inform the system of their response to a emergency dispatch (n.d.) However, teams did not do so and as a result response time was unacceptably delayed and the system bordered on complete collapse (n.p.). At the same time, and as Benyon-Davies (1995) adds the system revealed itself incapable of dealing with excessive pressure and responded to such pressure by wiping unresponded to 999 calls from the screen so that some emergencies were actually dropped from consideration (n.p.). The failure of the IS program implementation in LAS, which culminated in the death of one or two patients, was unwarranted. Had good practices been implemented or, had system development proceeded with practical application, as opposed to untested theory, in mind, the cost of implementation would not have been so excessive. In essence, the technologies required by the LAS were hardly complex but were extremely sensitive. It is due to such sensitivity that development should have proceeded through pilot testing phases, as stated by Bentley (2002) and not implemented, as is, without any form of testing. The failure to implement good practices in the design and execution phases was at the root of unjustifiable systemic failure, according to Bentley (2002). 2.1 Skills, Communication and Negotiation The failure of the IS project in the London Ambulance Service case communicates a number of lessons on the importance of communication, negotiation and skill development. In the first place, and as may be inferred from Benyon-Davies (1995), the development and pre-development phase were faulty, insofar as they did not proceed along the guidelines established for positive client and team communication and negotiation. As Benyon-Davies (1995) writes, the LAS ever fully investigated the system development team’s references and abilities with the end result being that the system development team misrepresented itself and effectively took on responsibility for a project that they could not handle (n.p.). Secondly, and as also may be understood from Benyon-Davies’ (1995) discussion, there was poor communication, whereby the project development team was forced to complete the IS within an unrealistic time frame with the consequence being that there was no time for testing. In addition to the stated, and as pertains to the LAS, on may infer from Finkelstein and Dowell (n.d.) that there was an extremely poor level of communication between emergency response team and 999 clients, culminating in non-response to emergency calls. This is partially traceable to the poor IS skills exhibited by the teams whereby few could actually input their correct location information into the system or record their response to an emergency call (n.p.). As one may deduce from the stated, part from mechanical and design flaws, systemic collapse was further consequent to low levels of communication and skills. 3 Recommendations One of the primary reasons for the failure of the LAS experiment is that the work system had not been properly scrutinized, evaluated and understood. In an attempt to overcome this rather glaring shortcoming, and prior to the development and implementation of an improved IS program for the London Ambulance Service, I would undertake, and recommend to others, a thorough analysis of the work system. Personally speaking, I believe that the most suitable follow-up IS project here would be a system which performs the functions that the earlier one had been envisioned as doing, with the primary difference being that the follow-up system will deliver the vision of increased efficiency and will significantly reduce the request-response time lag in order that such a system may evolve a study of the work system framework is essential. As explained by Barki et al. (1988), the work system is comprised of six elements, organized in pyramidical form. At the top of the pyramid is the customers element, followed by products and services then, the business processes. Occupying the base are the participants, information and technology. These elements, or components, their arrangement and the manner in which they are linked, and their modes of operation, are the core of what is referred to as the work system’s architecture, referencing the organization of information within the parameters of the referred to system. This architecture, referring to the manner by which a system operates, is often confused with the concept of work system performance, referring to how well the system operates. These two, however, are distinct despite the fact that the elements and subelements of the architecture furnish the variables used to evaluate performance (pp. 300-301). Although the importance of evaluating performance through an analysis of the performance variables related to the work system framework’s elements, goes without saying, a brief elaboration is necessary. Basically, each element of the work system is comprised of a number of performance variables, outlined below (gathered from information presented by Barki et al., pp. 301-303): 1) Customer * customer satisfaction 2) Products and Services * cost * quality * responsiveness * reliability * the degree of conformance to established standards and regulations 3) Business Process * Activity Rate * Output Rate * Consistency * Productivity * Cycle Time * Downtime * Security 4) Participants * Skills * Involvement * Commitment * Job Satisfaction 5) Information * Quality * Accessibility * Presentation * Security 6) Technology * Functional Capabilities * Degree of user friendliness * Ownership Cost * Compatibility While the overall evaluation of system performance is integral to any effort designed to improve performance, Brki et al. (1988) emphasize that it is important to evaluate each of the above stated performance variables independently as change in any single one, inclusive of improvement, may not necessary lead to improved overall results. In other words, it is necessary to look at the separate parts, measure each performance variables independently, and then construct the larger picture (p. 312). Such a method enables greater comprehension of why a work system is performing at its current level and what may be done to induce improvement. If the organisation independently measures performance variables, the organization in question will be in a position to better formulate strategic plan for improvement of the work system in general, addressing the problem of high quality and high reliability at high cost, leading to customer dissatisfaction. The importance of describing the business process at different levels of detail, according to Banker and Kauffman (1991), lies in the fact that doing so is integral to the acquisition of a better understanding of the process and formulating an effective strategy for improvement. The importance of the stated, one might add, is highlighted by the significance of the business process itself, representing, as it does, the transformation of inputs into outputs (pp. 380-381). As we cite DFDs as one method by which the business process is described at different levels of detail, and explicate upon this through a brief review of the constituents of such diagrams, the referred to importance will be better clarified. Figure 2: Data-Flow Diagram        Source: http://www.getahead-direct.com/gwbadfd.htm Within the framework of data flow diagrams and the extent to which they can be manipulated to represent the business process in varying degrees of detail, we note that context diagrams function to clarify the scope of the system. Following from this, the processes are identified, as explicated by Banker and Kauffman (1991). The range of details is expanded via the breakdown of the referred to processes into subprocesses. Apart from the fact that this enables the inclusion of more detailed descriptions of the business process, the fact is that such details are an integral component in the creation of a better comprehension of the system, offering guidance as to what an information system need do in various situations (pp. 385-386). The point is that the diagrams mentioned are endowed with a flexibility that allows for the incremental expansion of details in a clear hierarchical fashion. These details, and varying levels of detail, are of intrinsic importance to both managers and users, who do need to comprehend how processes function in an organizational context. The failure to acquire such an understanding, negatively impacts the attempts to improve the system, understanding its shortcomings, or to construct a new information system. In other words, the ability to describe the business process at different levels of detail is important insofar as these details offer a more comprehensive understanding of a present system, outlining strengths and weaknesses, and serving as a guideline for the construction of a new system. 4 Conclusion If I were to apply the above, as I would recommend to any who are involved in the redesigning of the LAS IS, I would effectively be implementing a model for good practices. Each stage of the work process would be tested, the work tasks would be developed according to an accurate understanding of the precise functioning of the organisation and the tasks demanded of the system and any glitches in the system would be immediately detected and corrected. In other words, implementing the above model constitutes, in itself, good practice because it provides a strategy for IS project development which eradicates as far as is possible, errors, system malfunction and most definitely, systemic collapse. Therefore, the conclusion of my report is that the LAS should introduce automation for greater efficacy and that the vision contained in the earlier system is worthy of realization and implementation. However, design and implementation, in order to avoid IS failure, should proceed according to the above cited model, in all its details. 5 Bibliography Banker Rajiv D., and Robert J. Kauffman. “Reuse and Productivity in Integrated Computer-Aided Software Engineering: An Empirical Study.” MIS Quarterly, Vol. 15, No. 3, Special Issue: [Strategic Use of Information Systems]. (Sep., 1991), pp. 375-401. Barki, Henri et al. “An Information Systems Keyword Classification Scheme.” MIS Quarterly, Vol. 12, No. 2. (Jun., 1988), pp. 299-322 Bentley, Ross. “Learning from the Worst IT Mistakes.” Computer Weekly. 23 May 2002. Benyon-Davies, Paul. “Information Systems Failure: Case of LASCAD Project.” European Journal of Information Systems. 1995. Finkelstein, Anthony and John Dowell. “A Comedy of Errors: The London Ambulance Service Case Study.” School of Informatics. http://www.cs.ucl.ac.uk/staff/a.finkelstein/papers/lascase.pdf Joshi, Kailash. “A Model of Users Perspective on Change: The Case of Information Systems Technology Implementation.” MIS Quarterly, Vol. 15, No. 2. (Jun., 1991), pp. 229-242. Purvis, Russell L. “The Assimilation of Knowledge Platforms in Organizations: An Empirical Investigation.” Organization Science, Vol. 12, No. 2. (Mar. - Apr., 2001), pp. 117-135. Wastell, David G. “Learning Dysfunctions in Information Systems Development: Overcoming the Social Defenses with Transitional Objects.” MIS Quarterly, Vol. 23, No. 4. (Dec., 1999), pp. 581-600. Read More