Part of every major project, both in my classes, and in better run software development organizations is a post mortem report.

In good software organizations, the post mortem report is read by a neutral third party and the source of the information is kept confidential. The information itself is usually digested, stripped of personal identification and passed on to management in the organization. It should never be given directly to managers as fuel for promotions, demotions, punishments and rewards. In this way, the people on a project get a chance to review the project and (one hopes) learn from its errors and successes.

I ask students in my courses to do a post mortem for the same reasons. It is a chance for you to learn from your errors and from your successes. It is also a chance to survey the project and assess what you might have learned from it.

It also serves as an opportunity for you to consider your team members if you were in a team (teaching/teamwork.html) project. Feel free to express your opinions of the other team members. I will not reveal the source of any information you pass on in this way and for the most part this information will remain confidential with me. Thus, this can serve as a way for you to burn off some of your frustrations with a problem team member.

I may use this information in a couple of ways. First, I may use this in grading team members - I will not take points off from someone who has been described poorly in a post mortem, but I may give a bit of credit to someone who has been described well. Second - if I have repeated reports from team members that a specific individual has not done their fair share, I may take this into consideration when I grade the submissions from a team. Thus, if a team has a member who has sone nothing for the team, and the team assessments agree on that point, I may grade the project as though it were done by a team without that individual. Finally, repeated poor reports about a student may leave me reluctant to recommend that student for awards, to write recommendations and so on. (It probably won't surprise you to hear that repeated good reports will probably have just the opposite effect.)