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

Types of Abandonment

What, in essence, constitutes software project abandonment? Software project abandonment occurs whenever senior management decides, for whatever reason, to discontinue temporarily or retire permanently a software project under development. Three types of software project abandonment are identified by Ewusi-Mensah and Przasnyski (1991) and will form the basis of the classification in this discussion.

Total Abandonment

The first and most frequent case of software project abandonment is total abandonment. Total abandonment describes the instances where there is complete termination of all activity on the software project prior to full implementation. This classification is analogous to the "impaired" project category of the Standish Group's three-resolution categorization, consisting of completed, challenged, and impaired projects. The incidence of this type of abandonment reported in published studies ranges from a low of 10 percent (Cole 1995) to a median of 31 percent (Standish Group, 1995) to a high of 40 to 44 percent (OASIG, 1996; Ewusi-Mensah and Przasnyski 1994). It is also one of the most costly expenditures organizations incur in their software project portfolio, with estimates ranging in the area of several billion dollars for both public-and private-sector organizations (Standish Group, 1995; Wysocki 1998; Heinrich 1998).

Substantial Abandonment

The second category of abandoned software projects is described by Ewusi-Mensah and Przasnyski (1991) as substantial abandonment. Substantial abandonment refers to instances in the software development process where a major truncation or simplification of the project occurs prior to full implementation to make it radically different from the original specifications. This category is approximately analogous to the Part 2 [i.e., of his book] resulted in some form of project cancellation." Thus, by Glass's own description of what constitutes a "software runaway," the abandoned project can belong to either of the above categories—that is, total or substantial abandonment.

In substantial abandonment, projects may still be continued or carried to completion even if cost overruns and schedule delays occur, so long as the reduction in systems functionality will enable the organization to salvage some of its investment in the project. This is perhaps the most significant distinction that can be made between substantial and total abandonment. However, in the case of total abandonment, reduction in systems functionality may not achieve the desired goals even if management allows for the cost and schedule overruns, thus making complete termination of the project the only viable option.

Partial Abandonment

The third category of abandonment is identified by Ewusi-Mensah and Przasnyski (1991) as partial abandonment. Partial abandonment describes the case in which a reduction of the original scope of the project is made without entailing major changes to the project's original specifications prior to its full implementation. This classification provides a limited, indeed a restrictive view of abandonment to reflect in essence some reduction in systems functionality but nothing so significant as to drastically affect the original project specifications. Such cases seem to occur frequently in practice, albeit with some cost overruns and schedule delays. In fact, the KPMG study (Cole 1995, 4) provides data to indicate that about 30 percent of "software runaways" can be attributed to "reduction in scope of [the] project." In addition, this class of abandoned projects is probably in general to be expected, because organizations would rather make changes to the scope of their projects than risk total abandonment or even substantial abandonment if they believe such changes would enable them to achieve their original project's specifications. This would be a more rational use of organizational resources in the development of software projects than the other two alternatives would be.

All three types of abandonment occur in organizations in both the public and private sectors. However, of the three types of abandonment, the most costly and at times the most disastrous is the total-abandonment category, as many reports bear out (see, for example, Cole 1995; Capers Jones 1995; Glass 1998; Standish Group, 1995; Wysocki 1998; Gibbs 1994; OASIG, 1996; Heinrich 1998; "PG&E Dumps CIS Project," 1997; Ewusi-Mensah and Przasnyski 1991, 1994).

Table 1.1 provides a summary of the data on abandoned software projects from four published studies, and figure 1.1 summarizes the same data in graphic form. The totals do not add up to 100 percent because the incidence of abandonment reflects different projects in different organizations.

Figure 1.1: Summary data: Abandoned software project studies

The data deal only with abandoned or "runaway" projects; successfully completed projects are not included in the data analysis reported. The total-abandonment figure from the Standish Group, with a total sample size of 365 respondents in the United States, breaks down as follows according to the size of the organization: 37.1 percent of most projects in medium-sized companies (i.e., companies with annual revenues of between $200 and $500 million); 29.5 percent in large companies (i.e., companies with annual revenues of more than $500 million); and 21.6 percent of projects in small companies (i.e., companies with less than $200 million in annual revenues) (Standish Group, 1995). No comparable figures are provided for the substantial-abandonment projects.

chapters 4 through 6.

The data from the above studies confirm that abandonment is not confined to any particular market segment or type of organization, nor is it "associated with any particular business sector or size of organization," as the KPMG study (Cole 1995, 3) concludes. In general, software abandonment occurs "when problems arise in perceiving, analyzing, designing, or configuring the system objectives; when the technological basis for the system and its behavioral, political or organizational (including economic) issues directly or indirectly affect ways that could bring the project to a successful completion, within the estimated budget and/or schedule constraints; and/or when the organizational environment factors combine to reduce the project's expected benefits or increase its expected costs" (Ewusi-Mensah and Przasnyski 1991, 68).