Published on April 15, 2025
Last updated on April 15, 2025
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.
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.
Incident post-mortem meetings are structured, meaning they serve to:
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:
Post-mortem meetings are held for a reason, actually for many good reasons.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.