Project Post-Mortem Meetings — It's About Process Improvement, Not Dead People
Project Post-Mortem Meetings — It's About Process Improvement, Not Dead People
A Post-Mortem meeting is a review process for identifying organizational improvements on how to run projects.
Calling a meeting a Post-Mortem is a little morbid. The idea behind it is to circle back to a completed project and take stock of what worked, and what didn't.
It's a mechanism for learning from experience. One mechanism for learning from experience is the COE, where you review an operational event (“Error”) and take action. A Post-Mortem on the other hand is an evaluation of a project. Rather than being focused on a negative event, a Post-Mortem is focused on the process.
Feedback is a strong mechanism for an individual to improve. Post-Mortems are the analogous mechanism for groups of individuals. Consistently doing a Post-Mortem meeting, and then executing on the actions and changes, will create a continual improvement process for an entire organization.
This meeting should be called within a week or two of project completion. Once you move too far away from your launch activity, everyone's minds will have moved on. You want to have all the information fresh in everyone's heads. Having the meeting in that brief period between launch and the kicking off of the next big thing is the perfect moment to take a breath.
Why have a Post-Mortem?
People often misinterpret the causes of failure. Consider the following situation.
Engineer: "We were unable to launch on time because the design was late. The designers need to be done on time."
If you stopped the discussion here, you might assume that the designers need to get their act together.
Designer: "We had the first version of the design ready, but the product management team kept requesting changes. We could never get agreed upon designs."
Ok, we've just flipped our assumptions. Now it seems that the product team couldn't make up their mind.
Product: "Remember, we had contracted with the user research group. But we did it so late that they gave us the results halfway through the project. Still, the results told us that we were building the completely wrong thing. We had to change the product and design or we'd have failed.
Now we have a more complex and interesting answer. Real life is often more complex than it first appears. If we had gone with the simple answer, the engineering team would continue assuming that the designers were the cause of their issues. The design team would assume the product managers couldn't make up their mind.
Instead, we have a compelling and complex cause of the delay. Someone will now need to take responsibility for getting user research done further in advance of the project.
This is why we do a Post-Mortem. We look under the surface. We pull together disparate sources of data to tell a story. We build collective organizational knowledge, and then disperse organizational learning. Everyone learns something, opens their mind to the complexities of project management, and we execute the next project that much better.
How do you prepare?
Someone will drive the Post-Mortem process. This is a coordination position, which requires someone to be open-minded, and respect the opinions of all the stakeholders on the project.
You could perform a bare minimum version of a Post-Mortem by getting everyone into the room for a brainstorming session. This won't be very effective. There are three major things missing from an impromptu meeting.