لطفا منتظر باشید ...
Learning Paradigm
It is apparent that improvements in software project development can be made if organizations show a willingness to learn from past project failures. Consequently, a study of how and why a particular project failed will, in essence, be the best safeguard against a repetition of the same or similar problems. I believe organizations, to paraphrase Petroski (1992, 523), must incorporate a treatment of software failures in their software development history for the "measure of humility" it will bring to the "innate hubris" of developers and, even more significantly, for the inherent features of the organizational software development methods and practices that they can so effectively reveal. Thus organizations should allow the problems underlying the causes of the failed project to serve as a catalyst for a deeper understanding of the entire systems development process. Learning takes place when the results of the analysis of the failure, uncovered largely through postmortems, lead to changes and modifications of organizational practices and procedures.The type of learning just referred to is similar to that described by Lehman (1989, 1980, 1062) in discussing the laws of software evolution, with specific reference to program types "P" and "E"—that is, programs that attempt to solve real-world problems and programs that "mechanize a human or societal activity," respectively. For the "Pprograms," the solution's value and validity as compared to the realworld environment or context in which the problem emanated is the main concern. Whenever differences are detected in the course of the comparison, "it causes the program, its documentation or both to be changed." Thus, "P-programs are very likely to undergo never ending change or to become steadily less and less effective and cost effective." However, for the class of "E-programs," change is intrinsic. Lehman (1980, 1063) describes the changes involved: "Once the program is completed and begins to be used, questions of correctness, and appropriateness and satisfaction arise … and inevitably lead to additional pressure for change." In other words, as organizations begin to learn more about the strengths and weaknesses of the implemented systems, change becomes a necessary consequence of that knowledge and experience, which in turn leads to better systems. The costs incurred in effecting the changes are generally accepted as essential to the organization in the long run, because the changes help to prolong the useful life of the system.Figure 8.1 presents an organizational learning-cycle paradigm appropriate to software development projects. The figure is an adaptation of the organizational learning cycle of March and Olsen (1976), applied in the context of software projects. There are essentially two parts to the paradigm. The first part deals with successfully completed and implemented software projects, and the second part deals with abandoned IS development projects. For completed and implemented projects, learning takes place in the form of maintenance and enhancements of the system (Blum 1987). In both instances, positive feedback is generated as a result of using the implemented system and learning about its deficiencies and shortcomings. Thus, through maintenance and enhancements, organizations have come to accept postmortem appraisals of even successfully implemented systems as an appropriate means of improving the performance and operation of such systems. In other words, organizations accept as normal the roles individuals and collective learning can play in "perfecting" the IS development process. Lyytinen (1987, 15) puts it succinctly when he writes: "A successful IS [or software] development process is more a matter of social learning. The information system is an incremental outgrowth of this learning, and it continues to evolve [emphasis added] over time owing to new learning." It is this type of evolutionary learning that takes place as successfully implemented systems are subjected to maintenance and enhancement changes as a consequence of users' increased learning and experience with the capabilities of the implemented system.
Figure 8.1: Learning cycle for software project
The model presented in figure 8.1 seeks to make such organizational learning standard practice for failed or abandoned software development projects through formal postmortems performed on those projects. An abandoned project is analyzed at the project-team level, using the methods and techniques discussed in earlier sections, to determine the underlying causes of the failure. The results of such an analysis should be widely communicated to all individuals associated with the project, including those who managed it. In addition, documentation of the analysis of the failure must be stored and made readily accessible to future project team members for regular consultation. The results of the postmortem should lead to the creation of guidelines calling for modifications to some organizational practices and procedures in project development in order to avoid the recurrence of the problems and/or to improve the overall performance of future project teams on subsequent projects. Such new guidelines should also be widely communicated to project team members and other individuals with responsibilities for future projects. Individual as well as organizational learning is likely to be achieved when postmortem analysis is routinely performed on each failed or abandoned software development project, and when the lessons learned are widely communicated to all concerned.However, any discontinuity in any leg of the cycle will amount to a failure on the part of the organization to undertake a postmortem appraisal of the abandoned project. It is therefore critical that each leg of the learning cycle be maintained, if the learning process is to result in the necessary changes to the way the organization or individuals approach subsequent projects and if the organization is to fully realize the benefits from the lessons of the postmortems for later projects.
