Post Mortem Basics

What is it?

To make long story short post mortem is a little discussion after a project or important part of project. The team discusses what was done well and what was screwed. Before discussion one person gets feedback from all team members to bring a food for thought. Outcomes are used in future projects.

What’s in it for me?

Why to do post mortems? You usually feel what went wrong and what went well. But do all team members feel the same? Does a developer care if communication with a client went perfectly? Does a project manager understand all architecture flaws developers had to face? Does quality assurance team was aware about complex hardware installation part?

Post mortems bring two main outcomes.

1. Knowledge sharing. Everyone adds their two cents. All perspectives are included. Even the least important team member can bring a refreshing insight about project.

2. Written summary. The process of preparing post mortems forces a person to prepare a piece of document before discussion. You just raise your chances to have a written summary after all which won’t fade in a week.

How to do it?

The scenario is simple:

1. A person who knows a project well, ask all team members to answer three questions:
• What went well and should be repeated in future projects?
• What was on a good path and should be improved in future projects?
• What went wrong and should be avoided in future projects?

2. Then the person needs a lot of squeezing to get answers from most people from a project team, as many people won’t just answer a polite request.

3. All answers are assembled into one summary. That’s part can be tricky as it sometimes happen the same thing will be put in different categories by different people.

4. The whole thing is discussed and adjusted during team meeting, when everyone can add anything what comes to her mind.

5. Post mortem can be, and should be, used to improve future projects.

The questions can be adjusted if you feel like it, although I find the more general they are the more interesting things people will bring in answers. You don’t force people to change their perspectives, you just let them exploit their area of competence.

When to do it?

Definitely when a project is finished. But when you run a project which lasts three quarters you won’t remember all the issues you had to resolve during first phases after all. Then it’s quite a good idea to run post mortems after each important milestone.

When you shouldn’t bother?

If you don’t plan to use post mortem outcomes to improve future projects, don’t waste your time. Looking back is worthwhile only when it is a tool to improve future.