What Is a Post-Mortem Meeting, and How to Conduct
Book A Demo Today

What Is a Post-Mortem Meeting, and How to Conduct

Published on April 15, 2025

Last updated on April 15, 2025

Jump to a section

After weeks, maybe even months, you have completed your project. Now what?

As tempting as it might be to jump straight into the next one, there is something important you need to do first: a post-mortem meeting. Think of it like cleaning up the mess after a party. Until the wrappers are in the bin and the carpets are clean, it can be tricky to start setting up for the next event.

What Is a Post-Mortem Meeting?

A post-mortem meeting is a meeting originated in engineering and IT to analyse system outages or incidents after they occur, primarily including what happened, what went well, and what could be improved upon and prevented in the future.

While in this article we are focusing on post-mortem meetings in the context of incident management, it's worth noting that post-mortems are not exclusively held in the realm of engineering and IT and, in fact, widely applicable across industries and project types.

Plus, many teams now hold positive post-mortems to understand why something was successful and how to replicate it. That is, as much as we can learn from mistakes, we should learn and build from successes, too.

What Are the Primary Goals of Post-Mortem Meetings?

Incident post-mortem meetings are structured, meaning they serve to:

  • Understand the root cause of the incident, which is also known as root cause analysis (RCA)
  • Document the timeline of events and responses
  • Identify gaps in monitoring, communication, tools, or processes
  • Create actionable improvements to reduce the likelihood and impact of future incidents
  • Encourage learning and accountability rather than finger-pointing

Who Should Attend a Post-Mortem Meeting?

In order to get the full picture of the incident, everyone directly involved should be invited to the meeting, not only leadership. This may include, but is not limited to:

  • Project lead or moderator – to provide context and guide the discussion
  • Team members – to share frontline insights and technical details
  • Relevant stakeholders – to contribute business or client perspectives
  • Facilitator (if needed) – for larger teams or when navigating sensitive topics

Key Benefits of Post-Mortem Meetings

Post-mortem meetings are held for a reason, actually for many good reasons.

Facilitates Decompression

Incidents can be high-stress, fast-moving, and emotionally draining, especially for those on-call or on the frontline. A post-mortem meeting provides space to decompress—a short pause to assess what happened in a structured, low-stress environment. Most importantly, it helps teams shift out of firefighting mode and into learning mode.

Encourages Transparency and Psychological Safety

When run well, post-mortem meetings provide team members with a safe forum to speak openly. This fosters psychological safety and makes it easier to surface concerns, flag issues, and share honest feedback without fear of blame or judgment. This is particularly important in cases of mistakes and failures when boosting team morale is of the utmost priority.

Uncover Blind Spots

In the rush of trying to fix the issue at hand, it's almost impossible to spot root issues or unhelpful patterns. When you get together for an incident post-mortem meeting, however, team members are given time and space to communicate and share their individual experiences of how the project went. Pieced together, these perspectives often reveal blind spots or bottlenecks that weren't visible at the time.

Identifies Systemic Issues

Not all problems are unique to one project, so looking for patterns in your post-mortem meetings can expose what might be recurring issues, such as flaws in tools or poor workflows that affect delivery across the board. Spotting these can help teams implement process improvements, and leadership prioritise what needs fixing at an organisational level.

Builds Organisational Memory

Lessons fade quickly if they are not recorded. A post-mortem helps capture what worked and what didn't, supports knowledge sharing across teams, and gives new employees something solid to refer back to. With the right tools, like an incident management platform, this knowledge can be stored, shared, and embedded into playbooks and runbooks for future use.

Improves Future Projects

With a bird's eye view of what helped or hindered delivery, it is much easier to take forward the right actions. Whether that means replicating an effective comms approach or scrapping a process that slowed you down, the post-mortem helps you make smarter choices next time.

Feeds into Risk Mitigation

As mentioned earlier, post-mortem meetings often surface unanticipated risks such as missed dependencies, unrealistic timelines, or supplier issues. Feeding these back into your risk management can help strengthen future business resilience.

Enhances Team Collaboration

Incident response can strain team dynamics, especially under pressure. Post-mortems are a chance to reset as they give people the opportunity to reflect, acknowledge one another's contributions, and address any tension in a constructive setting. This kind of open and respectful discussion is key to preventing resentment from building and overflowing into future projects.

How to Conduct a Successful Post-Mortem Meeting

If you want your post-mortem meeting to be more than just a box ticked, approach it with a plan to hand. This means preparing before the meeting, conducting it with intention, and ensuring that outcomes lead to real improvements in how incidents are detected, escalated, and resolved in the future.

Before the Post-Mortem Meeting

  • Schedule promptly: Schedule the post-mortem within one to two weeks of the incident being resolved. This gives teams a moment to regroup while keeping the event fresh in their minds.
  • Send out pre-meeting forms: Encourage team members to reflect on what went well, what didn't, how the incident was handled, and what could have improved detection, communication, or resolution.
  • Create a focused agenda: Don't wing it. A good post-mortem meeting agenda should be informed by the main points highlighted in the above forms. This will help to cut down on waffles during the session.
  • Assign a moderator: Ensure that the person expected to lead the meeting (for example, the project manager) has been informed of this. Also, make sure to send communications to any other relevant stakeholders who are expected to contribute to key points in the agenda.
  • Assign a minute taker: Appoint someone other than the moderator to take notes on the meeting. If the meeting is conducted virtually, it may also be helpful to record it so that it can be referred back to at a future date.

During the Post-Mortem Meeting

  • Keep it structured: Stick to the agenda and use time blocks to stop a single topic from dominating the discussion.
  • Keep it blameless: Avoid finger-pointing and focus on understanding the contributing factors, whether technical, process-related, or organisational. Most incidents are the result of a chain of events, not a single error.
  • Make space for all voices: Some team members won't speak up unless invited. To make sure everyone has a voice, use round-table questions and make it clear that the meeting is a judgment-free zone.
  • Use a facilitator (optional): Especially in high-stakes or cross-functional incidents, a neutral facilitator can help keep the conversation balanced, prevent dominant voices from taking over, and ensure the session doesn't turn into a blame game.

After the Post-Mortem Meeting

  • Write a clear, concise post-mortem report: Take all the insights you have collected and collate them into a report that you can refer back to in the future. Consider summarising and grouping the most useful points, making sure to cut any repetition or redundancies. You may also want to include key lessons learned, action items and owners, and any follow-up deadlines.
  • Follow through by applying the lessons learned: Update your runbooks, playbooks, and incident response documentation based on what was learned. If applicable, revise monitoring thresholds or escalation protocols to catch similar issues earlier next time.

Examples of Post-Mortem Questions

If you are tasked with holding your first post-mortem meeting after an incident, fret not. Here are some of the questions to ensure structured, productive, and successful post-mortem meetings.

Post-Mortem Questions for Project Overview

  • What was the original goal of this project?
  • What were the key deliverables and deadlines?
  • Was the objective clearly defined and understood by everyone involved?

Post-Mortem Questions for What Went Well

  • What aspects of the project went smoothly?
  • Which parts of the process were most effective?
  • What tools, strategies, or communication methods supported success?
  • Were there any surprising wins or unexpected achievements?

Post-Mortem Questions for What Could Have Gone Better

  • What did not go as planned?
  • Were there any missed deadlines or deliverables?
  • Which obstacles slowed us down, and why?
  • Were there any bottlenecks, misunderstandings, or miscommunications?

Post-Mortem Questions for Processes and Planning

  • Did we follow the original plan? If not, why?
  • Were project roles and responsibilities clear from the start?
  • Was the time allocated for each phase realistic?
  • Did we scope the project appropriately?
  • Were changes or scope creep managed effectively?

Post-Mortem Questions for Team and Communication

  • How well did the team collaborate?
  • Were stakeholders kept informed throughout?
  • Did everyone feel heard and supported?
  • Were there any team dynamics that helped or hindered the project?

Post-Mortem Questions for Tools and Resources

  • Did we use the right tools and platforms?
  • Were there any tools that caused issues or slowed us down?
  • Was everyone properly trained to use the systems involved?

Post-Mortem Questions for Results and Impact

  • Did we meet the goals set at the start?
  • How did the results compare with our expectations?
  • What feedback did we receive from stakeholders or clients?
  • Did this project add value to our organisation or audience?

Post-Mortem Questions for Lessons Learned

  • What would we do differently next time?
  • What processes should we keep or improve?
  • Are there areas where we need more training or clarity?
  • What risks should we plan for in future projects?

Post-Mortem Questions for Next Steps

  • Are there any loose ends to tie up?
  • What actions should be taken based on what we have learned?
  • Do we need to update any documentation, templates, or processes?

C2 Meridian for Successful Post-Mortems

C2 Meridian transforms what is traditionally a manually compiled and inconsistently delivered process into a streamlined, auditable, and repeatable workflow embedded within your business continuity management software.

Every incident logged through Meridian BCMS is automatically timestamped, categorised, and linked to relevant BC plans, BIAs, and risks. You can record the sequence of events, impacted assets, communication history, and recovery actions in one centralised place.

After the incident is resolved, Meridian's dynamic reporting engine can instantly generate comprehensive summaries of, for example, impacted services or functions, actions taken and by whom, recovery time vs target time, communication logs, and root causes and contributing factors.

You can also create, assign, and track corrective actions directly from the post-incident analysis interface. These are fully auditable and version-controlled to ensure accountability and continuous improvement. Lessons learned can be added to the plan review cycle and directly influence BIAs, risk registers, and continuity plans—creating a live feedback loop.

C2 Meridian enables your team to make post-incident reviews smarter, faster, and more actionable. No spreadsheets. No silos. Just real insights that drive resilience. Book a demo today.

Send me the latest news and updates on IT & Cyber Security

Written by Richard McGlave

Founder & CEO at Continuity2

With over 30 years of experience as a Business Continuity and Resilience Practitioner, Richard knows the discipline like the back of his hand, and even helped standardise BS25999 and ISO 22301. Richard also specialises in the lean implementation of Business Continuity, IT Service Continuity and Security Management Systems for over 70 organisations worldwide.

Richie c2 profile
Richie c2 profile

Written by Richard McGlave

Founder & CEO at Continuity2

With over 30 years of experience as a Business Continuity and Resilience Practitioner, Richard knows the discipline like the back of his hand, and even helped standardise BS25999 and ISO 22301. Richard also specialises in the lean implementation of Business Continuity, IT Service Continuity and Security Management Systems for over 70 organisations worldwide.