Numerous software engineering authors and researchers write in support of what is termed in the industry as postmortems. Unfortunately much of the software industry does not heed the adage "Those that do not know history are doomed to repeat it." It is suggested that progress is not so much an issue of steady successes, rather it is a reaction to past failures. Some authors claim of this lack of success in project after project is predictable, because we repeat the same behaviors each time. These critics go as far as to suggest that a thorough review of the problems encountered during a project is the first step in overcoming poor performance.
Educational practice also fails in this regard. We do not encourage students to review projects. We do not ask students to critically review the events, actions, and problems occurring during the project. We have opted, with student support I might add, for the easy way out - "Grade it, and forget it!" We have ample evidence from the literature in support of the positive influence critical reviews can have. It may seem difficult or fruitless, yet there is solid foundations for the activity. Our focus should be on the problems encountered during project development -- What went wrong and what went right with an effort toward an explanation of how our actions relate to those successes and failures.
This is the case for including a postmortem analysis for each project this semester. First, postmortem analysis has been identified as an industrial best practice. Identifying it as a best practice indicates that investing time and/or money in a postmortem process has an enormous return on investment. Second, since this is a learning activity, the gains from the educational perspective are potentially as large as those from the industrial perspective.
From the introduction on this page I hope you can see the purpose in postmortems is to help the developer, in this case you and me, understand the development process and the various intricacies involved in product development. We do this by focusing on what happened during product development. In particular, at the end of each project we want to ask ourselves some questions regarding the events that occurred during the project. The purpose of the survey is to focus the developer on certain issues. The idea is not to assign blame and fault, rather it is to help you identify situations that occur and hopefully help you develop strategies to cope with those situations. The survey is intended to collect information on the process you went through for a particular project. There are two primary responsibilities: first, my responsibility is to help you make your development process visible and therefore accessible; and, second, your responsibility is help yourself by providing valid and thoughtful responses to the questions. It serves no purpose to avoid the truth!
Opinions, intuitions, and judgments are not sufficient for the job we have accepted. What is needed is a firm foundation from which to understand and reason about the project. To move toward this foundation, you must begin to collect objective information regarding the project's process and product. The survey completed in step one lets you focus your perspective, now the data you collect and describe in this step lets you begin to focus your reasoning. Hard data helps identify problem areas. It is the problem areas that offer the greatest prospect for improvement. Furthermore, collecting data over multiple projects allows you to initiate activities in terms of comparing different projects. Finally, the use of hard data diminishes the use of intuition and conjecture. Now the issues are framed with numerical values that must be understood with respect to the process and product they describe.
There are several approaches to communicating the results. Before those are discussed however let's justify the practice. There should be an attempt to describe what has been identified and learned through the first two activities. The act of organizing what you have learned and communicating it to someone, the infamous player to be named later, is crucial to the activity. The remarks made in this activity should be coherent and thoughtful. There is no space for sloppy thinking, or the misuse of data. Your initial attempts at communicating the results is to state the problems you have identified with any supporting evidence you have collected. Try to be specific. Remember you are working toward developing strategies to work better and smarter, so deceiving yourself now is not a good idea. As you develop this statement put yourself in the position of a nonbiased observer. You are viewing the evidence for the first time, what statements can and should be made? Are the statements supported by data that was collected in a reasonable fashion?
From the issues and problems you have identified choose one activity or task that will become your focus of improvement for the next project. I recommend choosing a single item in the beginning since it facilitates focusing on that one issue. You job here it to identify the task that has a large impact on your development activities. For instance, you may have identified through the first three steps that you postpone beginning the project until it is almost impossible to complete the project in reasonable fashion. You may have identified the reason for such an action is you misunderstood the project requirements or expectations. Your goal may then be to work hard at understanding the problem and elaborating the requirements early in project rather than later. With that goal in mind you should detail what actions you can take to achieve the goal.