An Examination of Common Causes of Software Project Failure and Their Application in the Denver International Airport Baggage Handling

System Failure Donald Winans

Donald Winans CSC383

An Introduction Even small software projects are complex and contain a lot of potential for failure. Extremely large projects can be so complex that if the project is not managed correctly, the project will most certainly fail. It has been reported that five to as high as fifteen percent of all new IT projects crash and burn (Charette). Five percent may not seem like a high number of failures, but imagine that if every time you went to the grocery store that five percent of everything you purchased was defective and unusable, and not returnable. Think of all the money that would be wasted, more than likely you would stop going to that store. The store would not be in business for long either. Software failures can cost millions of dollars in wasted money. A company that allows a major failure may not survive the monetary costs let alone the damage to its reputation. The organizations that commissioned the project will also suffer heavy monetary losses. In just the United States project failures annually waste up to seventy billion dollars (Charette). A software project should not feel like a game of chance. The numbers of projects that fail may be high, but the failures all seem to share some common themes. If you examine these projects you begin to see a combination of missteps to include not understanding what it is the customer wants, requirements bloat, in-experienced managers, or the use of new untested technologies. These are just some of the common reason that causes projects to be unsuccessful. The point being that these projects did not have to crash and burn. Had those involved realized what path they were about to stumble onto, they could have taken actions to change the ultimate outcome. To be able to recognize that you are about to do something or not do something that will put your project on that slippery slope that ultimately leads to unhappy stakeholders and a chance to make the list of top ten software failures, you must understand what those common root causes are. To illustrate them we will examine the attempt to create a fully automated baggage handling system for the Denver International Airport. Many mistakes were made in that particular case, which will illustrate just how something that seems very do able on paper, ends up as a total catastrophe. The Project and Its Failure In the late 1980s the city of Denver, Colorado wanted to build a new airport to attract more business to the area as well as to attract tourists to the area. The city wanted the new airport to be large enough to serve as a hub for many of the airlines that were around at the time. Of the major

Donald Winans CSC383

airports there are hubs and nodes. The hubs are similar to bus stations, in that aircraft are based out of them, they have repair facilities and they service very large areas. A node on the other hand is like a bus stop. They tend to be smaller, aircraft stop at them to pick up and drop off passengers but they are not permanently based at them. They service a smaller area than hubs with flights going to and from fewer places than the actual hub. The city of Denver knew that it was in a great location to be a hub, being a large city in the Rocky Mountains. Construction was started in 1989 with an estimate that total construction costs would come to a total of $1.3 billion, with a completion date of October 1993 (Office, Testimony Denver International Airport); however Denver had to attract some major carriers if it was to make the project economically feasible. United Airlines had said that they would be very interested in using the soon to be Denver International Airport as a hub, if the airport could be designed in a way that would allow a turnaround time for an aircraft landing at the airport to be less than thirty-five minutes. The immense size of the airport, large enough to hold all of Manhattan, twice over (Gibbs) meant that the traditional method of pull carts and tractors would not be fast enough. The city and the project management team looked for a faster more efficient way to move baggage, so as to attract some airlines. The Franz Joseph Strauss Airport located in Munich, Germany had implemented an automated baggage handling system a few years earlier (Donaldson). Though a much smaller airport with far less traffic then the expected traffic Denver would receive, the city and the project management team saw that system as the solution they had been looking for. The airport development team then hired the consulting firm Breier Neidle Patrone Associates who looked at the potential for creating a fully automated system for the airport. BNP reported back that while the system would provide many advantages that there was no way a system large enough to handle an airport the size of Denver International Airport could be built in the time allotted by the schedule (Swartz). The city decided it would be better to let each airline design and build its own baggage system, so long as the airlines system would not interfere with a future airport-wide automated system. In the meantime Continental Airlines had signed on as a carrier that would use the airport as a hub. Continental airlines were the only committed airline to do so far. To get the commitment from Continental the project management team agreed to change aspects of the plan to benefit Continental. However, soon afterwards Continental had filed for bankruptcy. The city and the airport authority were concerned that Continental would be unable to pay for anything. With the only committed airline in bankruptcy, there was increased pressure to entice United into a long term commitment. United demanded an automated baggage handling system for its own

Donald Winans CSC383

concourse and since it had already been decided that each airline could develop its own system so long as a future airport wide system could be put in, it was easy to accept the offer (Donaldson). United Airlines hired BAE Automated Systems to design the automated baggage handling system for their concourse. BAE Systems was a logical choice, at the time they were the leading supplier of airport equipment, including baggage conveyance systems. BAE opted to use a development model called rapid application development (Swartz), to build the concourse wide baggage system for United. They leased a 50,000 square foot warehouse near their headquarters in Texas, and built a prototype of the system. This prototype was a much smaller system, than what would be needed for one airlines section of concourse, and being a prototype it was all smoke and mirrors intended to demonstrate what the finished system would look like (Donaldson). Seeing the prototype had an effect on the project management team and representitives from the city, that caused them to recall that they had originally planed for an airport wide baggage handling system. BAE had infirmed them that they had the system right there in the warehouse, and it would just take some minor modifications and an expansion of the scale and they would have that automated system (Calleam Consulting Ltd). Now ignoring the results of the earlier evaluation that said there was no waya system that complex could be built in the time frame alloted a year ago, and ignoring the fact that the much smaller German system had taken two years, with six months non-stop testing, just to get it operational, the city decided that they would contract BAE to build their automated baggage handling system, that would service the entire airport (Office, Testimony Denver International Airport). The system to be designed by BAE was to be the largest automated baggage system ever developed. No one had ever attempted to create a baggage handling system as complex and as large as the Denver Airports. The design had baggage moving at speeds of twenty-four miles per hour (Office, Testimony Denver International Airport). So that no matter where passengers got off a plane their baggage would always be waiting in the baggage pick up area. The system required a network of over a 100 pcs , and included 2,700 photo cells, 400 radio recievers, 59 laser arrays, had 17 miles of track and 5 miles on conveyer belts. On the tracks there would be 3,100 standard size carts, as well as 450 oversize carts. The system would service 88 gates in three concourses (Calleam Consulting Ltd). Many of the technologies needed would be used for the first time in this project, BAE would need to develop some specificly for ther project.

Donald Winans CSC383

Colorado is a major destination for tourists who like to ski. There are many ski resorts, and a lot of traffic to the Denver International Airport would be skiing tourists, once the winter season hit. This reasoning caused Continental Airlines to demand a change in the requirements for the baggage handling system. They demanded that four additional ski claim terminals be added and United decided that rather than two loops through their concourse they would rather have just one loop to service alll of their terminals. Now , both of these requirements changes occurred in August of 1992 and both were made way after the the plan was supposed to be fixed (Donaldson). The requirements contininued to change with Continentals next demand that more ski sort areas needed to be added. They also wanted

and were granted an expansion of the ski claim length form 94 feet to 124 feet. During this time the rest of the airport is under construction, so that every change in the baggage system requirements trickles down to all other plans involviong construction. The requirements again changed in January of 1993, when the ski claim areas were again modified to be from 124 feet down to 112 feet, also at this time it was decided that the system would be much easier to maintain if a special track was built that would allow the cars to be serviced with them on the track. These changes were happening a mere ten months from the origanally scheduled opening date of October 1993. One other major requirements change was made as late as January

Donald Winans CSC383

1994 when United requested modifications to its odd sized baggage areas (Donaldson). By now the opening date had been moved back to March 1994, however it was discovered that a lot of the electrical hardware of the system was being destroyed because the power supply to the airport was not clean and power spikes were frying circuit boards and other sensitive devces. To solve this problem special filters needed to be created, which took a few months (Calleam Consulting Ltd). The problems with the new system became even more evident when the mayor of Denver schedule a prfess conference and a demonstration of the airports futuristic baggage handling system. BAE was not told that they were going to demonstrate the sysytem that day (Donaldson). Itg soon became evident to theworld that the system still had many bugs, including problems with the carts sticking together, and the readers not recognizing baggage on the conveyers (United States General Accounting Office). The media got to see bags riped open and luggage run over, carts fell off the tracks. Soon after the airports opening was called off indefinately due to problems with the baggage handling system. With the automated system litteraly a train wreck, the city decided in July of 1994 to create a back up plan to transfer baggage. It was decided that they would use a traditional approach of carts pulled by tractors. A small portion of the original automated system did run in Uniteds concourse, with only normal sized baggage for outbound flights (Office, Testimony Denver International Airport). The airport finally opened for business in Febuary 1995, way later than the originally planned opening of October 1993. The alternative baggage handling system alone costs $50.6 million (United States General Accounting Office). The total cost of the airport at the time of opening had reached $4.8 billion far beyond the original estimate of $1.3 billion. The automated baggage system was scaled down, but still cost $1.1 million a month just for maintainence costs, which ultimately led to the complete abandonment of the automated system in 2005 (Associated Press). Reasons for Failure The previous section of the paper was an explanation just how the project had failed. In this section wil be an examination of why the project had failed. Some of the most common causes for software failure are unrealistic goals, badly defined system requirements, use of immature technologies, an inability to handle the complexity, poor project

Donald Winans CSC383

management, and stakeholder politics (Charette). These causes are seen in the case of the airport baggage system. The city and the project management team had hired a consulting firm to analysis the potential of adding a fully automated baggage handling system. The results of that analysis showed that it would not be possible to develop a fully functional system in time to have the airport open in October 1993. It was even well known that smaller systems such as the one in Munich, took two years to buildand another six months of testing, to fully operational. Yet, soon afterwards all of this information was seemingly forgotten. While at first the city and the project management team had decided not to build the automated system they did eventually change their minds. What the panning team did not understand when they decided to ignore the initial analysis was that, BAE was using the process model called rapid application development, and in doing so had only created a prototype. The prototype sysytem was all smoke and mirrors, it was not a nearly finished system, as they had believed. Yet, because the planning team believed that they were seeing an actual working version of the baggage system, and this allowed them to set goals that were completely unrealistic. A Swedish naval ship began its maiden voyage as well as its final voyage on an August day in the year 1628. The ship, named the Vasa, never made it out of the harbour (Fairley and Willshire). The Vasas story is not unlike that of the Denver International Airports automated baggage system. They both capsized in part because of requirements creep, in the case of the Vasa it may have been extra guns and decks, in the Denver case it was the constant change to the requirements to add ski pick-ups, the changes to those area, the actual addition of the automated system in the first place, the changes to the system in the United Airlines areas, where they wanted a single loop. Every change caused a slip in the schedule and a redesign of the existing plan. The plan was supposed to be frozen, yet the plan was changed over and over again. Many of the changes could have waited to a later date, when it would be possible to update the system. That had been the original plan in regards to the fully automated baggage system, so modifications could also have been later. Requirements creep is a very common reason for project failure, we have seen it over and over, from the Vasa, to the baggage handling system. We also see an example of poorly defined requirements in the cae of the automated baggage handling system. I believe that a lot of the changes to the requirements were made because nobody really had defined exactly what was needed. BAE had implied that they could build the system quite easily, after building the prototype, either they were just dishinest or more likely those requirements that they were using were incomplete.Look at how

Donald Winans CSC383

the ski areas sort areas had to be changed three times, these all point to poorly defined requirements. The fact that the carts would stick together when colliding, and that the system would lose track of the empty carts, are examples of what happens when the requirements are vague. The reason carts were sticking together was that there were different bumper heights on the many of the carts (Office, B-270920). The use of immature technologies has killed many a project over the years. Anytime you are the first or one of the first you are taking a major risk. BAE took that risk with their automated baggage system. While there had been automated baggage systems in use elsewhere, BAEs sytem was the first of its kind, all the technologies was built or had to be built for this system. The delays caused by the lack of clean power, in which circuit boards were continously destroy, and other equipment damaged due to the power surges. Had the technologies been used prior to this first implementation many months and a lot more dollars could have been saved. Many of the problems the system experienced were based on the fact that no other system like it had ever existed, you can only learn as you go in that case. The airport baggage system was the biggest ever designed ever, in addition to using new technologies, a major risk factor was based on the fact that this was a very complex system. With its seventeen miles of track and five miles of conveyor, and its collection of over a hundred computers this was an extremely complex system (United States General Accounting Office). As soon as that complexity became too much to handle, the project was only able to fail. If the risk from this complexity had been acknowledged early on some sort of mitigatin plan may have been derived to make the complexity manageable. There may not have ever been a way to make this level of complexity manageable, the fact that it took $1.1 million a month to maintain, which eventually led to its shutdown, shows just how unmanageable that complexity actually was. Airport construction began with no airline commited to using it as a hub. With no commitment there existed no assurance that the airport would be able to make enough income to pay for itself. The city of Denver would be stuck with an enourmous deficit. Continental Airlines did eventually agree toa commitment to use the airport as a hub; however they soon declared bancruptcy. With the only committed airline, looking like it would become a deadbeat, the city needed to get more major airline to make an obligation. The threat of no income, let United leverage the city to start changing the scope of the baggage system. The city not only adopted a fully automated system they were told would be impossible to develop in time, they allowed United, as well a Continental to have changes to the system, which

Donald Winans CSC383

ultimately created more delays. This demonstratges just how stakeholder politics can interfere with a project. Poor project management is a hammer that will drive the nail into the coffin of any project. It will not matter how well the requirements are, how well the team and the stakeholders work together, poor project management will lead to every common failure point. Every one of the preceding examples of why the project failed was the direct result of poor project management. Proper project management techniques would have recognozed the risks associated with the various aspects of the plan. A much more effective risk mangement plan would have been implemented. Requirements bloat, would have been seen as that and avoided, even a better understanding of what a prototype was would have made a huge difference in this case. The city may have saved billions in the long run simply by hiring a very expereinced project manager. Even at that prospect poor management failed the project. There was no way this system with its level of complexity could succed with out the very best project management, which it definitely did not have. Conclusions Every unsuccesful project we have looked at throughout the semester whether it be the Vasa, of ther Virtual Case File project, and of course the Denver International Airporta automated baggage system all failed for the same reasons. The degrees to which certain causes turned up in the various projects may vary, but they are always there. By being aware of these root causes you can take measure to avoid them. Developing a good process model and using risk management techniques will help minimize the threat from these causes of failure. You can avoid requirements creep with good metrics collection techniques, such as function point analysis, which help to indicate trouble. The use of metrics can help prevent all sorts of trouble, had BAE used some sort of metrics to measure the complexity of the system that they agreed to create, they may have realized that hey were walking into a trap. Metrics collection is not the only way to avoid many of the problems, an experienced project manager to increase the odds for a succesful project. An experienced project manager may be able to spot those root couses of failure prior to commiting to them. A strong project manager can help keep the focus on the ultimate goal of the project, in the case of Denver, the change of plan to include an airport wide automated system may have been avoided.

Donald Winans CSC383

The use of risk management techniques would also have help prevent the disaster that was the automated baggage handling system. Not only would all the potential risks be indentified, all those serious risks woud have been prepared for. A back up system may have been created along side the main system, so that instead of the airports opening being delayed over and over again, that airport could have opened, while the main system was tweaked. Denver Airports automated baggage system was extremely complex, poorly planned and destined to fail. The project ultimately cost billions of dollars, delayed the opening of the airport for approximately two years, and never actually worked as planned. Had the project management team implemented a better process model things may have turned better. The lessons learned from this example of a project failure can be applied to any software project.

Donald Winans CSC383

Works Cited
Associated Press. Untited Abandons Denver Baggage System; Automated network lost, tore up luggage. 6 June 2005. 5 December 2011 <www.msnbc.msn.com>. Calleam Consulting Ltd. Case Study- Denver International Airport Baggage Handling System - An illustration of ineffectual decision making. 2008. 07 12 2011 <printfu.org>. Charette, Robert N. "Why Software Fails We Waste Billions Each Year on Entirely Preventable Mistakes." IEEE Spectrum September 2005: 42-49. Donal Flynn, Gary Pan, Mark Keil, and Magnus Mehring. "De-escalating IT Projects: The DMM Model." Communications of the ACM October 2009: 131-134. Donaldson, A.J.M. Software Forensics Centre Technical Report TR 2002 01. 02 05 2002. 7 December 2011 <www.printfu.org>. Fairley, Richard E. and Mary Jane Willshire. "Why the Vasa Sank: 10 Problems and Some Antidotes forSoftware Projects." IEEE Software March/April 2003: 1825. Fayad, Mohamed E. "Software Development Process: A Necessary Evil." Communications of the ACM September 1997: 101-103. Gibbs, W. "Software's Chronic Crisis." Scientific American September 1994: 86-100. Office, United States General Accounting. B-270920. 15 March 1996. 05 December 2011 <www.gao.gov>. . Testimony Denver International Airport. 11 May 1995. 7 December 2011 <www.gao.gov>. Swartz, A. John. "Airport 95: Automated Baggage System?" ACM Sigsoft Software Engineering Notes Vol 21 No. 2 March 1996: 79-83. United States General Accounting Office. Denver International Airport Baggage Handling, Contracting and other Issues. August 1995. 07 December 2011 <www.gao.gov>. . New Denver Airport Impact of the Delayed Baggae System. October 1994. 07 December 2011 <www.gao.gov>.

Donald Winans CSC383