Software Development Failures [Electronic resources] : Anatomy of Abandoned Projects نسخه متنی

Chapter 3 presented a framework for analyzing cases of abandoned software projects. The following factors were identified as being dominant in cases of abandoned projects dealing with socioorganizational issues:

Unrealistic project goals and objectives

Changing requirements

Lack of executive support and commitment

Insufficient user commitment and involvement

These factors were shown to be particularly critical at the requirements stage of the development process, and mildly critical at the design and implementation stages. (See table 3.4.)

In this section I will use five reported cases of software projects that were either totally or substantially abandoned as a basis for discussing the socioorganizational factors critical to abandoned projects. The five cases—Confirm, Delta, TSM, DIA's BHS, and CODIS—reflect both public and private organizations. The cases represent projects from a consortium of four commercial organizations, a drug distribution company, a large public organization of the U.S. government, a public/private endeavor, and a medium-sized private commercial organization, respectively. The cases are illustrative of the incidence of abandoned projects reported in the public domain. For example, multiple secondary sources of data exist in the public domain dealing with the Confirm, Delta, TSM, and DIA's BHS projects, and the data for the fifth project, CODIS, are based on studies undertaken in the private organization. The examples were selected because each represents a case of abandonment or failure from which one can draw valuable inferences; chapter 3).

Unrealistic Project Goals and Objectives

In the Confirm case, AMR Inc. charged in its suit that the consortium partners failed to "specify exactly what they wanted from the system" and that this "indecisiveness" of the partners had the effect of impeding progress on the project, as McPartlin (1992, 12) reports. In fact, John Mott, who led the Confirm project, is said to have asserted that the four years of Confirm's development involved "continuous debate" because the partners did not "know what they wanted in the first place." However, this claim is vehemently denied by James Yoakum, then chief information officer (CIO) of Marriott, who claimed that before the start of the project the other three partners provided AMRIS with a detailed list of specifications defining exactly what they wanted (McPartlin 1992). It is difficult, if not impossible, to verify which of the Confirm partners is right on this point, but it clearly shows there was no apparent consensus on what the goals and objectives of Confirm should be prior to the start of the project, other than the very vague and rather broad assertion that Confirm would constitute the first reservations system of its kind, combining airline, hotel, and car rental operations (Halper 1992a, 1992b, 1992c).

In its suit against Andersen Consulting, the bankruptcy trustee for FoxMeyer Drug charged that the Delta project was intended to be a technologically advanced, state-of-the-art distribution system. The overarching goal of the Delta project set by management was to "push the technological envelope, and to do it fast" Bulkeley (1996, 2). The FoxMeyer chief operating officer (COO) who was reported to have championed the ambitious project indicated that the fast pace was needed and promised that within three years the company would be able to "accelerate sales growth without proportional increases in head count and operating expense, automating functions that now are manually driven, and improving the quality of our service" (Bulkeley 1996, 2). This unbridled optimism was shared by FoxMeyer's top management to the extent that they are reported to have "recklessly underbid contracts, expecting electronic efficiencies to lower costs enough to make the deals profitable" (Bulkeley 1996, 2). All of this was against the advice of their own independent consultant, who urged a slow approach, knowing full well the risks involved in undertaking a project of such magnitude and complexity. In addition, the consultant noted that SAP R/3 was really designed for manufacturing operations and in his view lacked "many features for the wholesale distribution business," as Bulkeley (1996, 2) also reported in his Wall Street Journal article. In time, when the computerization failed to realize the anticipated goals and benefits, the COO was removed by the board to atone for the errors and misjudgment of all top management.

The TSM, critics charged, had not created a comprehensive plan or blueprint outlining "what the system is supposed to do and how it would work," as the Los Angeles Times reported "IRS Computer Project Has ‘Very Serious Problems,’ Rubin Says," (1996, D1). This charge was echoed by Treasury Secretary Robert Rubin and by Representative James Lightfoot, chair of the U.S. House Appropriations Committee. In fact, Secretary Rubin was reported to have remarked that what existed or could be passed for a plan was rather a highly technical 6,000-page document that was not for a general readership. Most observers felt the project, was "too grand" and, furthermore, that the IRS had failed to prioritize the TSM projects, insisting that the projects were all of equal importance. This failure to prioritize the projects, was later cited by the GAO not only as "unrealistic" but also as potentially dooming the projects to be "generally unattainable." (GAO, 1995).

The BHS project, which is critical to the efficient operation of the new DIA, was inexplicably not part of the build-design plans until several months into the construction. Initially, DIA project leadership—that is, the city of Denver management—decided to leave the baggage handling details to the individual airlines. Unfortunately, none of the airlines using the old airport had committed themselves to using the new DIA, and consequently the baggage handling part of the DIA design was neglected. It was several months into the construction of DIA that first Continental Airlines and later United Airlines signed on to use the new DIA. It was only then that the DIA authorities, realizing that none of the potential airline users of DIA had committed to the design of a baggage handling system (with the exception of United Airlines, which had contracted with BAE for its concourse), moved to address this omission in the build-design plans of the airport. At that time sixteen bids were solicited from various companies for an airportwide automated baggage handling system. Of the sixteen companies solicited for the BHS project only three responded, excluding United Airlines' BAE company. However, none of the three responding companies was judged by the consulting firm asked to handle that task to be capable of undertaking a project of such magnitude and complexity within the time available before the airport was officially to be opened for operation. Thus it was quite late in the construction of DIA that United Airlines' baggage handling company BAE was brought in to undertake the BHS project. After several days of intensive negotiations between BAE and DIA management, the parties agreed on rather stringent conditions to provide BAE ease of access to facilitate its work and to make up for the time lost due to DIA's earlier inaction on the problem.

DIA management requested an automated integrated baggage handling system to serve the needs of all the airlines that would be using the new airport. The BHS was touted as the "most complex automated baggage system ever built" to "direct bags …from the main terminal through a tunnel into a remote concourse and directly to a gate" (Montealegre et al. 1996, 9). The efficient operation of the BHS for the entire airport was to be the hallmark of the DIA, enabling the airlines to maximize their hub operations and decrease the turnaround time for their aircraft.

Although the goals and objectives of the project were clear, the time frame in which the project was to be realized, coupled with the stringent conditions and operating environment in which the project was initiated, created much uncertainty. United Airlines, which had previously contracted with BAE to build the baggage handling system for its concourse, rightly anticipated the level of complexity involved in the project and estimated its completion to be no later than two and one-half years away. Yet when the BHS was expanded to cover the entire airport, the completion-time issue was not appropriately or adequately addressed. Instead, it was hoped that by placing "a number of conditions" on the contract—dealing, for example, with the freezing of dates for changes to software and giving BAE unhindered access to work sites—the project goals and objectives could somehow be achieved before the targeted opening day of the airport. With hindsight, it is apparent that consensus on project goals and objectives was not sufficient to guarantee project success. In this case, the other mitigating forces, namely, the size and complexity of the project, were so powerful that they conspired to nullify whatever benefit consensus on project goals and objectives conferred on the project. DIA management's failure first to deal with the baggage handling issue and then to make a realistic assessment of the time required to complete the project ensured that the state-of-the-art BHS would not get off the ground.

The data in the CODIS project suggested that although there was general agreement in the organization regarding the need for a new IS, there was no clear statement of what the new system's goals and objectives should be in order to satisfy the company's specific information requirements. The vice president of marketing, one of the project's participants, is reported to have indicated that "there were no firm, established goals and moreover no real consensus on what those goals should be." The only consensus existing at the time was that "the company was functioning with brute force—good people working very hard with little computing or information technology" (Ewusi-Mensah 1998, 7).

I have already reported elsewhere (Ewusi-Mensah 1997, 76) that "it is imperative that firm goals or objectives be established for the project to guide the information requirements phase of the development process. Failure to satisfy this aspect of the project is likely to lead to fragmented efforts, and lack of team focus in assembling the facts to guide the rest of the development," as was the case in CODIS. Consequently, lack of "clear, measurable goals" at the start of the project is likely to lead to a vague set of systems requirements that can be harmful to the success of the project, as Curtis, Krasner, and Iscoe (1988) found in their study of large-systems design. I have further reported that "projects may still be canceled if the goals articulated as attainable in the original requirements document prove illusive," especially with changing requirements, which was the case in the Confirm project (Ewusi-Mensah 1997, 76). It is equally important that the goals specified not be perceived as overly broad or ambitious. In addition, the goals should be judged to be doable and within the capabilities of the project team. The Delta, TSM, and DIA's BHS were particularly vulnerable to this charge of being overly ambitious. The lack of priorities in TSM also worked against its success in the long run.

Changing Requirements

Changing requirements may at times be a manifestation of a lack of consensus on goals and objectives prior to the start of the project. However, even when goals and objectives are agreed on before the start of the project, new clarifying information may be encountered at a later date that may cause changes to be made in the existing requirements and that thus may set the development process somewhat further back. Changes to requirements are, therefore, inevitable in any software development project. Because the more critical issue of concern is the frequency and intensity of those changes as the project proceeds through the development stages, there is always a need to control for such changes, which have the potential to wreak havoc in the development process.

In the Confirm case, Marriott charged in its suit that AMR began to eliminate functions from the system to help speed up the development process. AMR of course dismissed this charge as frivolous because it was confident that the project would come in on time (McPartlin 1992). Overly ambitious projects can be characterized by this problem of inevitable changes in the requirements as further knowledge of the problem domain is gained, and as what is and is not feasible is discerned. For example, the TSM project was criticized as being "too grand," which may have played a role in the problems it encountered in, for instance, developing a blueprint to guide the development process. On the other hand, CODIS is illustrative of a project where the lack of consensus on what to do led to a scattershot approach to the development and the eventual, inevitable failure.

In May 1993, following the collapse of Phar-Mur Luc, a Midwestern pharmacy chain responsible for 15 percent of FoxMeyer's revenue stream, its top management felt added pressure to make up for the lost business and ensure its survival. As a result, FoxMeyer aggressively pursued University Health System (UHC) Consortium, a national network of major teaching hospitals, by underbidding the contract, expecting to make up for the smaller profit margin with the increase in volume they felt was assured by the Delta project. The successful acquisition of the UHS contract, however, set in motion a stream of actions that necessitated changes in the original requirements for SAP R/3 implementation. For example, because UHS hospitals are scattered across the United States, it required the opening of six new warehouses in the West. In addition, the implementation schedule had to be shortened "to get parts of the SAP financial software running three months sooner than planned" to accommodate the requirements of the UHS contract (Bulkeley 1996, 3). FoxMeyer's own CIO admitted that "the new contract [i.e., UHS] increased the difficulties of the already-ambitious plan" (Bulkeley 1996, 3). This fact is echoed by Jesitus (1997), who reported that the SAP contact on the project indicated that the new contract introduced a significant change in FoxMeyer's business. It added to the problems of Delta, because the focus of the project changed drastically from the original specifications to ensure that the UHS consortium's needs could be satisfied.

After the hasty start on the BHS by BAE, it was inevitable that the individual carriers would make changes to the specifications for the airportwide integrated baggage system drawn up by the DIA planners and consultants (once they committed to the project). While this was to be expected, the frequency of the changes and the set of problems they in turn introduced with respect to, for example, coordination with other contractors working in other areas of the airport for which BAE needed unimpeded access for its equipment, materials, and workers, was not anticipated by the project team and DIA management. Additionally, the freeze dates for changes to the design of the mechanical parts and the software involved, which BAE and DIA authorities had painstakingly negotiated, proved hollow and unenforceable, thus introducing another layer of problems to the project. For instance, after BAE took over the BHS for the entire airport, United Airlines requested design changes from its original specifications such that an entire loop was removed from its original two complete loops of track. This change saved United Airlines $20 million in its contract; it also required a redesign of the BHS, in the United Airlines section of the airport. As Rifkin (1994, 113) reports, "a flood of changes followed," including, for example, "relocation of outside stations, addition of a mezzanine baggage platform and Continental Airlines' request for a far larger baggage link." No sooner had these changes been acceded to than more requests came in. The head of BAE complained that six months prior to the airport's opening, requests for changes in software design, controls, and movement of equipment were still being dealt with across the board (Montealegre et al. 1996). In a complex system any change in design in one section is bound to have ripple effects on other sections of the project, which would require additional time and resources to tackle. Thus controlling for the frequency of the changes was a prerequisite to the project being completed on time. The DIA authorities painted themselves into a corner when they failed to heed the advice of their own consultants, other companies, and the technical advisors of the Munich Airport that BHS was so complex that "there was not enough time to build such a system" (Rifkin 1994, 113; Montealegre et al. 1996). Munich airport was contacted because of its experience in implementing an automated baggage sysem, albeit one that was considered much lesss complex than DIA's BHS (it is also the sister airport of DIA). It was therefore inevitable that, in order to accommodate the airlines, DIA and BAE agreed to changes in the design, which further delayed the completion schedule.

This factor is, quite frankly, tied to the project goals and objectives factor in the sense that both are linked to the issue of requirements for the system. Whenever there are excessive changes in the requirements resulting from, for example, ambiguous or ill-defined goals and objectives, or incomplete requirements resulting from lack of understanding of the problem domain, the rest of the development process may be affected. Depending on how far down in the life cycle the requirements changes occur and how extensive they are, the repercussions for the development may be severe, affecting cost and schedule estimates alike. In extreme cases, they may even cause the project to be abandoned altogether, as DIA's BHS case illustrates.

Lack of Executive Support and Commitment

The need for the active commitment and involvement of senior management in software development projects is well documented as a canon of good practice. Senior management provide the necessary resources for the project, and their commitment and involvement are viewed as evidence of their support for the goals and objectives of the project and its contribution to the larger or broader organizational strategies. On the other hand, "If senior management fail to become actively involved in monitoring progress on the project" or otherwise fail to become informed "on what is going on with the project on a regular basis, it is likely that small unresolved problems will compound over time and eventually contribute to the project's termination" (Ewusi-Mensah 1997, 78).

As reported in Ewusi-Mensah 1997, "The failure of senior management in the Intrico consortium to be actively engaged on a more frequent basis in the development of Confirm" was cited by one AMRIS executive as partly to blame for the failure of the project. The AMRIS executive stated: "Confirm's ‘fatal flaw’ was a faulty management structure in which no one group had ample authority over the project. …You cannot manage a development effort of this magnitude by getting together once a month… . Had they allowed the president of Intrico to function as CEO in a normal sense and empowered their senior reps [to] work together with a common goal and objective, it would have worked. …A system of this magnitude requires quintessential teamwork. We essentially had four different groups… . It was a formula for failure" (p. 78).

The top executives of FoxMeyer Drug were actively committed and involved, perhaps even overcommitted to the success of the Delta project. As Bulkeley (1996) and Jesitus (1997) both reported, prior to the initiation of the Delta project, the board of FoxMeyer Drug as well as its COO realized that their current aging Unisys mainframe was not capable of handling the anticipated growth in the business. Consequently, they embarked on a search for a client-server-based system to do the job. This decision eventually led to the acquisition of SAP's R/3 software and its subsequent implementation on HP clientserver hardware. FoxMeyer Drug hired Andersen Consulting to do the systems integration work based on the forceful representation the consultants made as to their level of expertise, experience, and resources for undertaking the arduous task (Bulkeley 1996; Jesitus 1997; LJX files, 1998).

Because top management saw the future of the company as being intrinsically interwoven with the success of the R/3 implementation, they perhaps did not pay adequate attention to other telltale signs of the potential for failure and thus became overly committed to the project until it became too late to withdraw. Their overcommitment to the Delta project caused the top executives of FoxMeyer—in particular, the COO—to lose their objectivity and thus fail to pay attention to the problems that their systems people were reporting with regard to the overambitious project. Systems people working on the project realized that it was not "appropriate to criticize SAP" because they were systematically "encouraged to minimize problems" (Bulkeley 1996, 3).

Another outcome of top management's dangerous overcommitment to the Delta project was their unwillingness to listen to the cautionary advice of their own independent consultant, who felt the schedule Andersen proposed for completing the work, even before the UHS contract was signed, was too ambitious and unrealistic (Jesitus 1997; Bulkeley 1996). The bankruptcy trustee charged that FoxMeyer was repeatedly "coerced" into paying additional fees to Andersen even when the "completed" work was riddled with flaws/bugs that needed to be fixed at the consultant's expense, demonstrating the extreme reluctance of top management to give up on the failing project (LJX files, 1998).

For TSM there is not sufficient documented evidence to attest to the extent of executive involvement. Consequently, we are left to infer the existence and nature of such high-level involvement and commitment from other sources. For example, Treasury Secretary Robert Rubin, the Los Angeles Times reported, had pledged to increase top-level attention to the project and to have it handled "much like a chief executive at a private corporation overseeing a major problem" during his appearance before the House Appropriations Committee ("IRS Computer Project Has ‘Very Serious Problems,’ Rubin Says," 1996, D1). At that meeting, Secretary Rubin was also reported to have announced the appointment of a new chief to head TSM with the experience and expertise to tackle the problems. All of these apparent senior-level activities with respect to TSM should have occurred throughout the project's development as evidence of senior-level support and commitment to the project, and to signal to the rest of the TSM project teams the strategic value of the project to the Treasury Department. The fact that these organizational changes were being discussed several years after the TSM project had started, while it was facing severe criticisms from Congress for its failures, showed at least that the project did not enjoy the kind of topmanagement commitment and support traditionally associated with a project of such magnitude in an organization.

As in the case of FoxMeyer Drug, the failure of the BHS to come in under budget and on schedule was not due to a lack of commitment and involvement by DIA's senior management, which included the mayor and other elected officials of the city of Denver. The case can be made that the apparent attempt by the city council to manage the project after the untimely death of the chief airport engineer—instead of assigning to his successor all the autonomy and authority to make decisions involving, for example, access control by BAE and other related issues—may have played a part in the difficulties BAE had in completing the project. Because the chief airport engineer had autonomy and authority granted by his stature in the organizational hierarchy of DIA, he was able to cut through any bureaucratic bottlenecks and provide the necessary assistance needed by BAE. Unfortunately, that level of decision-making authority was never conferred on his successor. So although she had some construction experience, it is not surprising that she was not able to achieve the same results as her predecessor.

The politics associated with the entire airport construction endeavor were also a significant factor in the problems encountered in the BHS project. DIA was a project on which much of Denver's political elite had staked its future, ranging from the mayor (who started it all with a campaign promise) to his successor (who inherited the built-in constraints associated with the project). For example, the revenue bonds the city used to partly finance the airport assumed the "date of beneficial occupancy" to be January 1, 1994, with the bond repayments scheduled to begin on that date. At the time the city believed it could meet its bondrepayment obligations if DIA opened no later than October 31, 1993 (Montealegre et al. 1996). Mayor Wellington Webb's failure to heed the advice of consultants and technical advisors with respect to the near impossibility of the BHS being completed by the time DIA was originally scheduled to open may have been for political purposes. Denver politicians' desire to please their constituents may have led them to jettison some of their objectivity regarding the readiness of the airport and the feasibility of completing the BHS project on schedule. For example, despite all indications that BHS testing was far from complete and that there were several bugs in the system that had to be fixed, the city of Denver in late April 1994 invited the news media (without BAE's prior knowledge or consent) to observe the first test of the baggage system, which turned out to be a major failure and embarrassment (Montealegre et al. 1996; Rifkin 1994).

The commitment and involvement of senior management of the DIA were in this case somewhat misplaced. The political elite would have served the city and citizens of Denver better if their role had been one of active support and participation, leaving management of the technical issues surrounding the BHS project to the people trained to handle such complex matters.

For CODIS, there is evidence to suggest that senior management failed to "request and enforce regularly scheduled management review meetings to monitor progress" on the project. As a result, senior management had no firsthand knowledge of the development process at any time and thus could not be informed of the possible completion time for the project. Consequently, far more resources were expended on the project than could be justified, as noted by the marketing director when he commented on "the inability of senior management to recognize they had a problem and delayed decision on it for so long" (Ewusi-Mensah 1997, 78). This lack of involvement led to delayed decisions on major issues, such as replacement of the nonperforming MIS director. Again, the marketing director commented that "Pete should have been let go sooner, and the MIS area should have been reorganized to deal with the project and its related problems earlier."

In both the Confirm and CODIS projects, senior management appeared to have been lax in managing the development by their conspicuous lack of commitment and involvement to the projects' outcomes. Specifically, in the case of Confirm, the lines of authority and responsibility for the success of the project were blurred, leading unavoidably to the passing of blame to others and failing to take decisive actions in situations where such actions would have advanced the course of the project. An additional factor may be the potential conflict of interest among the various stakeholder groups forming the consortium and, in particular, between AMRIS as project developer and the rest of the consortium. For example, AMRIS executives accused the other three partners in the consortium of failing to ask for copies of an IBM consulting report, which, it was suggested, carefully detailed problem areas that eventually contributed to the failure of Confirm. Finally, the other three partners accused AMRIS project management of "promising anything to keep the project moving" (Zellner 1994, 36). On the other hand, the Delta and BHS projects are examples of overcommitment on the part of senior management, impairing their objectivity and contributing to the difficulties the projects experienced.

Senior management, Krault and Streeter (1995, 80) have suggested, are supposed to be the "major beneficiaries of formal management procedures" in the software development process and are expected to use the procedures to gain feedback and exercise control over the process. In the cases of Confirm, TSM, and CODIS cited here, it is apparent that the requisite senior management involvement described by Krault and Streeter was nonexistent, which contributed immeasurably to the problems of cost overruns and schedule delays faced by the projects and led to cancellations in the long run.

Insufficient User Commitment and Involvement

The key role of users in the development of organizational software is widely accepted in the software industry. Users can become involved in the development process as participants in formulating the requirements and in helping the software personnel understand the users' problem domain. Users can also become involved by their continuous interaction with the systems personnel throughout the development process. The extent of the users' participation and interaction with other stakeholder groups in the development process may signal the depth of their commitment to the project's outcome. Through the study of users' views on systems development, I have suggested elsewhere that while user involvement in development projects is necessary, it is not a sufficient criterion for project development success (Ewusi-Mensah 1998). However, there is a significant risk of project failure, even abandonment, if the involvement in and commitment of users to the project are lacking.

In each of the cases under discussion there is no specific, direct information, except possibly with respect to CODIS, of users' active participation in the systems development process. For example, in the Confirm case the first mention of users in almost all the reports was when the system was initially beta-tested at the Hilton site in early 1992. This, of course, is not confirmation of a lack of users' involvement in the Confirm project; however, one is left to speculate as to the nature and extent of their involvement, if indeed they participated in the development of Confirm. The TSM systems also present a muddy picture of the nature of users' involvement in the entire development process. The GAO reports, for example, that in the area of requirements management, the involvement of the customers—that is, the users—has been rather limited and consequently has not had any appreciable influence on TSM systems (GAO, 1995, 36). The CODIS project is the only one of the three where active user participation in the development is documented. The users were the initiators of the project, and they stayed engaged through their constant interaction with the process until the end (Ewusi-Mensah 1998). Indeed, the CODIS project confirms the proposition that user involvement is, other things being equal, necessary but not sufficient to ensure successful systems development.

In the FoxMeyer Delta project, user involvement in the warehouse operations occurred when the frequent and persistent breakdown of the system forced users at the warehouse to carry out the tasks that were originally intended to be fully automated as a result of implementing SAP's R/3. However, prior to the implementation of the new system, employees at other warehouse locations where job layoffs were reportedly anticipated left in droves, making the entire warehouse operations vulnerable to the persistent system breakdowns (Jesitus 1997; Bulkeley 1996). Thus, although users are not explicitly cited in any of the sources on the Delta project, it is safe to surmise that they were probably never consulted on the viability or feasibility of the project and on what they could contribute to its successful completion. Both Bulkeley (1996) and Jesitus (1997) reported that one of the problems FoxMeyer faced that contributed to the delays was the unanticipated en masse departures of workers from Ohio warehouses, which the Washington Court House (i.e., the main warehouse) center was supposed to replace. It is apparent that once the workers realized their livelihood would be threatened whenever the Delta project became fully operational, they decided to leave rather than wait to be fired by management. The abrupt departures of many workers needed to handle the initial implementation stages of SAP for the UHS consortium imply that the workers were uninformed of the effect of Delta on their job security. The labor problems generated by the mass resignations could perhaps have been minimized if the workers had been fully consulted on the project and made to feel part of the decision-making process. There are no reports in the available and reviewed records to indicate that such an action was taken by management.

The decision to implement the airportwide integrated baggage handling system was made entirely by the DIA authorities without any participation from any of the potential users of the DIA project. To complicate matters further, the decision to construct the BHS was made in late 1991, when the DIA project was several years past the planning stage and construction had already begun. Originally DIA authorities left decisions involving baggage handling to the potential air carriers of the various concourses. It was only two years before the airport itself was scheduled to open when no carriers (except United Airlines) had contracted for baggage handling systems that the city scrambled to rectify the problem.

The BHS project was an example of top-down decision making with emphasis on cost containment and accelerated scheduling intended to catch up with the completion time frame dictated by the bond market. The city of Denver and its agents on the DIA project never asked the airlines for their direct involvement in the decisions of BHS in the initial stages. This singular failure to involve the air carriers, in particular United and Continental, in the design, and implementation decisions of BHS from the beginning resulted in frequent design changes and contributed to increased costs as well as to further delays in the completion of the airport. The air carriers as important stakeholders in the successful outcome of DIA and, of course, BHS should have been assiduously courted with incentives to gain their support and commitment in the early stages of the planning, design, and implementation of DIA and the BHS project. The problems subsequently experienced could have been significantly reduced.