Project Postmortem

"Those that do not know history are doomed to repeat it."

It is important for each team member to take stock at the end of a project and review your project's history analyzing its positive and negative aspects. Typically such reviews are called post-project reviews or "postmortems". The goal of a postmortem is to draw meaningful conclusions to help you learn from your past successes and failures. Despite its grim-sounding name, a postmortem can be an extremely productive method of improving your development practices. This document should not attempt to assign blame for failure. In most cases, the team as a whole should accept responsibility.

Once your project has been turned in and you have had a few hours to relax and reflect, you are to individually analyze your experience. You may meet as a team to refresh your collective memory about project's timeline and how specific key decisions were made, but the analysis itself should be written individually and submitted electronically.

Specifications

Your analysis should be divided into three distinct parts: a technical evaluation of the project's code and design; an evaluation of the progress and decisions made by your team; and an attempt to grade your team's overall effort. Your analysis should be an honest, thoughtful reflection that aims to identify specific actions that either helped or hurt later in the process. Additionally, it can be used to demonstrate your knowledge of design concepts that may not be easily represented in other project documentation.

At least the following sections must be included in your analysis. Questions are provided to get you started thinking about what to consider within each section; you may, of course, include anything else you feel is relevant. In other words, do not be limited by these questions, but include them at least.

Technical Review

This first part should focus solely of the code and design of the project, analyzing both its strengths and weaknesses.

Time Review

Reflect on how you spent your time while working on this project. Start with the estimated time spent on project and project start and finish dates. Include how many hours on average you worked each day of the project and what you spent your time doing (i.e., coding new features, refactoring, testing, reading, designing, debugging, documenting, and meeting with team members).

Planning

Reflect on how your team planned this project. Start with your initial plan for the project.

• Did it hold up over the course of the project?
• Was each person in the team effectively used?
• What does the difference in planned versus actual time tell you about how to estimate and partition your time in the future?

Status

Analyze the design and coding details of your project. Look over the entire project and assess the following:

• Do you feel the code accurately reflects the design?
• How did the design change as it was realized in code?
• Are there any parts of the design you do not understand? especially like? dislike?
• Are there any parts of the code you do not understand? especially like? dislike?
• Are there any parts of the design that did not work when you tried to code them? or worked out better?

Conclusions

What conclusions can you draw from analyzing your code? List both successes and shortcomings in your design.

• What defect types occurred most frequently? were most time-consuming to find? to fix?
• What can you do to reduce the occurrence of those defects in your future projects?
• Which parts of the code required the most rework? of the design?

Future work

No project is ever completely finished. Document at least three parts of your project that still need fixing, that you wish you could understand better, or could be extended or made more flexible.

• If you could work on one part right now to improve your grade, what would it be?

Team Review

This second part should focus on how the team worked together to work on the project, looking at it from the roles each person assumed in the team and how they contributed to the overall effort, not their personalities.

Description

Begin with a brief overview of your team (including outside people with whom you collaborated), detailing what roles each person played, how each role was selected, and for what packages of code each was responsible.

Planning

Document your initial thoughts about the team, including the initial meeting and plans to keep communication flowing with the team.

• How often did you plan to meet?
• How did you plan to communicate within the team?
• How did you plan to manage the project individually, i.e., package, develop, and post the code?
• How did you plan to manage the project as a whole, i.e., integrate, update, test, and avoiding deadlocking?

Status

Analyze how effectively your team worked together to complete the project.

• Describe any early warning signs of problems that occurred later in the project?
• How could you have reacted to these signs?
• How can you be sure to notice these early warning signs next time?

Conclusions

What conclusions can you draw from analyzing your team's planning and communication? List both successes and shortcomings in your team.

• Were the right people assigned to all project roles?
• Did you overestimate or underestimate the size of this project? By how much?
• Did you overestimate or underestimate the time required for this project? By how much?
• What does the difference between planned vs. actual time tell you about the method you used to estimate time from size?

Future work

It would be a great waste of time to create a beautiful project postmortem, archive it, and forget about it. You should develop an action plan that can be applied to your next project. Review your project history, reflect on the lessons you have learned, and specify new guidelines you personally plan to follow in the future.

• What conclusions can you draw from your project history that will help you improve in the future?
• What should you start doing, keep doing, or stop doing?
• Review your previous personal goals, did you meet them when working on this project?

Grading

Finally, based on your answers to the questions above, or the effort needed to discover the answers, grade your team's project (not necessarily their effort). This is primarily intended to see if our assessment meets your expectations, not to influence your grade. Please note that it is rare that everyone in the course gets an A+ on every project, so you should justify the grade you have assigned.