Nerd For Tech
Published in

Nerd For Tech

How to Write a Postmortem for Your Project in 5 Simple Steps

Tips and Tricks on how to learn faster from your mistakes

Photo by JESHOOTS.COM on Unsplash

Mistakes. We all make them. On the job it can really impact your timelines and the quality of your work.

This article include 4 do’s and 1 don’t on how to get better, quicker. I detailed how I broke down my latest project and tackled the issues that held me back. I hope this specific example can help you improve and to avoid pitfalls for your own work.

My projects generally involve software, but these principles should work for any type of project. You can do this by yourself or with a team, but I encourage you to share this process with at least 1 other person to get a different perspective. From my experience, to engage others in this activity will maximize the benefits.

This article is also expounding on the first point made in this previous article: 5 To-dos at the End of Your Project

1. Do: Break-down the Project into Sections

I sectioned the parts of my project I wanted to review based on the project’s time flow, the skill-sets I used and the team transitions.

I was on a project involving other teams (each with their own function in the project), so the sections I list below made sense for this project. There can be overlap to the sections you choose, but I tried to avoid it. I think a good time for overlap is if a skillset that worked for one situation did not work for the other and I wanted to make a note of where it was effective (and vice versa).

Here’s a specific example from my postmortem on how I broke mine down:

  • Planning
  • Communications
  • Coding (Acting on the plans)
  • Quality Control (Testing the outcome)
  • Continuous Integrations (Maintaining the integrity of the overall project)

I named these sections to give myself context in the future.

Bad context, for example, would be if I put: Phase 1, Phase 2, …, Phase 5, etc. because it doesn’t specify to future-me what I did in each phase. Planning, on the other hand, is more specific than Phase 1, because it summarizes what I did.

2. Do: List Both the Good and the Bad

Why not just the bad?

I highly recommend spending the time to write out what worked. A postmortem is not just a place to list all that went wrong. Not only is listing what worked a morale booster, it was important for me to be able to clearly identify the actions that deserved repeats. It has the same import as knowing what needs to be changed.

Doing my postmortems during my project or immediately after helped me better remember the successes and failures. On the other hand, if I forget something I’m also likely to repeat it, so it was definitely up to me on how long I wanted to keep making the same mistakes.

An example from my postmortem:

  • Good:

Demoed to Quality Control team on how the product should work. Opened the floor up for Q&A. This gave them a baseline on how to test the new feature.

  • Bad:

Clearly communicated task dependencies to the parties involved to drive urgency and highlight priorities.

The good worked because I specified what behavior I wanted to repeat and with whom. I also highlighted the main goal of the action and why it was important. The focus here is to be as specific as possible.

The bad didn’t work because I was vague on how I communicated, who I communicated to, and which context to apply these actions for max benefits. Even though it looks and sounds good on paper, it’s too vague for me to followup on. A month from now I’m not going to be able to compare this to another recommendation and know which one is better to apply to a given situation.

3. Do: Ask What Could I Have Done Differently?

Evaluating my reactions will provide me with more choices for next time.

Now that I’ve written down my successes and failures, I can think about how I got there, what I should continue doing well on, and what I could do differently.

For successes, I spend time thinking about why it was successful. How would I improve or stream-line this success? Is there a context I can provide so I can tease out the nuances necessary to continue getting good results?

For failures, I think about the context of the situation. How might I have avoided the pit-falls I didn’t look out for? Were there other choices I didn’t consider in the heat of the moment?

An example is to add to the earlier good example I used in part 2:

Demoed to Quality Control team on how the product should work. Opened the floor up for Q&A. This gave them a baseline on how to test the new feature. Schedule more time in the future to prepare for the demo and include the time needed to demo.

Again, the more specific, the better.

4. Do: Request Feedback

It’s uncomfortable, but this is the secret sauce.

While this may not be applicable working on your own, it’s always good to review with someone. I tend to go over my reviews not just with my manager but with my teammates. This allows people a chance to tell me what they liked and didn’t like when they worked with me. I tend to do this in an open forum (assumption here is that participants are comfortable speaking up). I find it allows people to bounce off of each other and expose issues in better detail, from multiple perspectives.

If I had been working on my own, I would share my list with someone I trusted. Going over my list helped me rediscover problems and positives I might have forgotten about in the original write-up. It also helped me to explain my process, step-by-step, to someone else so I can pin-point where it got the messiest.

When I did this with my team, I made it clear to everyone that the goal of the meeting was to examine what obstacles we ran into and distill what we have learned. This way people are prepared to speak up. I also gave them a heads up on specific sections I would likely ask for their insights on. If the team wants good insight, the team needs to have time to think about it seriously.

5. Don’t: Blame Others (No Matter How Tempting)

It’s not about what others could have done better this time, it’s about what I should do differently, next time.

This is actually why I like to do the public forum. For me, it’s an additional barrier to help keep myself from playing the victim. I find doing this in front of the people I work with (versus just writing everything down), tempered my desire to say: “It wasn’t me, it was XXX!” or “If XXX did his work on time then I would have gotten different results!”

The victim card detracts from the important thing I need to answer: What did I do this time that I need to change? It also allows others to share their perspectives about notable situations. I have experienced coworkers highlighting events I had overlooked because I was focused on other pain-points.

If I had worked by myself, I would also have to resist blaming the situation (just as I would another person). I would want to think about how I got myself into that situation. If what happened was good: How would I recreate the same conditions? If it was bad: How do I avoid the situation or the conclusion of the situation, in the future? The key is to figure out where my power exist to mitigate the causes and to examine my reactions to see what needs tweaking.

And I confess, it is still extremely tempting for me to spend time on what someone else did or a bad situation. I have done it and I will likely keep doing it. However, I always try to remember, the goal of doing a postmortem is to improve myself, to do and effect change. Shifting the blame, no matter how good it feels, does not help me achieve that.


If you want different outcomes, evaluating your actions in a project is one of the most impactful steps to take. With the above postmortem techniques I hope to provide help in making the exercise more productive. Hopefully, you can better navigate to the decisions that will get you to your desired results.

Above all else, give yourself both the space to improve and the space to make mistakes (new ones and old ones). By doing these evaluations regularly, you can change some long-standing habits and choose the actions that will come to define you. Take the lessons you can from any given situation and keep moving forward.

Photo by Ante Hamersmit on Unsplash



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Julia Yang

Julia Yang

I’m a full-time Software Engineer working for a global tech company. I want to share the things I’m learning; hopefully, it will help those in my field.