A Postmortem Story

First of all, I will quickly introduce what a Postmortem is. Then, I will share with you some tips to write one of them by yourself. And finally, I will explain why I had to do one, how I did it, and what I got out of it.

I had to conduct a Postmortem as part of my internship, so I’m not an expert on this topic. Let me share with you what I could learned.

I. Definition

A Postmortem is a simple process, very common in the world of project management. It consists in retracing all the steps, encountered challenges, and implemented solutions from the beginning of a project to its completion.

Writing it allows you and your team to learn lessons, to identify where and why there may be failures, and avoid repeating mistakes. In a few words: you gain in productivity, acquire skills, and save time!

II. Some advice

When writing a Postmortem it is important to communicate: with your team, the people with whom you have collaborated on the project, the users potentially concerned, etc.

It is also very important to focus on the right things, not to overdo and keep it as clear as possible. You can follow a template to guide you during its writing.

Another critical point is, to tell the truth, not to look for blame, and above all: To find solutions and learn from this experience!

III. Why did I write a Postmortem?

In my case it was a bit different, I had to write one as part of my learning process following a project to add a new feature in the application that caused an error to some users. So it was actually an Incident Postmortem because I didn’t write it during the execution of a project, but because an error occurred. So it’s our tech lead who asked me to make it with the developer I was working with on this project. We made it and it was really cool!

IV. How I did it

We followed a very complete Postmortem’s template that I invite you to consult. It contains a lot of elements that make it adaptable to a lot of use cases, but it is up to you to pick some of them related to your situation.

We started by answering the main questions:

• What was the problem?
• Why and how did it happen?
• What impact did it have?
• How did we detect the incident?
• What action did we take immediately?

So, we brainstormed and got back into all the procedures that have taken place since the detection of the incident, and even more: since the beginning of the project because we had to solve the issue while writing this Postmortem. It was not an easy exercise because it asked us a lot of questions and we had to make it as relevant as possible.

Once we had clearly answered these questions: we established a timeline and identified the root cause of the problem. Then we were able to extract lessons to be learned from this experience, the areas of improvement in order to avoid similar incidents and actions to take for future projects. We had a lot of interactions with our tech lead to get his feedback and give us his point of view as well.

When our Postmortem seemed to be over, we shared it with the whole team and collected their feedbacks.

V. What’s next?

Once completed it’s recommended to share it with the whole team: It’s the goal of this whole process. Sharing it internally allows your team to learn about the topic, the incident that occurred, and actions that have been or will be taken. It aims at avoiding repeating the issue.

Depending on the reason for writing a Postmortem, it may also be interesting to share it publicly. This can be useful for other teams who have already encountered the same problem or who may be facing a similar situation.

Also, some companies may be interested in sharing it with their customers, which is a sign of good practice, rigour, seriousness, and quality.

VI. What it brought to me

One thing I have learned from this experience is the good and bad practices I had during the project realization. Another thing I have learned is the actions to be taken when managing an incident Postmortem.

I really enjoyed the communication with the team during this process. Sharing this experience with them was great, constructive, and interesting.

VII. The final word

In my opinion, I think that all teams should be aware of this good practice and should try to integrate it into their workflow. Following this process is as beneficial for the writers as it is for those who will read it.

I am really happy to work within a team that works with this kind of process, and I hope that reading my article will make you want to integrate it into your own and realize how useful a Postmortem is!