Causes of Project Management Failure - Report Example

Information Technology Project Management A Case Study to Determine Why Projects Fail Name of Student: Name of Learning Institution: Introduction The success of contemporary business is represented by a complicated structure involving diverse areas ranging from communication to production methods. It is no wonder then that information technology is a key driver in managing all these aspects of business. The applications of IT in industry are almost inexhaustible from improvement of productivity via enabling a streamlined process to enhancement of efficiency of employees through better communication. It promotes growth of business by providing the means to access a larger clientele and collaborate with new partners. With all the advantages that IT offers industry, it is unfortunate that it has not quite measured up to its potential in the real world. Various researches that have been done have illustrated the failure of firms to succeed with IT projects. The Standish group did a study of thirty thousand IT application projects done by US companies The Standish Group International (2001) in which the criteria for failure was categorised as projects which were never completed or implemented. The results were tabulated as: Figure 1: history of project outcomes from 1994-2000 Although a distinct drop in failed projects was noted between 1994 and 2000, the percentage of failed projects was still significantly large. This project confirmed a premise that projects on a larger scale are more susceptible to failure than their smaller scaled counterparts (The Standish Group International, 1999). This is probably due to the added complexity of large projects. The following essay will seek to examine two projects that failed, in fact were considered death marches, in order to learn from them how to avoid such failure in future. The essay shall examine what role the Project Manager may have played in the failure of the project and what responsibilities they have in order to ensure success of the project. Discussion A plan to implement a project must have five significant features which need management. These features are 1). The scope of the plan which encompasses the “what” of the project- what will be involved exactly in the plan? 2) The resources to be used in order that the scope of the project might be met. 3) A timeline must be set in order to manage the tasks necessary to complete the project. 4) A certain standard of quality must be set about which the project can only deviate by a certain pre-defined percentage. 5) The risks of the project. What contingency measures are in place should these happen? (Coley, 2010). According to Coley (2010), IT projects are doomed to failure when three criteria are not met; delivery on time, within or on budget and the system works in the way that it is supposed to. There are just a few projects that deliver on all three criteria. A vast majority which are delivered will fall short of one or more of these and quite a few of these will be cancelled due to drastic failure (Tilman and Weinberger, 2004). The consensus by researchers according to Cushing (2002) is that there is no one overall reason for failure of projects but this usually occurs from a combination of factors. Some of the most significant of these reasons are: Deficiency in Management Participation This factor can render a killing blow to any project. When the user is uninvolved, the level of commitment to the project decreases to such an extent that there may be antipathy toward it. The involvement of senior management staff and other users to a project is crucial right from the beginning and continuously throughout the process. This means an investment in time and effort therefore when these are already stretched, and the project does not rate highly on their agenda then failure results. It is therefore very important for senior management to communicate the importance of the project to all users in order to give it priority and greater chance of success. Prolonged or Impractical Timelines The trick with Information Technology is that half life for a product is very short. Therefore if an extended time line is given for the delivery of a project, it may find that the technology is obsolete by the time it is in use. Therefore it is recommended by Coley (2010) that time scales should be short and should a project be extremely large, and then it should be broken down into smaller manageable projects. Conversely, due to this same issue, many project managers may set a time scale that is impossible to meet taking into account the scope of the work to be done. The result of this is either late delivery or incomplete work. Meagre or No Requirements For any project, especially one involving computer systems to be successful, it must be accompanied by a good set of user requirements. Failure to specify exactly what the system should be able to accomplish will lead to disappointment with the final product. This problem stems from the lack of knowledge about how the business runs on the part of the computer systems developer and a lack of knowledge of the potential of the computer system on the part of the business user (Fichter, 2003). This leads to paralysis and a lot of time is wasted on the management of timelines and budgets rather than the content. Scope Creep When the scope of the project is infected by insidious expansion of scale during life of the project, this is known as scope creep (Fichter, 2003). It is an issue of management that ties in with change control. If the management is not realistic about their goals and/or is unable to stick with them, then scope creep results. This leads to unrealistic expectations, failure to deliver within timelines and probably a failure of the system as well. Lack of a Change Control System It is the nature of business to embrace change and in contemporary business, the rate of change is very rapid. It therefore behoves any project manager to factor change into any plan. However, when this change is out of control, it can play havoc with the whole system under development leading to failure. This highlights the benefits of shorter timelines and phased projects as a way to manage change. Poor Analysis An evaluation of the system is done during different phases of development and finally the user must be able to run acceptance assessments to confirm that the system is up to business requirements. The bottleneck comes in if the other criteria had not been met initially and therefore failure to catch faults stemming from: Meagre requirements provided. Failure of planning or poorly planned tests meaning that systematic checks are not done. Users who are not sufficiently proficient with the system and thus are unaware of the purpose of testing. Limited time to perform assessment due to late delivery (Coley, 2010). Case Study 1 A number of IT project failures that are well documented involve cases to do with public money. The Virtual Case File project commissioned for the United States Federal Bureau of Investigation (FBI) is a case in point. This project, as admitted by the FBI themselves, failed to meet the requirements set out by the bureau in spite of being five years in development and costing USD 170million according to Friden (2005). The aim of the Virtual Case File project, delivered by Science Application International, was to facilitate case file management through the integration of data filed under an older system and which included the Automated Case support system, which would lead to eventual replacement of these. However, there seemed to be a lack of backup and contingency provisions in spite of the fact that the Automated Case Support System would not be available after the cutover to the Virtual Case File (National Research Council, 2004). These issues demonstrate a timeline that was extremely long and project requirements that were poorly planned and articulated as demonstrated by the perceived lack of backup or contingency plans. According to the system developer, Science Application International Corporation, they delivered the primary phase of the assignment ahead of timetable and under budget. However, after the terrorist attacks of 9/11, the software requirements changed several times according to Gross (2005). This can thus be identified as the beginning of scope creep. The requirements of the project were still being defined two years after commencement according to Fine and Glenn (2002). This lack of clear requirements was further exacerbated by the poor communication with IT managers at the FBI due to high turnover (Gross, 2005). Furthermore, according to National Research Council (2004) the Virtual Case File design did not contain requirements for the FBI mission. This case study implies that the difficulties that led to this project failure were more as a result of human error rather than technology according to Tilman and Weinberger (2004). In many cases, IT managers may not be given a chance to plan their projects due to time constraints and pressure from senior management. This leads to premature inception of projects without clear definition New Zealand Management, (2003). The problem here lies in the lack of significance attributed to planning and the notion that action would be a better way to proceed (Fichter, 2003). One elementary rationale for the failure of the Virtual Case File project was poor planning. For one thing, it was discovered that a very small amount of code was released for testing according to Gross (2005). As earlier stated, there are risks involved in every project and therefore, neglecting to carry out a risk analysis is a major drawback in project planning. This leads to a lack of awareness of the extent of the risk being undertaken in any particular IT project when formulating plans (Armour, 2005). This is exacerbated when newer technologies are replacing older ones leading to risks not previously experienced (Pinto and Kharbanda, 1996). The Virtual Case File project aimed to do just that yet the plan excluded availability of these systems according to the National Research Council (2004). This implies that calculations for risk were not done for this project. In some cases, there may not be a clear requirement laid out due to inarticulate definition (Glaser, 2004). The FBI had the intention of making it easing organisation, analysis and communication data for its agents in cases to do with crime and terrorism when it decided to implement the Virtual Case file system. However it failed to define how the system would ease this analysis and communication of data; this was left to the system developer to infer – a classic criterion for project failure. Another reason for failure of the Virtual Case File project was scope creep. Requirements for this project were changed a multiplicity of times after the terrorist attacks of September 11th 2001 (Gross, 2005). Case Study 2 In August of 2004, Ford Motor Co. shut down its five year herculean effort known as Everest Web purchasing project. This involved redeploying almost three hundred and fifty IT staff and the abandonment of an estimated USD 400 million that had gone into the project. The purpose of the project was to replace a group of obsolete purchasing and procurement systems, effacing paper, escalating speed and reducing costs all at once. The business user, Ford, and the systems developer, Oracle, are silent as to the cause of the failure, but it is thought to be the poor design, integration issues and IT sprawl; in addition to the costs (Keefe, 2004). The noble aim of the project was consolidation of thirty different purchasing and procurement systems into a single web-based entity able to serve several levels of suppliers. This would be a huge saving in terms of costs as automating procurement costs from manual processes would lead to huge savings in administrative overheads (Keefe, 2004). The project failed due to several issues. At the top of the list was cost control. The original budget for the project was USD200 million but it was estimated to have doubled before being abandoned. Although the project goals were thought to have been achieved in the first generation, it soon turned out that the end user was unable to access its full functionality in a satisfactory manner. Hence the system was poorly tested probably due to inadequate definition of requirements and lack of participation in the development stages (Keefe, 2004). Another concern identified was integration. Components required failed to run together effectively including CRM, application servers and security. This is again a factor of lack of definition of requirements as well as poor planning. Commensurate with the size of the project, there is increased need for people with expert oversight, communication skills planning and organisation. Unfortunately, it does not follow that highly experienced technology experts also possess these skills (Glaser, 2004). Therefore we find that once again, it is the human component that caused the failure of the project as opposed to technology per se. The project manager failed to conduct adequate research on the real-time functionality of the integrated systems leading to absolute disaster when the system got off the ground. The end user, that is the suppliers, were unable to use the system to access their data, were taken through a long and involved process that did not culminate in satisfaction of their aims and furthermore, had access to parallel systems that could achieve what this system could not (Keefe, 2004). Thus, either there was insufficient training of the end user or poor testing was done that failed to capture the glitches in the system. The second error in planning was the timeline. Five years in technology terms is too long a time for systems to be developed. Rapid changes in the industry would mean that scope creep would occur in order to keep up with these changes and if change control is not instituted what you are left with is a confusion of requirements that lead to system breakdown as occurred here, and thus to project failure. Conclusion The purpose of critically analysing IT projects that may have failed is not to daunt future endeavours but to assist in the learning process so that the same mistakes need not be made twice. In order for project managers to ensure success in their own projects going forward it behoves them to take into account some valuable lessons learned from the past. They should endeavour to pay attention to all tasks set out in their schedule, giving them the due diligence they deserve. It is also wise to create systems and process that can analyse risk to the project while ensuring that the project has clearly laid out objectives. Should there be need to alter these objectives, it is important to understand the trade-off before making a decision. When allocating a timeline for a scheduled task, it is important to calculate the duration necessary to complete it rather than how much time is spent on the task. This is true for resources as well; linear approximations are an inaccurate measure. It is important that senior management is on board with the project and lines of communication between them and the project manager should be kept open to avoid conflicts of interest. These lines of communication should extend to all participants in the project and they should be kept up-to-date on any progress being made. This progress should involve the users as their participation is important for design and development. Lastly, it is important to acquire the correct skills for planning, technology and communication. These observations would form the framework which would minimise the probability of joining the FBI and Ford in IT project failure. References Armour, P. (2005). Project Portfolios: Organizational Management of Risk Communications of the ACM, Volume 48, Issue 3, page 17 Coley, P. (2010). Why Projects Fail - The six key project failure reasons. Retrieved 1st September, 2011 from www.coleyconsulting/failure.htm Fichter, D. (2003). Why Web Projects Fail [Online Journal] Online, Volume 27, Issue 4, page 43. Retrieved 1st September, 2011 from computer source database at http://www.ebscohost.com Fine, Glenn. (2002). Federal Bureau of Investigation's Management of IT Investments: OIG findings and recommendations, Report No. 03-09 U.S. Department of Justice, Office of the inspector general. Retrieved 1st September, 2011 from http://www.usdoj.gov/oig/reports/FBI/a0309/findings.htm Friden, T. (2005). Report: FBI wasted millions on Virtual Case File [Online] CNN Washington Bureau. Retrieved 1st September, 2011 from http://www.cnn.com/2005/US/02/03/fbi.computers Glaser, J. (2004). Management's role in IT project failures Healthcare Financial Management, October Gross, G. (2005). FBI trying to salvage $170 million software package [Online] IDG News Service. Retrieved 1st September, 2011 from http://www.computerworld.com/printthis/2005/0,4814,98980,00.html Keefe, P. (2004). Oops! Ford and Oracle mega-software project crumbles Retrieved 1st September, 2011 from http://www.Oops-Ford-and-Oracle-megasoftware-project-crumbles.aspx.htm National Research Council. (2004). A Review of the FBI’s Trilogy Information Technology Modernization Program Computer Science and Telecommunication Board, National Academies Press, Washington D.C. New Zealand Management. (2003). When IT Projects Fail [Online Journal] Volume 50, Issue 2, page 18 Retrieved 1st September, 2011 from Business Source Premier Database at http://www.ebscohost.com Pinto, J.K., and Kharbanda, O.P. (1996). How to fail in project management – without really trying Business Horizons, Volume 39, Issue 4, July-August. Tilmann, George and Weinberger, Joshua. (2004). Technology never fails, but project can [Online journal] Baseline, Volume 1, Issue 26, page 28. Retrieved 1st September, 2011 from computer source database at http://www.ebscohost.com The Standish Group International. (1999). CHAOS: A Recipe for Success: The Standish Group International The Standish Group International. (2001). Extreme CHAOS the Standish Group International Read More