How to run a “Post Mortem” after a problem project

My team and I ran into a few problems a couple of weeks ago with one of our multi-timezone campaigns. Everything went great with the campaign, and as we “Deep Dive” into the metrics it turns out that on many levels we hit out goals. Big green tick. However, we did have some issues with the rollout which led to the deployment of the emails going out at times that weren’t 100% optimal. So it felt somehow initially like we’d screwed up even though that wasn’t the case.

It can be quite stressful when you’re delivering these kinds of projects, especially when you’re trying out new functionality for the first time. So we decided to run a “Post Mortem” on the rollout, which was a really useful exercise and I recommend you do this with any campaign rollout where you’ve experienced niggles. And here’s why:

Of course, helps you to learn from past actions and improve the next time you do this. Together, as a team across the wider business.

We ran a “Post Mortem” call one week after the campaign, with everyone that was involved in the project across 3 timezones. It was really productive and important we did it. I was given some simple guidance on how to do this before we met, and it was extremely valuable. I recommend you do it too whenever you’ve feel like something didn’t go so great, and here’s how.

Be swift

Once you’ve recognised there were a few events that you’d rather hadn’t occurred, suggest getting a time in the diary to meet/chat as soon as you’re all available. Within one week is preferable, and make sure all team members can come.

Assign a moderator

Assign someone to moderate and lead the session. Preferably someone who has run this kind of “Post Mortem” type evaluations before. They might put their hand up to do it, but make sure you’re all clear on who this person is going to be. This is usually the Project Manager or could be an Engineering Lead.

Have someone write up a timeline of events

In preparation for the session make sure you write up the details, start to finish, of what happened during the project. Assign someone to start it, which will be the person who was responsible for delivery, and then have any involved parties add their details too. Make sure you have this before you have your meeting and you share it with the team ahead of time. It will make sure you make most of the time you have to talk through it.

Have your session – in person or via video conference

Use your timeline and have the moderator walk everyone through it from start to finish. The idea is to pick out the points of interest, and to isolate the source of an issue or notice anything interesting in what you did or how you did something. This can also help you to pick out anything unusual in what the team, i.e. perhaps they did something they wouldn’t normally do or gives you the chance to constructively discuss other ways of doing something that could improve performance next time.

Call out Action Points

As you walk through this, the moderator should call out action points, and an assigned member of the team should note these down, preferably on the shared timeline document so it’s all in one easily referenced place. Assign a team member to each action point so you know who’s responsible for each. The call should finish with you feeling like you’ve discussed the end-to-end process and you have some simple follow ups.

Deadline for follow up

Agree to meet again in a week to follow up on the action points. Then the output of this should be a write up of what happened, what you learned and what you’ll do differently next time so it’s easy for others to see how to operate in this way.

Document your assessment

Enough said. If you have an intranet or something similar put it there, but just make sure its somewhere that can be referenced in the future for your team and others.

This is a really simple process, and a really productive one. It also helps to share knowledge amongst teams so you’re not operating in silos and new functionality tests don’t results in the same kinds of pain points in the future. It also helps build trust within delivery teams.

I wish these kinds of things were so simple in real life. Next time you have a problematic project with your team I suggest you do this – inside or outside of work.