لطفا منتظر باشید ...
Project Cancellations and Aftermath
The incidence of project failures, runaways, and abandonment will be substantially minimized if the issues discussed in the preceding section are satisfactorily handled in the course of project development. Senior management should be concerned about how project cancellation decisions are made and the repercussions they have for the organizations and their projects teams.
Project Termination Decision
The decision to cancel a software project should not be taken lightly, because it has far-reaching implications for employee morale, due to the often-bitter feelings it generates among some team members. Still, it is sound management practice not to delay the inevitable when every reasonable attempt made to rescue the project has failed. In essence, termination of the project should never be ruled out as one of the options available to executives in managing the project. Once the decision to terminate the project is made, how it is implemented becomes just as important. The cancellation decision can take place at any juncture in the project's systems life cycle based on failure to meet expected deliverables, including costs overruns and schedule delays, associated with each phase of the systems development effort.
Postmortems of the Canceled Projects
The decision to cancel a project, once made, should be communicated sensitively to the entire project team, preferably by the executive directly in charge, and reasons for the cancellation should be provided at this time. In most cases the evidence suggests that even if the team is aware of the possibility, the need to communicate the termination decision directly to the project's participants, as opposed to allowing them to hear it from the office rumor mill, will have a significant impact in reassuring the team of management's good intentions and will help minimize the extent of the blame game that sometimes follows (Ewusi-Mensah 1998; Ewusi-Mensah and Przasnyski 1995; Glass 1998).Whenever possible, the impact of the decision on individual careers should be minimized so as not to create an atmosphere where individuals would be unwilling to discuss with management what went wrong and why in the aftermath of the decision. Frequently, abandonment decisions are so badly handled by companies, culminating in the firing and/or demotion of some key technical personnel—as was the case in the Confirm and CODIS examples—that even those unscathed feel intimidated and so refrain from voicing their opinions on what went wrong and why. This is often the basis for "the code of silence" that exists in the computer industry with respect to discussing project failures (Ewusi-Mensah and Przasnyski 1995). If we are to move beyond the current state of software practice, we have to come to grips with the need to examine failures and shortcomings in order to gain insights that will significantly improve the technology, and the art and practice, of software development projects in organizations. Executives can play an important and constructive role in this learning effort.
Breaking the Code of Silence
Soon after the decision to cancel the project has been made, and even before it is communicated to the team, executives should begin the process of determining what went wrong. Someone of senior rank and of high repute in the company should be appointed to examine all aspects of the development effort with a mandate to uncover the underlying reasons for the failure. Assurances of nonrecrimination must be fully extended to all project participants. They should all be encouraged to speak with the person(s) in charge of the investigation for the sole purpose of helping the organization gain knowledge from the experience that may prove valuable in future systems development work. The intent is to help the organization recoup some of its investments in the abandoned project by learning from the experience. In this vein I suggest making the learning paradigm discussed in chapter 8 part of an organization's software development practice. This will build a knowledge base of development experiences and lessons that can provide insight into the factors that contribute to project failures in their development environment, and will provide lessons applicable to future systems development efforts. The complexity and conceptual nature of systems development projects contribute to our difficulty in understanding "all the possible states" of the system, which may in part contribute to "product flaws, cost overruns [and] schedule delays" (Brooks 1987, 11). Consequently, taking steps to identify the causes of the project failure will increase our insight into the systems development process and thus help minimize the recurrence of similar problems in the future.
