Failed Information Technology Project - Report Example

Failed Information Technology Project Section Number of Failed Information Technology Project The CHAOS report of the Standish Group (1995) defines three types of Information Technology projects based on their measure of success or failure. These are: i. The successful projects which are completed on time, and on budget, with all features and functions as initially specified. ii. The challenged projects which are completed and operational, but over budget, over the time estimate, and offers fewer features and functions than originally specified. iii. The failed or impaired projects that are cancelled at some point during the development phase. The problem here is in deciding whether the challenged projects actually fall in the category of failed projects or can be categorized as successful projects albeit with hiccups in between. Defining ‘failed’ IT projects Lyytinen & Hirschheim (1987) defined four major theoretical categories of failed IT projects: i. Correspondence failure: This form of failure is based on the idea that design objectives are specified in detail. An evaluation is conducted of the information system in terms of these objectives. If there is a lack of correspondence between objectives and evaluation the IT project is regarded as a failure. ii. Process failure: This type of failure is characterised by unsatisfactory performance. Either, the development process cannot produce a workable system or the development process produces a solution but the project runs over budget in terms of cost, time etc. iii. Interaction failure: The argument here is that if a system is heavily used it constitutes a success; if it is hardly used, or there are major problems with using the system then it constitutes a failure. iv. Expectation failure: Lyytinen and Hirschheim describe this as a superset of the three other types of failure. A failed IT project is characterized primarily by incomplete requirements, lack of user involvement, lack of resources, unrealistic expectations, lack of executive support, changing requirements and specifications, lack of planning, lack of utilization, lack of IT management and technology illiteracy. Even if IT projects have a definable lifecycle, their products or results can never be static. When an IT application is developed and implemented, it has to have the scope to be enhanced, extended and adapted to newer platforms. A IT project can therefore deemed to be a failure if the solution it delivers lacks growth and evolutionary capabilities. IT projects are not technical goal oriented per se. IT projects are primarily not launched to achieve any outstanding piece of IT engineering, they have to have business value. A delayed project that goes way above the budget could turn out to be a profitable investment if it facilitates business, whereas a project completed on time, within budget and with the specified functionalities could be considered a bad investment if it does not impact business positively. An IT project could therefore also fail due to lack of business sense. The overall project profitability is a much more relevant success criteria than strict adherence to the initial budget. IT projects have to adapt and merge with their organization environment. An IT application which is not an intrinsic part of its business environment will fail to meet expectations. IT projects have to keep the requirements of end users in mind. The adaptation process has to be mutual: an organization has to adapt itself to host a new and comprehensive IT application, and the IT application also has to be designed to meet the needs and capabilities of the organization for which it is developed. An IT project can therefore also fail due to lack of integration with its business environment. Implementation Management Although many IT projects fail because of technical lacunae or failure to meet business requirements, a considerable number also fails because of weak implementation management, especially problems related to stakeholder involvement (Strassman, 1985). A large number of these failures could be avoided by proper management in implementation. The implementation process involves issues related to stakeholder management and to change dynamics and change management. Successful implementation of IT projects requires a holistic management approach oriented on implementation right from the project conceptualization and planning phase. In other words, every phase of the project has to have an eye on implementation. The possible lack of implementation orientation in the different phases of IT projects that could result in project failure is elaborated below (Legris, 2006): Phase I: Preliminary Analysis: Failure to conduct an appraisal of an organization’s readiness to integrate a new information system, at the very initial stages of an IT project, more often than not, leads to implementation failures. This omission not only increases the probability of budget underestimations, but also management of useful information about users habits, needs, concerns, constraints, and mindset. From an implementation point of view, it is very useful to gather all relevant information during the preliminary phase. Such an approach accords the management the foresight to anticipate potential pitfalls, users’ expectations and concerns, and real-life challenges related to the usefulness of the system to be developed. This process should involve enough end users and management at various levels to make a positive contribution to the change process. Information gathering and discussions, and the subsequent publication of the findings in easily comprehensible formats prepare all concerned for the changes would be essential. Without such an analysis, implementation is endangered from the very beginning. Phase II: System Requirements: Although this phase is considered a very technical one, the choices made at this stage have a very strong impact on the entire implementation process. Awareness of the factors influencing choices, as well as a clear understanding of how the new system will benefit the execution of work and enhance receptivity to the chosen solutions. End users do not make the choices, but they should be informed of the basis on which the decisions were made, and what advantages would accrue. Soliciting suggestions from end users on which aspect of the work require improvements most will also play a crucial role in successful implementation. Phase III: Preparation: Even though it is the usual practice to let the IT people alone handle this phase, it is very important that management should remain fully involved as the conception and design of the system will significantly influence work processes, as well as business processes, and these are primarily management responsibilities. Involving end users actively in choosing, testing and validating new processes, provides the development team with the opportunity of testing and gauging how end users will react and behave when interacting with the system under development. They are able to make suitable modifications or adaptations accordingly. Lack of implementation orientation at this phase tends to accumulate more problems for the implementation phase, sometimes leading to project collapse. Phase IV: Implementation of the New System: Sole emphasis on features installation during the implementation of any IT project could lead to implementation failures. The real issues here are acceptance of the system as a whole, and effective use of its functions. Users should be able to handle the system correctly and get what is expected from it. Even with a highly user-friendly system, users may not be comfortable in handling it without orientation and familiarization programs. Three typical phenomena are frequently associated with project implementation at this stage: higher fatigue level, individual and collective confusion, and feeling of personal failure, each with the potential of leading to discontent and rejection and ultimately to implementation failure. Management participation in the form of providing consistent guidance to end users is absolutely necessary to avoid such problems. Phase V: Consolidation: In this final phase, organizations should fine tune the system, the work and the business processes to derive the maximum out of the IT project. These include technical fine-tuning as well as making a serious assessment of the functioning of the system. Failure to do so will result in persistence of problems and inability to adapt, which in turn could snowball into project failure. The classical approaches to IT project implementation management focussed more on technical issues and tended to ignore stakeholder involvement and social issues. The high rate of IT project failures could be attributed to the inherent drawbacks in such approaches. An integrated approach focussed on management of project implementation from the very initial stages would ensure a much higher rate of success for IT projects. References -01 Legris, P., 2006, A roadmap for IT project implementation: Integrating stakeholder and change management issues, Project Management Journal, [online] Available. http://www.allbusiness.com/management/4110466-1.html [January 15, 2008] Lyytinen, K. and Hirschheim, R.,1987, Information Systems Failure: A Survey and Classification of the Empirical Literature Oxford Surveys in IT, 4, pp257-309 Standish Group, 1995, The CHAOS Report. [Online] Available. http://www.cs.nmt.edu/~cs328/reading/Standish.pdf [January 15, 2008] Strassmann, P., A., 1985, Information Payoff: The Transformation of Work in the Electronic Age Free Press, New York, NY. Read More