Why Projects Fail - Essay Example

Table of Contents Part 2 Introduction 2 Key Factors of Project Failures 2 Project Lifecycle 3 Causes of Project Failures 4 Lack of Project Methodology 4 Poor Planning 4 Poorly-Defined Project Scope 5 Lack of User Involvement 5 Scope Creep and Feature Creep 5 Untimely Implementation 6 Limited Training 6 Risk Management 6 Types of Project Risks 7 Part 2 8 Case Study: UK Passport Agency 8 Identified Causes of Failure 9 References 12 Why Projects Fail Part 1 Introduction Project fails. Despite a few known cases of successful project development and implementation, it is widely accepted in the industry that a number of unacceptable projects fail, especially in the IT/IS sector. According to Lyytinen and Hirschheim (1987), the estimated number of project failures is half of all the systems implemented. Galloway and Whyte (1989) concurred with the survey of project failures. Whyte and Bytheway (1996) further argued that more projects fail than succeed. Bozman (1994) claims that project failures are common in every parts of the world – it is an international phenomenon. Industries view project failures as either a pathological state to be avoided or a logical problem of goal definition (Lindahl & Rehn, 2007). This paper will focus on the different key factors that influence the failure of projects especially on the field of information technology (IT). It will discuss the different stages in the project lifecycle and the possible areas of failures in each stage. Furthermore, the paper will tackle the concept of risk management and its benefits in a successful project development as well as in preventing failures. A successful risk management system incorporated in a project will create a programme for handling probable causes of project failures. Key Factors of Project Failures IT projects fail when it does not meet one or more of its criteria for success. The criteria for successful IT projects are delivery on time, completion on or under budget, and satisfaction of user requirements. Only a few projects achieve all three (Grossman, 2003). In summary, failure can be defined as a system which does not perform as expected, not operational at a specified time and cannot be used in the way expected. There are four key factors that can be associated with project failures. These are design, data, cost and operations. A poor design phase can result in a system that does not match customer expectation, or fails to capture the basic business requirements. The data factor may include inaccurate, inconsistent, not available or incomplete information and records. The cost factor involves the operational costs to implement and run the system that far exceeds the identified business benefit. A survey showed that 35% of all major information systems projects are over budget, termed “runaways”, such as the Stock Exchange Taurus Project and the London Ambulance Service (Flowers, 1996). Project Lifecycle The project lifecycle defines the beginning and the end of a project. It is a collection of generally sequential and sometimes overlapping project phases whose name and number are determined by the management and control needs of the organisation (Project Management Institute, Inc, 2008). It also determines which transitional actions are included and which are not in every stage of the project from beginning to end. It can be used to link the project to the ongoing operations of the organisation. (Choudhuri, 2005) The first phase of the lifecycle is the initiating process which involves those processes performed to define a new project by obtaining the authorization needed to start the project. The second phase is the planning process which includes those processes required in establishing the scope of the project, refining the objectives, and defining the course of action in order to attain the objectives of the project. The third phase is the executing process which encompasses those processes performed to complete the work defined and to satisfy project specifications. The fourth phase is the monitoring and controlling process which includes those processes required to track, review, and regulate the progress and performance of the project. The last phase is the closing process which considers those processes performed to finalise all activities to formally close the project. (Project Management Institute, Inc, 2008) Causes of Project Failures In every phase of the project lifecycle, several causes of project failures can be identified. The following are the common causes of project failures: Lack of Project Methodology Project methodology includes the different project lifecycle from beginning to end that are needed in order to complete the project. Lack of project methodology will force the project manager as well as the team members to make hasty and haphazard decisions without basis of factual data and objective analysis. A successful project follows a well thought out route and programme in order to implement a smooth flow of operations and prevent going in circles, getting lost and hitting countless roadblocks. The methodology must take into account the size and complexity of the project as well as planning, development and implementation guides. (Grossman, 2003) Poor Planning Failing to plan is planning to fail. Planning is one of the key factors that can affect the success of the project. Project managers should take a lot of consideration in creating the project plan and pay a lot of attention to this area. Enough time must be allocated in the planning process in order to cover every area of the project lifecycle as well as possible risks involve (Kleim & Ludin, 2000). Poorly-Defined Project Scope Unclear goals and objectives contribute to the failure of completing the project. When goals exceed the ability to deliver timely results, the project will surely fail. Successful projects have a well-defined scope that must state realistic goals as well as obtainable objectives. Benefits and deliverables of every phase in the project lifecycle should be clearly defined and communicated. Scope must also be clearly identified and delineated as part of the project definition. The project problems start with common scope mistakes such as overrunning initial cost estimates, over- or under-estimating project schedules, and miscalculating work to personnel ratio. (Lindahl & Rehn, 2007) Lack of User Involvement Successful projects need input from the people who will be affected most by the project such as the end-users. Poor user input or vague requirements from the end-users are project killers. The project team may be given informal set of requirements that are indistinct or ambiguous which could result in building a project based on the project teams assumptions and not on what the users actually need. Major roadblocks that would be encountered may include project not meeting customer needs, reduces productivity and product design takes longer than required. (Ennals, 1995) Scope Creep and Feature Creep Scope creep refers to uncontrolled and unexpected changes in user expectations and requirements as the project progresses. Feature creep, on the other hand, refers to uncontrolled addition of features to a system with a wrong assumption that one small feature will add nothing to cost or schedule. The most common form of scope creep is modifying the products without testing against the business case and evaluating the impact on the cost, schedule and risks. A project manager should be aware of the risks of change and the risks of no change while balancing both risks before deciding what to do. (Williams, 2008) Untimely Implementation Rolling out at the wrong time produces unsuccessful projects. Proper timing of a project’s implementation is an important success factor. Business sponsors want the system implemented before peak times where it will provide the greatest benefits, however, testing and pilots should not be sacrificed in lieu of the sponsors’ wants. Rolling out without pilots and testing can be disastrous. (Lyytinen & Hirschheim, 1987) Limited Training Training is the first thing cut from a project when funding is low or over budget. You get the product released and the sponsors will not spend additional money on training. Without proper training, the new system will not provide the expected return on investment. Additionally, poor or no training will lead to low customer acceptance resulting in a failed project. To receive value, the customer must know how to use the new product. (Sommer, 2003) Risk Management Elkington and Smallman (2002) have identified in their study that there is a strong link between the amount of risk management undertaken in a project and the level of success of the project. They maintain that more successful projects use more risk management. Furthermore, risk management practices used in the earlier stages of the project contribute to a more successful project. Risk is defined as the possibility that a project may not achieve the product, schedule or resource targets because something unexpected occurs or something planned does not occur (Portney, 2007). Risk is the occurrence of an event that has consequences or impacts on a project (Kleim & Ludin, 2000). All projects have some degree of risk because predicting the future with certainty is impossible. Risk may stem from the nature of the work, from the type of resources available, from the contractual relationship which is in place or from the political factors which influence the project (Yeates & Cradle, 1996). Types of Project Risks Higuera (1995) states these characteristics are uncertainty and loss. Uncertainty is the event that characterises the risk with a possibility to happen or may not happen. However, there are no 100% probable risks because it is a major stumbling block for the project. Loss is the consequence if the risk becomes a reality. Kleim and Ludin (2000) further categorises project risks according to its main characteristics. They proposed risk categories such as acceptable and non-acceptable risks. Acceptable risks are tolerable if they occur and will not stop the project. Non-acceptable risks slow or stop tasks on the critical path of project completion. Pressman (1997) identifies three types of risks for IT projects – project risks, technical risks, and business risks. Project risks involve potential budgetary, schedule, personnel, resource, customer, and requirements problem and their impact on an IT project. Technical risks are identified potential design, implementation, interfacing, verification, and maintenance problems as well as specification ambiguity, technical uncertainty, technical obsolescence and leading-edge technology upgrades. Business risks include identified business stability, usefulness and validity problems that are considered as strategic, management, market and budgetary risks. (Pressman, 1997) Part 2 Case Study: UK Passport Agency The United Kingdom Passport Agency was established as an Executive Agency of the Home Office. Its main aim is to provide passport services for British nationals in UK. Their objectives include maintaining the integrity and security of the United Kingdom Passport as well as meeting known travel needs in passport services; provide advice on passport matters; and ensure that the passport service meets the needs of its customers. Since its creation in 1991, the Agency has dealt with increasing demand for passport applications due to improved economic climate, greater opportunities to travel, cheaper travel and the abolition of British Visitor’s Passport. By 1997, the Agency had decided to employ Siemens Business Services to carry out initial processing of passports and to provide a new computer system that would support passport processing. Security Printing & Systems Ltd. was contracted to provide secure printing and despatch of passports. The Agency implemented its new computer system and procedures in its Liverpool Office on October 1998 with an expected output level to reach 30,000 issues per week. However, the output level was just over 8,000 issues per week which prompted the Agency and its partners to suspension of the planned roll-out of the new system to rest of the offices. The volume of applications started increasing in February 1999 which also increased the maximum processing time. As a response to the demand, the Agency increased overtime working, trained existing staff as passport examiners, and began recruiting extra staff. When the demand continued to increase, the maximum processing time began to deteriorate further. By May, the monthly output level reached 619,000 applications with a backlog of 565,000. As an emergency measure to alleviate the problem and achieve the 10 day target in maximum processing time, the Agency established a call centre to deal with telephone enquiries, added extra staff in passport offices and a facility to extend passports at post offices at no charge for up to two years. It is only at September 1999 that the Agency has recovered from its backlog and decreased its maximum processing time to five days. Identified Causes of Failure There are several causes of project failure that have been identified in the underperformance of the Agency’s planned capacity to process passports. The first cause the introduction of a new computerised passport processing system which was suspended on the remaining four offices due to roadblocks encountered at the Liverpool and Newport offices. As mentioned in the first part of the paper, untimely implementation as well as poor planning can cause failure in a project. Because of the suspension of the roll-out of the new system in other four sites, the Agency has not been able to cope up with the demand during 1999. The suspension is an example of a poor planning because the Agency and its partners were not able to anticipate the possible problems and risks in both their two offices. Furthermore, the Agency had not take into account the initial report of poor performance and poor productivity as well as initial problems in its pilot office. Another cause of the project failure is the long completion of the design and development stages of the new computer system. The design stage was completed four months later than expected and only six months before the ‘go live’ date. The design phase was on an evolutionary process with several versions of design documents as the new system was defined and redefined by the Agency and Siemens. This is an example of a scope and feature creep where the product undergoes several modifications as the project progresses. As a result, the subsequent development stage was also delayed and prolonged. Furthermore, the delays in at the design and development stage also delay the testing of the new system. Due to time pressures, the test programme did not extend to thorough testing of the system’s impact on productivity. This roadblock can also be considered as the consequence of untimely implementation where testing was cut short. In order for the Agency to limit the project failure, the testing phase should have included a system test, customer acceptance test, volume testing and stress testing to test the scalability of the new system. Developers will do a great deal of testing during the development but eventually users must run acceptance test to see if the project meets their business requirements. However, due to time constraints, the testing completed was only the initial system test. Skipping the testing phase because the project is way behind schedule led to downright failure. Other problems encountered during the project involve delays contributed by the method of capturing information through scanning forms which were followed by correction by its operators. The method created high error rate which led to high correction level and other resulting problems. A loss of productivity at the examination stage was caused by the examiner’s lack of familiarity with the system and the need to correct errors in the data scanned as well as a large number of key-strokes and on-screen operations to be completed before deciding on eligibility of a passport. These problems are an example of lack of user involvement as well as limited training on end-users as described on the first part of the paper because there was insufficient support available to the staff to answer queries about the new system and working arrangements. The Agency should have pay special attention to the interaction between the new system and the people expected to use it with focus on the practicability, usability and ease-of-operations on its passport processing system and features. Another problem encountered in the case is the insufficient communication of keeping the stakeholders such as the public well informed. The people were not aware of the actual causes of delay in the passport processing. The information they have gathered from the media only involves the information about the backlogs. Once the backlogs begun to build up further, the public had significant difficulty in contacting the Agency to check on the progress of their applications. Telephone queries took longer to resolve when more and more applications became urgent. At peak periods in Liverpool, the telephone enquiry service was virtually shut down because some staff where withdrawn from telephone duties in order to devote more resources to processing applications. Communications problem could have been avoided if the Agency had adopted a communication plan in the planning phase. Communication plan identifies people with an interest in the project (stakeholders), communication needs, and methods of communication. Communication planning helps to ensure that everyone who needs to be informed about project activities and results gets the needed information. It can be concluded from the case that the Agency has not thoroughly planned its new computerised passport processing system as well as create an intensive project risk management programme. If the Agency has created a risk management programme that would have included the contingency plans necessary to address probable risks such as surge in demand and probable areas for failure, then the Agency would have been prepared to address the problems in the summer of 1999. Project risks, technical risks as well as business risks were all visible in the case of UK Passport Agency. Such risks could have been addressed prior to it becoming a reality if the Agency had created an intensive and objective risk analysis. Risk management is an organised systematic decision-making process that efficiently identifies risks, assesses or analyse risks, and effectively reduce or eliminate the risks to achieve the project’s goals (Barkley, 2006). Risk assessment should not be a separate process but rather an integrated part of the project planning and management process. A good integration plan includes a scheduled integration phase with gate reviews at particular milestones, including design, coding, and testing. In addition, the project team is made aware of the need to communicate across functional areas to make sure that software engineers, certification engineers, quality assurance engineers, electrical engineers, and mechanical engineers are all talking during software development. In closing, it has been observed that the account of failure in information system development in UK Passport Agency is also an account of organisational failure. In other words, the case can be considered as a case of IS failure and of organisational failure. Technical issues are but manifestations of deeper social pathologies by social meaning issues at the individual, group and organisational levels of functioning and interacting. (Goulielmos, 2003) References Barkley, B. (2006). Integrated Project Management. New York: McGraw-Hill Companies, Inc. Bozman, J. (1994, May 9). DMV Disaster. Computerworld , 28 (19). Choudhuri, N. M. (2005, August 30). Project Management Fundamentals. ITC Infotech , pp. 1-22. Elkington, P., & Smallman, C. (2002). Managing project risks: a case study from the utilities sector. International Journal of Project Management , 20, 49-57. Ennals, R. (1995). Executive Guide to Preventing Information Technology Disasters. London: Springer-Verlag. Flowers, S. (1996). Software Failure: Management Failure: Amazing Stories and Cautionary Tales. New York, NY: John Wiley & Sons. Galloway, R. L., & Whyte, G. L. (1989). The internal information systems function as a service operation. International Journal of Operations & Production Management , 9 (4), 19-27. Goulielmos, M. (2003). Outlining organisational failure in information systems development. Disaster Prevention and Management , 12 (4), 319-327. Grossman, I. (2003). Why so many IT project fail, and how to find success. Financial Executive , 19 (3), 28. Higuera, R. P. (1995, January). Team Risk Management. Cross Talk , pp. 2-4. Kleim, R., & Ludin, I. (2000). Reducing Project Risks. Hampshire: Gower Publishing Ltd. Lindahl, M., & Rehn, A. (2007). Towards a theory of project failure. International Journal of Management Concepts and Philosophy , 2 (3), 246-254. Lyytinen, K., & Hirschheim, R. A. (1987). Information systems failure: a survey and classification of the emperical literature. Oxford Surveys in Information Technology , 4, 257-309. Portney, S. (2007). Project Management. Hoboken, NJ: Wiley Publishing Inc. Pressman, R. (1997). Software Engineering: A Practitioners Approach - European Adaptation (4th ed.). Berkshire: McGraw-Hill Book Company Europe. Project Management Institute, Inc. (2008). A guide to the project management body of knowledge (4th ed.). Newtown Square, Pennsylvania: Project Management Institute, Inc. Sommer, D. (2003). Avoiding Project Failure. Business Technology Research Center. Whyte, G., & Bytheway, A. (1996). Factors affecting information systems success. International Journal of Service Industry Management , 7 (1), 74-93. Williams, M. (2008). The Principles of Project Management. Canada: Sitepoint Pty. Ltd. Yeates, D., & Cradle, J. (1996). Project Management for Information Systems (2nd ed.). London: Pitman. Read More