Project Management II Research Paper

BBA 3626, Project Management Overview 1

Course Learning Outcomes for Unit II Upon completion of this unit, students should be able to:

2. Examine the steps for identifying projects and developing their proposals.

Reading Assignment Chapter 2: Project Selection and Prioritization

Unit Lesson Unit II summary is going to further illustrate major project failures as a continuation from Unit I. The first project to discuss is the FoxMeyer Drugs project which involved purchasing a systems applications and products (SAP) system and a warehouse automation system. The goal of this project was to increase efficiency. These two systems needed to be integrated in order to implement. A consulting firm was hired to do this piece of the project. The goal was to have this system implemented in 18 months which was an unrealistically aggressive time line. The next problem was the automation piece which would eliminate many jobs for current employees. These employees were not supportive of a project that threatened their jobs. The system turned out to be less capable than the one it replaced. Cost overruns plagued this project, and eventually the company went bankrupt. The lesson learned for this project was that it is important to make sure your operation can survive the failure of a project (Widman, 2008). The Copland Project was Apple’s attempt to develop a new operating system in the early 1990s. This project was plagued with feature creep. This project ended quickly because the project’s goals were not focused. Another project failure worth mentioning was Canada’s gun registration system. The project was supposed to cost the taxpayers only $2 million and $119 million for implementation, offset by $117 million in licensing fees. Politics became a problem which resulted in more than 1,000 change orders in the first two years. The changes involved interfacing with the computer systems of over 50 agencies and this interfacing was not part of the original contract. More money had to be paid by the government for these changes. The annual maintenance costs were running over $75 million a year. The lesson learned for this project was that defining project scope and freeze specifications before the requests for changes getting out of hand were paramount (Widman, 2008). As with the FoxMeyer project, Copland was also plagued by cost overruns and an overly ambitious project. Another huge project failure was the Expeditionary Combat Support System, an Air Force project. This project began in 2004 and was terminated in 2012 because of huge cost overruns and mismanagement of the program. The goal of this project was to consolidate and replace 240 separate Air Force computer systems (legacy systems) with a single enterprise resource planning (ERP) system. Over $1.1 billion was spent on this project without any significant capability being realized before it was canceled. The project was risky and ambitious from the beginning. It was determined that much more money would be needed for about a quarter of the original scope to continue and the fielding would slip to 2020 (Charette, 2012). This project, like the others, was plagued by cost overruns and over ambition. The next program that is going to be discussed comes from the standpoint of a developmental tester who worked on one piece of this program, which was the testing of the communications piece of the reconnaissance and surveillance vehicle. This program of record was known as the Future Combat Systems (FCS) that the Army needed for modernization into the future. This program was extremely ambitious as were the other projects mentioned in this summary. The FCS program was the largest acquisition program in the history of the Army, and its sole purpose was to modernize the Army by developing a system of systems and

UNIT II STUDY GUIDE

Project Selection and Prioritization

BBA 3626, Project Management Overview 2

UNIT x STUDY GUIDE

Title

integrating this into an advanced wireless network. Many of the technologies scheduled for this program were immature and had no demonstrated proof of concept. Misunderstandings of the requirements led to the instability of the program (Pernin et al., 2012). The intent of the Army for this program was good, but the program faced too many challenges and obstacles to execute effectively within the scope, time, and resources available. The cost of the FCS program was initially estimated at $200 billion: a hefty price tag. FCS promised to deliver or “field an entire Army brigade with new, lighter, and more mobile technologies that would be protected by improved sensors” (Pernin et al., 2012, p. 1). Originally, the program consisted of 18 different vehicles/sensors/munitions, manned and unmanned, plus a ubiquitous network, and a solder. Eventually, the program changed to 14 different vehicles/sensors/munitions, manned and unmanned, plus a ubiquitous network, and a solder (Pernin et al., 2012). In 2003, FCS reached its decision B milestone which meant it became a program of record in the acquisition world. Unfortunately, the technology was immature, the schedule kept slipping, and the costs escalated. FCS was cancelled in 2009. A primary reason for the program was that a more up-to-date Army needed a new, modernized program to fight the new threats in the world. The Rand study (Pernin et al., 2012) found that FCS promised “the capability to deliver a combat brigade anywhere globally in 96 hours, a division in 120 hours, and five divisions in 30 days” (p. 9). The capability of this program was too unrealistic. The Army’s understanding of the future operating battleground drove the FCS program assumptions. These assumptions were not technically sound or completely validated. Situational awareness was something needed for the new futuristic Army. This over ambitious program could be compared to a Star Wars type concept (Pernin et al., 2012). Situational awareness needed for the new modernized Army demanded a robust complicated network. Wargames were used to try and validate concepts that did not work. Large, complex acquisition programs require and demand analytical capabilities to be successful. There were too many pieces to this huge program that lacked some proof of concept. Proof of concept should be accomplished before becoming a program of record. Trying to integrate so many systems into an effective program in a short period of time, within budget, was impossible. These systems were too complex. “The FCS program experienced significant turbulence throughout its history” (Pernin et al., 2012, p. 49). All of the failed projects discussed in this summary have similar characteristics. First, each project or program had extremely ambitious requirements. Second, the projects and programs were plagued with cost overruns. Lastly, these projects and programs were mismanaged. The characteristic failures mentioned in this summary represent most characteristic failures common to most failed projects.

References Charette, R. (2012). U.S. Air Force blows $1 billion on failed ERP project. Retrieved from

http://spectrum.ieee.org/riskfactor/aerospace/military/us-air-force-blows-1-billion-on-failed-erp-project Kloppenborg, T. J. (2015). Contemporary project management (3rd ed.). Stamford, CT: Cengage Learning. Pernin, C. G., Axelband, E., Drezner, J. A., Dille, B. B., Gordon, J., IV, Held, B. J., Sollinger, J. M. (2012).

Lessons from the Army’s Future Combat Systems Program. Retrieved from http://www.rand.org/content/dam/rand/pubs/monographs/2012/RAND_MG1206.pdf

Widman, J. (2008). IT’s biggest project failures—and what we can learn from them. Retrieved from

http://www.computerworld.com/article/2533563/it-project-management/it-s-biggest-project-failures---- and-what-we-can-learn-from-them.html

Learning Activities (Nongraded) PMBOK Guide Questions, p. 46, questions 1-10 Nongraded Learning Activities are provided to aid students in their course of study. You do not have to submit them. If you have questions, contact your instructor for further guidance and information.