Case Study on D.I.a Baggage Handling System Essay

According to the initial plan, the project was to span from 1989 to 1993 and cost $1.7 billion. The opening of the airport was delayed four times due to problems with the baggage handling system. Overall 16 long months and a final cost of $4.5 billion. Several factors contributed to this fiasco, ranging from deficient scheduling, simple and untested technology, complexity of the systems and requirements that changed throughout the project itself. Let us take a look back at why Denver International Airport would take on such a project. The vision was to implement the largest automated baggage handling system the world had seen and allows Denver International Airport to be hailed as the air transportation hub, the largest in the United States with a capacity to handle more than 50 million passengers annually. The airport was to replace the Stapleton International Airport, a facility that had experienced serious congestion issues. Of course in order to handle that kind of capacity part of this plan involved implementing an automated baggage handling system, this was the critical piece of the plan. This report discusses the difficulties encountered as a direct result of a poor project plan, communication and implementation. Analyses have been done by many groups regarding this debacle and the failures itself are examples that are used to show the improper project management that was used. First, let us briefly discuss what tried to be accomplished. The Denver International Airport wanted to introduce a baggage system that when operational would rely on a network of computers (approx. 300) to route the bags and then approximately 4000 auto-cars to drive the luggage on a 21-mile track, completely autonomous. There were to be laser scanners used to read bar codes on luggage with tags and that would route them to the correct terminal or location. Sounds simple enough however BAE was the company that would try to bring this all to reality and would be one of the largest airports built in the United States since 1974. United Airlines was one of the main drivers and reasons for the push for a high-speed automated baggage system (http://www5.in.tum.de/~huckle/schloh_DIA.pdf). This was all requested and scoped early in the planning phase. Now prior to deciding how to proceed the officials had thought each airline would develop its own systems, but this failed to occur so the Airport looked into purchasing a system to handle all terminals baggage. The scope of such a project would not find traditional methods as those were too investigated. A man named Frank Kwapniewski, would be the site project manager â€Å"lucky† enough to call this project his â€Å"baby†. BAE had more than twenty some programmers working undistracted for two years to write software to handle all the automated needs of luggage, the engineers, which took just as long in their initial efforts of development. The initial design’s failures were inconsistency, so BAE sought to reduce such confusion and mishap, and wanted to understand the complex nature, however even a more scrutinous view would have foreshadowed the mishap of making such a large system functionally. Richard de Neufville stated in an excerpt from his book that the theoretical studies, models and reports regarding the automated baggage system at Denver were avoidable and should never be repeated (Neufville). BAE’s design flaws of complexity and the effects thereafter were a result of improper project planning and scope. The complexity of what it would take to operate and control automated machinery was never addressed or fully tested prior to implementation. Even after work ended when it was turned on and expected to work as intended, Denver officials were surprised at how poor it performed even enough to turn off the system. Let us take a moment to look at how complex this system truly was and how BAE design and planning failed to gain a glimpse of what it would take to operate such a daunting task. An empty cart is called and needs to go from one track to another, albeit simple sounding, this type of activity would have had to take place over a thousand times a minute under normal operating conditions. Since there were differences or variances in demand for empty carts throughout the airport, empty ones must continually switch direction, change tracks or completely change to another loop in the circuit. This is a logistics nightmare as one can imagine on such scale, so many variables to account for and they must do it error free. This was not using modern technology but even still it would have had to been almost instant decision making on again an error free basis. Typical systems with around 10k function points are cancelled approximately 65 percent of the time (capers Jones). In Denver, though the system’s workload hindered the network terribly to around 4000 tele-cars or auto-cars. These 1994 computers were tracking so many cars that several times a minute they mis-t racked just simply due to timing limitations. The planning of such a system was again originally contracted by United in 1991 to build, however after several years into it, BAE was concerned that the city of Denver still had not contracted for a baggage system. Sadly, the baggage system was nothing more than an afterthought of the design of the airport, AFTER construction began, let me make sure you understand that AFTER construction had begun and only then did the details surrounding the baggage handling system start to begin. This of course caused major problems due to limitations of resources that were not allocated properly which would contain the baggage system’s tracks and other components. The system then was made to fit in the underground tunnels and space available, not designed. These auto-carts had sharp turns now to make which again was not part of any plan. The schedule that BAE or timetable rather that they had set for the grand opening was not remotely realistic and as all good projects should do, have taken into consideration any potential issues along the way. BAE officials were even quoted as stating â€Å"We knew that was not long enough and we said so. It is a job that ought to take twice as long† (Why Technology Projects Fail). They knew but accepted the timetable of 4 years when they knew it should take 7 to 8 years for such a task. Denver Aviation Director James C DeLong even stated they just misjudged the timeline completely. The project as most will when unrealistic deadlines are given will continue to fall behind more and more, which then calls for more rapid work, longer hours which can lead, as the case here, to human error since the training and testing period were almost non-existent to meet the make-believe deadline. One of the other common misnomers in this project was the frequency and number of changes to its requirements, not a refining of them, but completely adding new functionality along the way. When the company BAE, took on the task, unrealistic as this sounds they took it on with anticipating no changes at all. As soon as work began though, Denver officials began changing plans and timetables without consulting either the airlines or BAE. Sadly, when changes were made to one piece of the system, the ramifications they made to other pieces was not clearly understood or the system as a whole. Again to reduce costs and save time, it was decided to remove an entire loop of track, from one of the concourses, this saved them 20 million, keep that figure in mind as later the system as a whole would cost them much more in the months after being deployed. Other such changes were made to save money, such as relocation of stations and addition of middle sub floor for baggage platforms that they referred to as the mezzanine baggage platform. Another airline also demanded the request for large baggage link. As the project matured, prior to implementation its scope size and complexity, along with design changed which increased the systems difficulties on a technical level that would continually deter progress. BAE then later chooses to decentralize all of the tracking and sorting computers, all these changes to scope should have led to review of alternate or contingency planning or delayed launch dates. However due to the shortened development and testing timetable, on the fly changes which should have required major pushback from core team members were â€Å"duct-taped† as I like to refer to it. One of the directors of engineering for the DIA, stated that BAE should have paid more attention to the programming issues early enough in the design phase. Lack of system testing, what I have I continuously stated all semester long about system testing and end-user testing, as a project manager most would agree, more than 75% of all IS projects are hampered by quality issue and 1 percent which are completed on time. I see reasons behind such statistics is not enough testing. I would advise any IT PMP to read ePMbook which is an online e-book regarding scope and project control, as was the case here a project that started out to be huge, got even bigger and eventually spiraled out of control. The ePM Book will has an excellent section that the BAE, airline and Denver City officials should have read prior to beginning step 2 of the project. They should have implemented any change coming through a request known now as a Change Request form. These forms are used to control the project’s scope and allow for the Project Lead, along with the core team, which requests can and will be made part of the original project and which can be sla ted as next phase or next step after implementation. It almost sounds as if this project never had a Change Control Process (CCP) whatsoever, if it did whoever was in charge of such did a horrible job, this CCP should exist throughout a project. It allows for requests to acknowledged in a timely fashion within a phase, and most important to determine impact in the planning for the next phase. This as stated on the site can be easier than de-railing the entire project due to shortening length of next step phases in the project path due to scope creep. Airlines kept changing the requirements, which resulted in numerous issues. One of the major reasons the whole thing went awry stems from BAE, the company that designed the system had previously implemented a similar system in Germany. The IT infrastructure was inadequate and design was not meant for such a large scale as that at the DIA. Well sadly it was not just a lesson for the DIA, BAE and Denver, but the taxpayers also ended up with a $1 million PER DAY cost, totaling $500 million by the end of the whole ordeal. Remember that 22 million they saved, good thing huh. Now let us think about how more time spent in analysis and design phase, let alone a Change control process, saved Colorado taxpayers millions of dollars. Since every project has a set of deliverables, assigned budget and expected closure time, there are agreed upon requirements and tasks to complete prior to the closure of a project. These constitute a project’s scope. The PMBoK clearly speaks to creeping scope and defines it adding features and functionality without addressing the effects on TIME, COST, and RESOURCES or without customer approval (PMBOK Version 4). References A guide to the project management body of knowledge (PMBOK ® Guide) (4th ed.).(2008). Newtown Square, Pa.: Project Management Institute. Brooks, F.P. (1995). The mythical man month: Essays on software engineering. (Anniversary Ed.). Boston: Addison Wesley Longman, Inc. JOHNSON, K. (2005, August 27). Denver Airport Saw the Future. It Didn’t Work. – New York Times. The New York Times – Breaking News, World News & Multimedia. From http://www.nytimes.com/2005/08/27/national/27denver.html?pagewanted=al lchloh_DIA.pdf Neufville, R., & Odoni, A. R. (2003). Airport systems: planning design, and management. New York: McGraw-Hill. New Denver Airport: Impact of the Delayed Baggage System — GAO/RCED-95-35BR. (n.d.). RITA | National Transportation Library. Retrieved December 6, 2012, from http://ntl.bts.gov/DOCS/rc9535br.html Scope & Change Control. (n.d.). Project Management and Program Management – The FREE ePMbook by Simon Wallace. Retrieved December 2, 2012, from http://www.epmbook.com/scope.htm Wiegers, K. (2003). Software Requirements (Second ed.). Redmond: Microsoft Press. Why Technology Projects Fail. (n.d.). Calleam Consulting – LLC. Retrieved December 1, 2012, from http://www5.in.tum.de/~huckle/DIABaggage.pdf