Software Development Failures [Electronic resources] : Anatomy of Abandoned Projects نسخه متنی

The Postabandonment Review Process

The project postmortem is an attempt to institute a process of inquiry, knowledge dissemination, and communication among all the major participants in the project based on their retrospective observations and analysis of the problems surrounding the development. The process must not be used to apportion blame to the various stakeholder groups and the individual members involved in the development process. Rather it must always remain an honest attempt to uncover the problems associated with the project. Thus how the postmortem is undertaken will have obvious consequences for the reliability and accuracy of the diagnoses of what ailed the project, why the symptoms and ailments were not corrected or could not have been corrected, and why those ailments ultimately destroyed the project. The sensitivity and openness that the project investigators bring to the process will unquestionably influence the validity of their findings and, most important, whether these findings will be acceptable to the project participants.

Eliot Chikofsky (1990) and Bonnie Collier, Tom DeMarco, and Peter Fearey (1996) have advocated that the postdevelopment review process be made part of all software development projects—both the successes and the failures. Chikofsky, for example, believes this kind of "endgame strategy" will impart to each project team member at the end of the project not only "their own individual opinions and conjectures about workable or unworkable approaches," but even more significant, "knowledgeable experience that comes from thoughtful analysis, group input, and discussion" (p. 112). To achieve this goal he offers a sample of postmortem questions that can be used as a basis for analysis and discussion. I have grouped Chikofsky's sample questions into three broad classes:

Project planning and initiation

What was the plan at the start of the project?

How did the plan change?

What do you know now at the end of the project that you wish you had known earlier?

How would this have changed the project?

Project management and control

What most noticeably went right on the project and why?

What most noticeably went wrong on the project and why?

What sorts of information came in too late, and what could have been done to get the information in on time?

In what ways did the project backtrack or rework ground already covered, and how could the rework been avoided?

What are the most important things you would point out to your manager or your staff if you joined a similar project in the future?

Technical know-how and technology base

Did the project team have enough expertise or training at the start of the project? By the end of the project?

What skills or knowledge turned out to be most important?

How effective was the development method or approach used in the project? In what ways did it succeed or fail? Would you choose to follow that approach again?

What tools were used on the project? For what were they most or least effective? How would you change the use of these tools to make them more effective? (Adapted from Chikofsky, 1990, 87)

The goal of the structured process illustrated by the above questions is to help the organization "to determine what went right, what went wrong, what worked, what didn't, and how it could be made better the next time" (p. 112). This will constitute the organizational learning that will in the long run prove beneficial to the software development practices of the reflective organization.

Collier, DeMarco, and Fearey (1996) also offer a five-step process for carrying out the postmortem review. The intention is to provide the organization with new insights with respect to the project in question and, most significantly, to find out which "behaviors need changing" in order to improve the methods and practices of the organization in future software development projects. The steps are summarized as follows:

Design and conduct a survey to collect relevant project information from all project participants.

Collect quantitative data on the overall project development process. For example, data such as the project cost at various stages, the schedule, and defect or error counts are considered to be valuable objective data to capture.

Conduct structured interviews or debriefings of the team members to expand on the survey data and to cover areas otherwise missing from the survey questionnaire.

Conduct a review of major events and issues (i.e., "Project History Day") in connection with the project with a select subset of project participants, presumably members in major leadership positions who will then be better informed on the events and decisions made on the project.

Document the findings in a report that will outline the lessons learned in the review and that can be beneficially used by the organization in new projects.

Finally, Collier, DeMarco, and Fearey strongly advocate that senior management create an open, sincere environment where such an exercise could be conducted in order to foster the kind of organizational learning that must take place and that must be disseminated throughout all levels of the organization.