Chapter 3: Factors Critical to Abandoned Software Projects - Software Development Failures [Electronic resources] : Anatomy of Abandoned Projects نسخه متنی

Chapter 3: Factors Critical to Abandoned Software Projects

The failure of software development projects defies straightforward explanation. These projects fail due to a combination of interacting factors. The failure may result in less functionality for some completed projects; it may result in cost overruns; it may also result in schedule delays; and in some instances, it may result in the cancellation of the projects. Consequently, like the failure of software projects in general, the abandonment of software projects may be the result of a "multiplicity of cofactors"—that is, technical, organizational, political, managerial, sociological, and economic factors, among others. The abandonment of software projects can occur at any stage of the software development process. In this chapter, we briefly discuss the various stages of the systems development process and examine the factors identified by researchers as contributing to the abandonment of software projects. We subsequently build on these analyses of the software development process and of the factors contributing to abandoned software projects by constructing a framework to help us understand the critical impact these factors have on abandonment decisions at different stages of the process. In subsequent chapters we discuss in detail the various groupings or classifications of the factors that are particularly crucial in a project's cancellation.

Software Development Models

Chapter 1 offered a theoretically based explanation for the persistence of the problem of software development failure based on a view of software development grounded in the modern scientific method of rationality. As Robinson et al. (1998), Brooks (1987), Parnas (1985), and others have argued, the modernist approach seems to break down because software projects are not completely amenable to the modern scientific method. As a result, in spite of the enormous progress made in software engineering methods and procedures, the practice of software development will continue to be plagued by socioorganizational problems—from problem formulation in ascertaining the requirements for the software to the full implementation of the completed software artifact in the organization. The scientific or modernist approach thus far has not succeeded in providing a reliable, valid, and verifiable way to develop software that gets at the core of the problem of software project failures.

In a review of software technology, Glass (1999) examines the productivity- and quality-improvement claims that heralded the introduction of six development technologies, ranging from structured techniques to process models and object orientation. He concludes that the claims are not substantiated by the empirical data—at least in the cases where data are available. Software project failures are still a recurring problem for projects of all sizes and levels of complexity, including both structured and unstructured application problems. Several process models for developing software are in use, perhaps the most widely known being the iterative version of the conventional life-cycle or waterfall model. The term software process model describes the sequence of activities that the developers need to undertake to produce a software product. In addition to the conventional life-cycle model and its various derivatives, there are the prototyping model, the clean-room model, the capability-maturity model, and the evolutionary model, among others. Software development in an organization will typically proceed with a variant of the process model it deems appropriate to the project based on the organization's own knowledge, past experience, and expertise regarding the use of the model in question. As Sommerville (1997, 2260) suggests, "There are currently no accepted standards for describing process models. The vast majority of models are expressed informally, using diagrams and descriptive texts." In addition, the work of the development team will be shaped by the existing organizational culture—that is, the "beliefs, commitments, styles and power relations" of the project team, as Tellioglu and Wagner (1999, 76) have found in their analysis of five software development projects.

The focus of the discussion here will be on the problems encountered in software development—regardless of the process or method used— that may be at the root of software failures, of runaways, and in extreme cases of complete abandonment. I do not intend to discuss the strengths or weaknesses of the various software process models used in software development. Interested readers may wish to review the analysis by others, such as Sommerville (1997) and Ramamoorthy et al. (1984). To the extent that software failures are not tied to any process model, my failure to discuss the software problems as they relate to the software process models does not diminish or detract from the validity of the analysis. I know of no empirical studies showing a correlation between software project and the development process model used. Perhaps future studies may be able to demonstrate a link or correlation between software failures and the type of process models used in the development. I agree with Sommerville (1997) that software systems failures are the result primarily of human errors in design, and are not a consequence of, for example, material failure.

The Life-Cycle Model

The widespread use of the conventional life-cycle model in organizations, which have adapted the model to fit their technology environment, is a testament to its enduring value. It will therefore be helpful to draw on the elements of this model as a basis for our discussion. When used in the various process models, none of the productivity- and quality-improvement techniques reviewed by Glass (1999) seems to have had any noticeable impact on the problem of software project failures and runaways. However, regardless of the particular process model an organization may use, four basic elements are common to the project development process. Every software project will feature: (1) the requirements-definition and functional-specification phase; (2) the design phase, during which the functional specifications are fashioned into various systems design "solution" alternatives conceptualizing how the requirements will be achieved; (3) the implementation or the coding and testing phase, in which the selected design "solution" is developed into source code, tested, and integrated to determine if the original requirements for the system are satisfied; and (4) the installation, operation, and maintenance phase, during which the completed system is put into operation for use by the organization.

Over the years, several critiques of the conventional life-cycle sequential approach to software development have been offered. The most compelling focuses on the delay between the specification of the functional requirements and the coding, testing, systems integration, and final installation of the working system. This delay, it is argued, hides from early discovery some potential problems that may only be uncovered after much time and effort have already been expended on the development. The second major criticism is concerned with the changes brought about by the critical learning that takes place as the development proceeds from one phase to the next. This need for iteration and recursion induced by the organizational learning and validation of the previous phase also introduces additional costs and delays in an already-stretched system for software development. (See, for example, Sommerville 1997; DeGrace and Stahl 1990; Lyytinen 1987; Ramamoorthy et al. 1984; Gladden 1982.) The above criticism of the conventional life-cycle model notwithstanding, I believe the problem of software failures and runaways leading to abandonment is not limited to what methodology or technique was used to tackle the development effort. Software failures, including abandonment, have a complex parentage, and for each case of an abandoned or failed project, one can find several candidate factors to blame for the fiasco.

Software project failures, runaways, or abandonment can occur at any one of the four life-cycle stages when the expectations of any of the stakeholder groups are unrealized, creating a situation that, in some instances, compels management to terminate the project prior to its installation and operation. The failed expectations of the stakeholder group leading to project abandonment may be traced to any combination of factors. The requirements specifications spell out the expectations for the software project development to the management of the project or the stakeholder group responsible for the project's budget, and the expectation-failure concept described here refers to the failure of the software developers to satisfy the terms of the project contract they proposed based on the requirements specifications. This view of expectation failure is different from what Sauer (1993) finds objectionable in his critique of Lyytinen and Hirschheim's (1987) definition, because it is based on the expectations for the development and completion of the project reflected in the contractual terms agreed on in initiating the project. It encompasses completion failure as well as failure to meet budgetary and scheduling estimates. We will examine these abandonment factors and group them into broad categories for further analysis. This further classification will point out the common characteristics of the various factors and help to focus attention on specific problems in the development process that may be harmful to the project's outcome if left uncorrected. Furthermore, we will show the relevance of each factor to each of the three stages of project development prior to the final installation and operation of the system. However, our analysis of the factors contributing to failure will not extend to including operational failure. Interested readers, however, can consult Lucas 1975, Kumar 1990, Markus 1983, and other sources in the information systems failure literature.