Abandoned software projects are failed projects because organizations do not routinely invest substantial organizational resources in a project unless certain criteria are met. First, an organization has to have identified a need for the system within the framework of its operational and strategic goals; second, it has to have determined that it has the requisite capabilities to get the system developed and implemented. Under such a scenario, when the organization decides to cancel the project later in the software development process, it can reasonably be surmised that the project was a failure because the organization did not achieve its original objectives with respect to the project. An enumeration of the factors that may contribute to the decision to cancel a project, the intensity of each factor, and the extent of their contributions to the cancellation decision is the focus of this book. The extent to which the factors are or may be repeated in other projects in different organizational settings or environments is equally significant in helping to shed light on the totality of the circumstances at the heart of abandoned projects.In its description of software failures, the Standish Group (1995) differentiates what it considers "challenged" software projects from "impaired" ones. The "impaired" software project is eventually "canceled at some point during the development life cycle" (emphasis added). The "challenged" project is not canceled; rather, it may eventually be completed, albeit over budget, over schedule, and possibly with limited functionality. Thus the distinction between the two types of software projects has to do with whether a project is canceled or not. There are, in fact, many similarities between software failures in general and abandoned software projects. The abandoned software project may be a consequence of a perceived failure of the project prior to its full implementation. Thus in anticipation of that fact, the stakeholder group—that is, senior executives with the responsibility for safeguarding organizational resources, sometimes in consultation with the other stakeholder groups—decides to "pull the plug" on the project. In this sense, we can characterize software project abandonment as an endemic part of the much broader organizational problem of software failures described above (Ewusi-Mensah and Przasnyski 1991).Boehm (2000), however, challenges the Chaos report's (Standish Group, 1995) conclusions by arguing that some project terminations are justified and, in fact, even necessary to safeguard organizational resources. He arrives at this conclusion on the basis of personal experience, knowledge, and "review of about 20 term papers per year on failed industry projects," among other sources of information. He lists the sources of project termination in the Chaos report and provides explanations as to why termination was desirable in each case. His basic concern is that project termination should not be used as a scapegoat to damage the careers of project managers who might in the future be more likely, as a result, to continue with projects whose strategic and competitive value to a company may have diminished as a result of changes in the project's original assumptions. Consequently, Boehm argues that not all project terminations should be equated with project failures, especially in rapidly changing technological, organizational, and market environments. Project terminations of 31 percent, in his view, should not be considered too high in dynamic development environments, as opposed to stable environments.While I share Boehm's basic concerns, I feel that project terminations of 31 percent are, in fact, indicative of fundamental problems that require thorough investigation. It is not satisfactory to suggest that such high termination rates are the risk-acceptance rate for undertaking software development projects, even in a rapidly changing development environment. I believe that proper understanding of the multiplicity of cofactors at work in software development projects, as well as knowledge of the risk-acceptance rate of particular organizations, will give software developers, project managers, and their senior management and end users a deeper appreciation of the uncertainties of software development and provide for better decision making in project selection and management.Subsequent chapters shed light on this looming problem of abandoned software projects in organizations. In particular, they discuss the variety of factors contributing to decisions to abandon software projects and show how abandonment decisions are made in practice. What characteristics do abandoned software projects have in common? What benefits, if any, do organizations derive from past decisions to abandon projects? And finally, what guidelines and lessons can be offered to management to aid in software project selection and project management to minimize the frequency of abandonment decisions in organizations?
لطفا منتظر باشید ...
