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

chapter 5 that bear directly on those problems.

The dominant abandonment factors that comprise the economicfactor category discussed in the framework of chapter 3 and listed in table 3.3 are:

Cost overruns and schedule delays

Unrealistic project goals and objectives

Changing requirements

The last two factors—unrealistic project goals and objectives, and changing requirements—have been discussed in conjunction with the socioorganizational and sociotechnical factors that bear on decisions to abandon the projects. The factors resurface here because of the direct economic impact they have on the project's outcome. For example, the scope of the project—that is, the functional specifications derived from the project's goals and objectives—will be fundamentally relevant in estimating the cost of the project and its tentative completion schedule. To the extent that changes in the project's scope will lead to changes in the requirements for the project, such changes will most likely have implications for the estimated project cost as well as for the completion schedule.

As such changes become frequent and have wider impact on the rest of the development process, the overall cost of the project will be duly affected, and so will the completion schedule. Thus, in essence, such changes may be at the root of the escalating project costs and schedule delays. The breadth and depth of such changes in the requirements necessitated by a changing or unstable project scope and/or ambiguous or overly ambitious project goals and objectives have a direct impact on the sustainability of the cost estimates and time-of-completion schedules.

However, regardless of the loci of such changes in project costs and/or time of completion, the evidence in some abandoned projects is that cost overruns and schedule delays may contribute to the project's eventual termination. Evidence from other studies confirms that for about half of the respondents to a survey, the cost of the project and the time of completion do "not seem to play any significant role in subsequent decisions to abandon those projects" (Ewusi-Mensah and Przasnyski 1991, 77).

Cost Overruns and Schedule Delays

The Confirm project presents us with a classic example of escalating project costs and time of completion. Analyses by Oz (1994) and Flowers (1997) provide us with the chronology of the facts with respect to project costs and schedule delays. The cost of the project was originally estimated to be $55.7 million in April 1988 with a completion date of June 1992, and was later revised to $72.6 million in September 1989. The latest cost figure was subsequently revised to $92 million in February 1991, and the completion date was pushed back to March 1993. This trend in escalating project cost continued until the project was canceled, as Oz (1994, 32) reports: "In July 1992, after three-and-a-half years, and after spending $125 million on the project, the Intrico consortium disbanded." It was during the period outlined above that "some of the failure… due to bad management practices of all the four partners in the Intrico consortium" occurred, as Oz notes. For example, it has been reported that "the client-partners team met with the developer's representatives just once a month [emphasis added]." This apparent shortcoming was later cited by AMRIS executives as a major contributor to the problems leading to the eventual cancellation of Confirm. An AMRIS executive is quoted as saying that "you cannot manage a development effort of this magnitude by getting together once a month."

The IBM review undertaken in April 1989 confirmed that this was evidently the case. Indeed, the IBM team found, in addition to other problems, that "project management was perceived as promising anything to keep the project moving" (Zellner 1994, 36). In fact, it is reported that Marriott alleged in its suit that AMR engaged in endless delays and cost overruns and, furthermore, that there was a deliberate attempt in the upper echelons of AMR to conceal "Confirm's countless problems from the rest of the consortium" (McPartlin 1992, 12). Sources familiar with Confirm indicated to McPartlin that "the development schedules were overly optimistic [emphasis added] and relied on outmoded and unrelated technologies that were not up to the task."

The FoxMeyer Delta project also experienced escalating project costs and schedule delays. The bankruptcy trustee provided a detailed analysis of the "coercive" tactics it alleged Andersen used to prolong the project while billing FoxMeyer for defective work that needed to be corrected at Andersen's expense. For example, the original contract estimated an ambitious completion schedule of eighteen months at an estimated cost of $15 million. Yet as the suit states, by the time of the bankruptcy filing in August 1996, Andersen had collected "approximately $30 million in fees, representing a 100 percent increase over its $15 million estimate" (LJX files, 1998, 51).

The fees and schedule escalation came about as Andersen repeatedly threatened to pull its personnel from the project and thus to cease all work on it unless FoxMeyer acceded to Andersen's demands to sign a letter Andersen had drafted indicating completion of various portions of the project FoxMeyer claimed were in fact not completed, and to pay Andersen several hundred thousand dollars for "remedial work" in July and August 1995.

Approximately eighteen months after Andersen began work on the Delta project at a cost of a $1 million per month, FoxMeyer felt it "could neither abandon the project entirely nor engage a new consulting firm to pick up in the middle" (LJX files, 1998, 54). Consequently, FoxMeyer felt compelled to give in to Andersen's demands rather than risk abandoning the project. Still, the trustee claimed in its suit that Andersen failed to convert even one of the remaining seventeen non-UHC warehouses at the time of the bankruptcy filing in August 1996, which was estimated to be "a full year after Andersen first announced its purported solution to SAP's volume problems" (LJX files, 1998, 58). The facts of the case as summarized above from the trustee's perspective are similarly described in the reports by Bulkeley (1996) and Jesitus (1997), with the exception of the alleged coercive tactics Andersen used to extract concessions from FoxMeyer.

As observed earlier in this chapter, issues of cost overruns and completion delays are almost always symptomatic of deeper problem(s) in the project. It is apparent that in this case the original schedule and cost estimates were overly optimistic and unrealistic, given the following conditions: the limitations of SAP, which was originally designed for manufacturing operations; the need for the system in distributed warehouse operations to "handle hundreds of thousands of transactions daily" (Jesitus 1997, 34); the newness of the SAP R/3 technology/system both to Andersen—its representations of expertise and experience notwithstanding—and to FoxMeyer's in-house staff; the changes in the requirements brought about by the acquisition of the UHC contract; and the enormous difficulties associated with the integration of three disparate technologies—the Unisys-based mainframe system, the SAP R/3 system, and the warehouse computerized automation system—difficulties that were grossly underestimated. All of these factors made cost overruns and schedule delays on the Delta project inevitable.

The TSM project was proposed in late 1986 at an estimated cost of $8 to $10 billion with a scheduled completion date in 2001. In fiscal year 1995, the GAO reported $2.5 billion of the budget had been spent or obligated, and an additional $1.1 billion had been requested for fiscal year 1996. However, the GAO reported in January 1995 that the IRS advised the House Budget Committee that TSM would cost about $13 billion to develop and operate. This figure was based on an October 1992 TSM cost model, which the GAO found unreliable because it did not adequately reflect the systems added to TSM since that time and, in particular, "changes in TSM systems development methods." In March 1996, the Los Angeles Times reported a revised figure of $20 billion for the modernization of what it termed the IRS's "badly outdated computer systems" ("IRS Computer Project Has ‘Very Serious Problems,’ Rubin Says," 1996, D1). In the same article, the Secretary of the Treasury, Robert Rubin, was reported to have acknowledged that there was as yet no comprehensive plan for tackling the problem. Up to that time approximately $4 billion was reported to have been spent on TSM, yet there was "basically nothing to show for it," as Representative Lightfoot, chair of the House Subcommittee on Treasury, Postal Services, and General Government, of the Committee on Appropriations (which approves IRS funding), was reported to have remarked (Anthes 1996, 28).

The cost of the BHS project was estimated to be $195 million, the figure BAE agreed to in the contract to build the airportwide integrated baggage handling system. BAE signed the contract to complete the project within about two years under some specified conditions including, according to DiFonso, an agreement that the design would not change beyond a certain date and that "there would be a number of freeze dates for mechanical design, software design, and permanent power requirements" (Rifkin 1994, 113). The city also agreed to provide BAE with unrestricted access to work areas for its equipment and personnel to install needed systems in order to meet the tight deadlines for BHS's completion.

All of the above conditions in the agreement were hammered out with the support, cooperation, and active participation of the chief airport engineer, who had been a strong proponent of the integrated airportwide baggage handling system. But soon after BAE began work on the project in April 1992, the carriers asked for a number of design changes. For example, United Airlines requested changes to its concourse, reducing its original two loops to a single loop track, saving $20 million from its share of the cost. Continental Airlines requested "a far larger baggage link," and a host of other changes that required redesign of the system, adding to the schedule changes and increases in cost of the BHS.

On the issue of unrestricted access for BAE equipment and personnel, Rifkin (1994) reports some disagreements as to what the understanding was between BAE and the DIA authorities. However, what is not in dispute is the fact that until the death of the chief airport engineer, who played a crucial role in the talks to convince BAE to accept the contract, work proceeded quite well without much friction. But soon after Slinger's death, the problems concerning access surfaced and contributed to work delays, because his successor was not able to exercise Slinger's considerable influence to move the project along. After BAE lost its most powerful ally and champion in DIA's senior management ranks, its problems with the implementation of BHS began to spiral out of control, to the point that the mayor called a press conference to give a demonstration of the BHS, reportedly without even notifying BAE about it. The situation became so poisoned that the city and BAE ceased communicating with each other. The city eventually hired a consultant to assess its options; this led to the development of a backup baggage system and a request for BAE to pay a penalty of $12,000 a day for the numerous delays in completion of the BHS and postponements of the opening day for the DIA, in addition to paying for the backup baggage system at a reported cost to the city of $50 million. Naturally, as is almost always the case in such software development project failures, BAE countersued the city and, of course, the major carriers had their legal departments research their rights and options in future litigation involving the cost overruns and project delays.

What is unfortunate in the above scenario is that the BHS project might not have come to such an end if a number of prudent steps had been taken by the city and BAE early on to avoid the problems that ensued. Missteps included the failure of the city to include the baggage handling system in the initial planning stages of DIA, assuming that it would be the primary responsibility of the carriers using the concourses; the failure of both the city and BAE to recognize the major impact of the design changes on the final project outcome in terms of cost and time of completion; the failure of BAE executives to comprehend the size and complexity of the BHS project as being beyond anything in their past experience and therefore requiring considerable effort on their part; the failure of both BAE and the city to recognize that the tight deadlines required a different approach to managing the project than would have been the case under normal circumstances; the failure on both sides to anticipate loss of critical personnel who might be champions of the BHS project and to put in place mechanisms to ensure seamless transitions for their replacements. All of the above factors conspired to doom the project from the beginning.

In the case of CODIS, we do not have figures indicating what the estimated project cost and completion schedule were prior to the start of the project. This was not unexpected or surprising, given that the project was never treated as a new project proposal for which separate funding was requested. Instead, funding for CODIS was handled as part of the MIS department capital expenditure. Moreover, in the view held by the new director of MIS hired to develop CODIS from scratch, the project evolved, in essence, as a series of "fixes" to an already badly outdated system. He complained about the outmoded practices he encountered in the project group, which failed to approach the new project development as being separate and distinct from regular systems maintenance operations within the organization. Despite those misgivings, funding for the project was never considered problematic in the organization because it was prepared to spend whatever was needed to get the project completed, due to the importance it attached to the project with respect to the company's future growth and survival (Ewusi-Mensah 1998).

It can be inferred from the preceding discussion that economic issues, in the absence of other compelling contributing factors, may not be sufficient to cause a project to be discontinued. In fact, projects may be discontinued in instances where the expended project cost and time schedule are below the budgeted estimates. It is considered sound management practice to "know when to pull the plug" on a project that may not be over budget and/or behind schedule in order to conserve organizational resources on a problematic development process.

However, projects may be abandoned because the original cost and schedule estimates were badly flawed and/or because the cost overruns and schedule delays reflect deeper problems uncovered during the course of the development process (Ewusi-Mensah and Przasnyski 1994, 1991). For example, analysis of the Confirm case has shown that the underlying causes of the escalating project costs and schedule delays are primarily bad project management and decision making, as well as reliance on inadequate or inappropriate technology. In the TSM and DIA's BHS projects, the escalating costs and schedule delays can be attributed to a variety of factors including, but not restricted to, inadequate planning and inappropriate oversight in a highly bureaucratic organizational setting. Furthermore, Delta, TSM, and DIA's BHS were overly ambitious and highly innovative projects, the successful outcome of which depended on a technology base and technical skills and experience on the part of the project teams that were nonexistent in the FoxMeyer, IRS, and BAE cases, respectively, as noted in the previous two chapters.

The cost overruns and schedule delays were just inevitable manifestations of those problems. Unfortunately these are the issues that consistently rise to the surface, burying the real culprits: the problems that gave rise to them. This situation is not surprising, because the technical issues involved in software development are often elusive and opaque to senior management (leaving aside issues of cost and schedule completions). Cost and schedule issues are the issues that executives in charge of project development are able to react to and make decisions on, affecting the future of the endeavor and all those who were engaged in it for the organization. Consequently, technical and/or technological problems at the root of the software project's problematic development history often manifest themselves in cost overruns and schedule delays when not properly addressed. When such problems become apparent, senior management often react negatively to the situation and cancel the project. This is because cost overruns and schedule delays are two of the nontechnical critical factors in software project development that nontechnical senior executives can fully understand, which causes them to cancel the project in order to safeguard organizational resources.