Debriefs, Project Wrap-Up or Post-Mortems to Learn From Mistakes

Your vision is to test new things and learn from what some may call mistakes. Ideally, the same mistakes wouldn’t repeatedly happen because you learn from them. What steps have you taken up to this point to ensure there is a formal process to review what went right, what went wrong, and what could be improved? If the answer is nothing or very little, keep reading. This article is going to discuss debriefs, project wrap-ups, or post-mortems.

What is a debrief, project wrap-up, or post-mortem?

For the purpose of this article, the term debrief will be used. There are some slight differences between these terms if you do some Googling. However, the point of this article is to ensure you are learning from mistakes and therefore, choose the term you feel comfortable with or make up a new one. Other common names are lookback, lessons learned, after-action reviews, retrospectives, and critical incident reviews.

The end result is that you need to learn and iterate, regardless of what you call it. This is a process done at the end of a project or job where you take some time to meet as a team and document some of the major points of a project. The goal is to drive improvements in the process and ensure the team is using best practices and using the successful tactics again in upcoming projects. If something major occurred derailing due dates, make sure it's accounted for and avoided in the next project.

This is a list of requirements for a debrief to cover:

1. What went well? Were due dates hit on time? Was communication strong enough to keep the project on track?
2. What didn’t go well? Did you find a team member had too little availability slated for the project? Did you run into surprises with vendors and suppliers being unable to produce and deliver on time? What about unexpected or unforeseen costs?
3. General observations. Makes notes if there were issues in communication styles for example so it can get worked out now for future projects. If key people, for example, were pulled in too late, make those kinds of notes.
4. Suggestions to improve what didn’t go well for the future to avoid the same mistakes. Stating what didn't work alone won't be helpful. Ideas and paths to improvement are required.
5. Determine if the project met company objectives. You may not yet know if sales levels were where they projected, but you will know if the project or job was completed according to the original specs. If it wasn't, why wasn't it, and was that pivot approved along the way?
6. Action items if necessary and applicable. For example, if more meetings were needed along the way, note this as an action item so for the next project, those meetings are set up in advance. If customers need to be contacted because something went wrong during the project, ensure that action is followed up on.

Why do you need to do debriefs?

Formal documentation of this process is the only way to get all thoughts in one place where it can be talked about, addressed, and acted on. This process provides transparency into what went on during the course of the project or job. Without doing this, it's common for things to be forgotten down the road, and if you don't talk as a team, major flags could be missed allowing for repeats of the same behavior.

When should you do a project debrief?

Time needs to be taken when the project is still fresh in everyone’s mind to go through this process. If you follow other project management methods, you will likely be doing something similar to this process along the way. Either way, it's critical for future success to ensure this process is done upon completion, regardless of how many other times it was done during the project.

Key considerations in debriefing

1. This is not a time to place blame and the environment needs to be psychologically safe.
2. It should be close to project completion, yet enough time should pass from project completion to this process where everyone has a clear head.
3. The invitee list should be all of the key people who contributed to the project.
4. The team should individually collect their thoughts and come prepared to the meeting.
5. Once the meeting concludes, you should have a single document that can be used to reference. This is helpful in particular when it’s a project type that may occur annually. Having this document serves as a tool for the next time, and you don’t have to rely on memory.
6. List the project name and dates run. Dates are important to look into whether timelines were met, where there wasn't enough time, too much, etc.
7. If you have other metrics to include, add those to this document. For example, if you were working on a new launch, and have metrics surrounding pre-sales or launch day, this can be helpful for future launches to have a baseline.

In summary, the name you use for this process is not as important as the outcome. Whatever the format, you should walk away from this meeting with a single document outlining the type of project, what went well, and what could be improved for next time. Ensure everyone has a voice, and that the environment is psychologically safe so that people feel they can be honest.

Written by Nicole Hullihen, February 27th, 2022