Why Most Project Management Post-Mortems Fail and How to Fix Them

One of the clearest signs that an organisation has not in place adequate learning cycles is the fact that they insist on having post-mortems.

As the name suggests, post-mortems happen once after a project's mortem, which means once it's over and it's too late to make it any better. One may argue that at that point, any effort to learn is a waste or risks to be so.

I don't think that that's necessarily the case, but it is very common that post-mortem conversations end up being just a shallow exercise that reinforces blaming culture and results in a series of empty statements that, for many reasons, are often not picked up by the team that is supposed to benefit from them in their new project.

While in most scenarios where work happens in a complex context, the ideal approach would be to shift to an agile approach where revision of outcomes and ways of working happen as a regular step of the PDCA (Plan-Do-Check-Act) cycle, it's also important to acknowledge that organisations and teams may not be ready for a radical change. It's important for a change agent to learn to meet the people they work with where they are and gradually coach them into a better state.

Improving the value and efficacy of post-mortems can become the first step toward building organisations that are truly focused on learning and will eventually recognise the value of embracing an agile mindset.

Let's see, therefore, a series of standard questions that can hopefully help in those contexts where post-mortems are still mandated as the main way to improve processes.

What are the biggest mistakes to avoid when running post-mortems, and why?

Agile teams adopted the practice of reflecting regularly in retrospectives to identify opportunities to improve processes and, ultimately, outcomes. After a few iterations, conversations often end up feeling like a routine hygiene practice, where people feel safe to share their insights, knowing that it will lead to benefits for themselves.

Being one-off events, usually organised not as a default practice but only when a project ended poorly, post-mortems rarely lead to the same level of psychological safety that allows deeper and more powerful insights to emerge.

Because of that, extra care must be built in to create the conditions so that a minimum level of safety can be achieved:

• Connection before correction: don't jump straight into dissecting what went wrong with the project, but allow time for people to ease into the session and re-establish rapport. This is particularly important if the team that worked on the project has already been disbanded
• Make it about actions and roles, not people: in post-mortems, the focus inevitably goes to what went wrong. Naming individuals as responsible for mistakes will likely create resentment and defensiveness. The language should focus on the action, not the person who performed it. Shifting the focus to roles rather than individuals further reduces this risk and also encourages reflection on how to reuse the learning (e.g., from “John ought to…” to “The Scrum Master's responsibilities included…”).
• Balance problems with successes: while the purpose of a post-mortem is to learn from what went wrong, dedicating space to what worked well helps maintain motivation and balance. Highlighting successes reinforces constructive behaviours and gives the group a more grounded perspective for future improvements

Together, these practices help post-mortems feel less like fault-finding exercises and more like shared opportunities for learning, trust, and renewal. 

What are the must-do practices that make a post-mortem meeting successful and actionable?

It may sound obvious, but the single most important part of a post-mortem is turning insights into action. Too often, participants focus on documenting every single issue instead of narrowing down to a few key outcomes and ensuring follow-up actually happens.

To this extent, it helps to:

• Involve a professional facilitator: facilitation looks simple, but it's hard to do well. A skilled facilitator can quickly generate a wide range of insights, cut through the noise to prioritise what matters most, and leave enough time to turn discussion into actionable outcomes rather than just clever observations.
• Shift from "what if" to "what now": focus on lessons that are not overly context-specific, so that solutions can be applied in new situations. There's little value in insights that only make sense within the closed walls of a single project.
• Avoid basic mistakes: overlooking the fundamentals risks compromising the process. Blaming people instead of analysing the process threatens psychological safety; letting discussions ramble away the time undermines trust in the method. A smoothly run session that produces usable outcomes is far more valuable than a messy one that uncovers a single spectacular insight.

When handled with care, post-mortems become less about recording the past and more about building the foundations for better projects ahead.

How do you ensure the meeting stays constructive and not just a venting session?

Short answer: Bring in a professional facilitator and let them do their magic. Ideally, someone who understands the organisation and its context but wasn't directly involved in the project under review.

Long answer: apply the guidance from the previous two answers and, on top of that:

• Venting is good when done purposefully: dissent or the need to vent shouldn't scare us. Normalising emotions by giving them space matters, as people can't think rationally while in emotional turmoil. And in the end, a display of emotions is a sign that people care. 
• Smaller groups, smaller problems: advanced facilitation can break participants into small groups and reshuffle them often. This prevents entrenched positions and helps diffuse dissent.
• Hard to complain when one is running: have you ever tried having a heated argument while running? When the pace is high, people save their energy for what really matters. Similarly, keeping sessions brisk with short rounds, tight time-boxing, and varied formats creates a sense of urgency that leaves little room for endless complaints.

Done well, these approaches transform post-mortems from potential gripe sessions into constructive spaces where energy is channelled into learning and progress. 

What's your go-to framework or structure for guiding post-mortem discussions?

There isn't a one-size-fits-all solution. Designing a well-thought-out post-mortem is at least as important and hard as running an efficient one. Different audiences and different insights will respond to the same format in very different ways.

It's also very important to be ready to pivot in the moment, depending on what energy emerges in the room once the conversation starts.

That said, there are a few techniques that I always keep in my pocket:

• Silent writing: ask each participant to write their thoughts in silence and add them to a shared space (wall, digital board, etc).
• 1-2-4-all and similar aggregation techniques: participants first reflect alone for one minute, then in pairs for two minutes, then in groups of four for four minutes, before sharing highlights in plenary. It helps ensure every voice is heard at least once and a consensus is built gradually.
• Silent sorting: participants plot information on a grid according to certain values. If they disagree with a placement, they move it. All of this is done in silence until the system begins to stabilise; only then is open discussion invited. This is another way to contain dominant voices and create space for the insights of the quieter ones.
• Breaks: too often sacrificed in favour of covering more ground, pre-set breaks give people a chance to recharge, reconnect, interrupt emotional spirals, and return to rational thinking.

Ultimately, the key is to strike a balance: enough structure to keep the discussion productive, with enough flexibility to make every post-mortem truly valuable.

Can you share one example of a post-mortem that led to meaningful, lasting improvements for your team?

This is a very hard question for me to answer for 2 reasons:

• As an agile practitioner, I very much prefer constant reflections while a project is still active and change is possible, rather than investing time in reviewing something that by definition has already become immutable.
• Most "lessons learnt" I've seen ended up in a document that sits in some knowledge repo and is hardly ever read. When they are, people who consult them often lack the context to understand why something happened.

All of that said (and even more not said!) I have had some extremely positive experiences with post-mortems, and that was when I was working in a suite of products. Each new product shared a lot of similarities with the previous ones: same technical environments, similar technological stack, often the same customer, and some of the developers who would have worked on the new project had already helped on the old ones.

Reflecting on previous implementations made us short-circuit decisions around tech-stack choices, but also the sequencing of events during the early development stages. It allowed us to choose a process that was already optimised for the type of work ahead. It made it very simple to write strong business cases around the number of people that we wanted to bring on board and what their skill set should have been.