Historically, technical and technological progress has been made by examining failures in various endeavors in addition to extrapolating from successful precedents. However, progress in software development practice will not come about merely by inferences from an extrapolation of successful precedents. Attempts to improve the practice and methods of software development will only come about by concerted, collective, and open attempts to closely analyze the conditions and circumstances surrounding major failures in software development projects. Postabandonment review is a process of uncovering what happened in a software project failure as well as why and how it happened. Through this deliberate fact-finding process the major events and issues that contributed to the failure may be uncovered and conclusions may be extracted from which all can learn. For example, one of the purposes of design reviews and requirements reviews in software development is to ensure that proper and adequate communication has been achieved, that there is the requisite appreciation of the user requirements, and that a full understanding of the design concepts is derived from the functional specifications before development is continued. Having the users and other stakeholders participate in such reviews is of the utmost importance in ensuring that communication and understanding are achieved among all the stakeholder groups. These are considered good practices in successful software development.The objective of a postabandonment review is to make the study of software development failures part of the education and learning experience of software practitioners. Software project failures can serve as catalysts to cause organizations to examine the processes, practices, and methods used in the projects. In this way, they can uncover the underlying problems associated with any of the major events or issues, learn from them, and ultimately avoid their recurrence in future projects. Failure to undertake such an analysis of why and how projects fail is to lay the foundation for possible repetition of the factors that contributed to the failure in the first instance.Sometimes management and other stakeholders involved in the failed projects view postmortem analysis as a political process that they would rather not see undertaken in their organizations. This attitude is unfortunate, because it is important for an organization to understand what went wrong in turning a conceptual model of information requirements into a complex systems artifact. With the increasing levels of complexity associated with software projects being tackled in organizations, any failure to learn from the successes and problems associated with project development efforts will most likely pave the way for a repetition of the failures of the last project. Besides, progress in the practice of software development will only come about as organizations take the bold, and perhaps at times unpleasant, steps of carefully examining their project failures and making needed organizational changes. Organizations that fail to adopt the approach recommended by critics are not only failing to heed the lessons of history but are invariably shortsighted with respect to their management responsibilities and leadership.What may be political in the process of postmortem analysis is the attitude brought to the exercise by project leadership and especially management. If the exercise is conducted in an open, nonthreatening, fact-finding environment by competent analysts without any other motives than to help the organization understand how to improve its software development practices, it will most likely be well received by a majority of stakeholders involved in the failed project. However, if the process loses objectivity and becomes a veiled attempt to find scapegoats or a witch hunt to assign blame to various individuals, most stakeholders involved in the process will be justified in viewing it as political and may try to sabotage it. Thus it is the negative or biased attitude toward project postmortem analysis that may be political and that therefore must be strenuously avoided by any organization intent on gaining new knowledge and insights into its software development practices.The project environment is never static; it changes continually over time as new team members are added, sometimes to replace departing ones and at other times as additional expertise is needed. In addition, the technology of the software industry changes rapidly as new tools and techniques are constantly introduced into the marketplace with the potential to influence ongoing projects. The dynamics of such an environment add another layer of complexity, risk, and uncertainty to an already-difficult creative undertaking. Project development under such circumstances is undoubtedly fraught with the potential for failure, especially if the project is highly innovative and the organization has no prior experience with a project of its kind. For these reasons, it seems prudent for organizations to make project postmortems an essential part of their software development practices.What makes software development qualitatively different from other types of engineering work is that the whole process, from requirements definition and design to implementation, is conceptual. Errors will always be part of the process because of the human element involved in the various stages of the development. The overarching objective of any organization, therefore, must be to identify and learn from the development failures resulting from these errors. However, organizational learning in software development will only come about when organizations are able to fully analyze and understand the problems associated with development failures. The learning that results from this process of organizational retrospection is intended to improve the performance of the organization in future projects and, in some sense, to change the environment in which the project development occurs so that there will not be a recurrence of the same or similar conditions. Because the project development environment is continually changing, this type of learning must be iterative to be of lasting value to the organization. The organization must continuously apply what it learns in the project development failures to improve its performance and practices in future projects. Organizational learning is emphasized because there is more at stake for the organization in determining the causal factors linked to the failed project than there is for the individuals involved.The roles of the individual project team members are important in helping the organization achieve its desired objective—that is, the recovery of some of its investment in the project—by aiding in the search for answers to the questions of what happened and why and how it happened. However, because they have freedom of movement, individual team members may not have as much at stake in the failed project as the organization does. Even those whose careers may be intimately tied to the project can, if they choose, distance themselves from the failure by resigning. Only the organization is left with the task of picking up the pieces after the project's demise. Hence the compelling need for senior management to assume organizationwide responsibility for undertaking such postmortems as soon as the decision to abandon a project is made. To the extent that software failures serve as catalysts to organizational learning about methods and practices employed in software development, organizations should welcome the benefits they bring and not shy away from or be embarrassed by them. The benefits will come when the lessons learned from the failures are incorporated into the organization's revised software development practices. The reasons given for avoiding postmortems include an unwillingness to spend the extra money or time, the organizational embarrassment involved in the failure, a reluctance to open the organization up to potential lawsuits in contractual projects, and a general lack of appreciation of the benefits to be derived from the exercise as an investment in professional development for the organization and the individual project team members. However, the benefits in the long run seem to far outweigh the disadvantages sometimes cited for not going forward with project postmortems.
لطفا منتظر باشید ...
