Post-Mortem Analysis

Post-mortem analyses review projects from start to finish to determine process improvements and ensure that inefficiencies are not repeated in the future. In the Project Management Book of Knowledge (PMBOK), this process is referred to as “lessons learned”.

Post-Mortem Analysis	Description	Analysis	Implications	Applications	Examples
1. Define the Event (DE)	Post-Mortem Analysis begins by defining the event or incident that requires analysis and review.	– Clearly describe the nature and scope of the event, including when and where it occurred. – Identify the key stakeholders involved and affected by the event. – Establish the objectives and goals of the post-mortem analysis.	– Provides a clear understanding of the event’s context and significance. – Sets the scope and expectations for the analysis process.	– Analyzing a software outage that disrupted a web service. – Reviewing a security breach that compromised customer data.	Event Definition Example: Defining a data center outage that led to service disruptions.
2. Data Collection (DC)	Collect relevant data and information related to the event for a comprehensive analysis.	– Gather data through various means such as incident reports, logs, interviews, and eyewitness accounts. – Ensure that data collection is systematic and includes all relevant details and timelines. – Preserve evidence and documentation related to the event.	– Provides a factual basis for analysis and helps in reconstructing the sequence of events. – Ensures that the analysis is based on accurate and comprehensive information.	– Collecting incident reports and log files related to a network outage. – Interviewing team members who were involved in a project that experienced delays.	Data Collection Example: Gathering logs, communication records, and eyewitness statements regarding a security breach.
3. Root Cause Identification (RCI)	Identify the root causes or factors that contributed to the occurrence of the event.	– Apply investigative techniques to identify the underlying reasons behind the event. – Use tools such as the “5 Whys” technique to probe deeper into the causal factors. – Distinguish between immediate causes and root causes.	– Enables the precise identification of the fundamental issues that led to the event. – Helps in understanding why the event occurred and how to prevent similar occurrences.	– Determining the root causes of a project delay that resulted in missed deadlines. – Identifying why a manufacturing process malfunctioned, leading to a product recall.	Root Cause Identification Example: Concluding that a software vulnerability was a root cause of a security breach.
4. Impact Assessment (IA)	Evaluate the impact and consequences of the event on the organization, stakeholders, and operations.	– Assess the extent of damage, losses, and disruptions caused by the event. – Identify the affected stakeholders, including customers, employees, and suppliers. – Analyze the financial, operational, and reputational impact of the event.	– Provides a comprehensive view of the event’s consequences and associated costs. – Helps in prioritizing recovery and mitigation efforts based on the severity of the impact.	– Evaluating the financial losses incurred due to a data breach. – Assessing the operational disruptions caused by a supply chain interruption.	Impact Assessment Example: Analyzing the customer trust and reputation damage resulting from a product quality issue.
5. Lessons Learned (LL)	Document and extract valuable insights and lessons from the event for future improvements.	– Identify the key lessons and takeaways from the event, both positive and negative. – Document best practices and areas for improvement based on the analysis. – Propose recommendations and action items to prevent similar events in the future.	– Facilitates organizational learning and continuous improvement by capturing knowledge from the event. – Provides actionable insights to enhance processes, procedures, and risk mitigation strategies.	– Documenting best practices for incident response based on a cybersecurity breach. – Proposing process improvements to prevent project delays.	Lessons Learned Example: Identifying the need for enhanced cybersecurity measures after a data breach incident.
6. Action Plan (AP)	Develop a clear and actionable plan to address the root causes and implement preventive measures.	– Specify the corrective actions required to address the identified root causes. – Assign responsibilities, timelines, and priorities for implementing the action plan. – Ensure that the plan includes preventive measures to avoid future occurrences.	– Provides a structured and comprehensive approach to addressing the root causes and preventing recurrence. – Ensures accountability and follow-through on corrective actions.	– Creating a project plan to enhance cybersecurity defenses after a security breach. – Developing a supply chain risk mitigation plan following a disruption event.	Action Plan Example: Specifying the steps to patch software vulnerabilities and improve security protocols after a breach.
7. Implementation (IM)	Execute the action plan and monitor progress to ensure that corrective actions are carried out effectively.	– Assign responsibilities to individuals or teams for each corrective action. – Track the progress of implementation and ensure adherence to timelines. – Communicate the status of corrective actions to relevant stakeholders.	– Ensures that the action plan is executed effectively and within specified timelines. – Allows for real-time monitoring and adjustment of actions as needed.	– Carrying out software updates and security enhancements as part of a cybersecurity action plan. – Monitoring supplier relationships and implementing risk mitigation measures in a supply chain plan.	Implementation Example: Rolling out a revised production process to address root causes of product defects.
8. Evaluation (EV)	Assess the effectiveness of the action plan in preventing similar events and improving overall processes.	– Measure and evaluate the impact of corrective actions on preventing recurrence. – Use data and performance indicators to assess the effectiveness of actions. – Compare post-implementation results with pre-implementation data to verify improvement.	– Determines whether the action plan has been successful in addressing root causes and preventing recurrence. – Validates the effectiveness of the corrective actions and their impact on outcomes.	– Assessing whether the new cybersecurity measures have prevented further security breaches. – Evaluating whether supply chain risk mitigation measures have enhanced resilience.	Evaluation Example: Comparing product defect rates before and after process changes to verify improvement.

Table of Contents

Understanding a post-mortem analysis

In business, a post-mortem analysis identifies the causes of an event to understand why it occurred and better prepare for future projects.

Post-mortem analyses tend to be performed at the end of a project, but larger or more complex projects may necessitate that they be held on a monthly, quarterly, or annual basis.

More frequent meetings enable the team to course correct and avoid important issues being overlooked.

Some teams skip this process because of time or resource constraints or an incorrect assumption that a post-mortem analysis does not contribute to the company’s bottom line.

When done correctly, however, post-mortem analyses are critical to the development of process improvements and best practices that can be used to repeat successes in the future.

Instead of rushing from one project to the next to generate more revenue, the company must take the time to examine all aspects of the project lifecycle.

Each member of the project team – including stakeholders and clients – should also feel free to note any issues or problems in a collaborative environment.

How to conduct a post-mortem analysis

The most effective post-mortem analyses are also the most organized and occur while the details of the project are still fresh in the mind of participants.

Step 1 – Create the agenda

The agenda only needs to be created once and can be tweaked for any future analysis. It should detail:

What went well (the wins).
What did not work well (the losses).
Whether the project accomplished what it set out to do (the outcomes).
Suggestions for improvement, and
Wrap up.

The business can also send a questionnaire to those involved to better understand what worked and what didn’t.

The questionnaire can be sent before the analysis starts to save time and its anonymous nature increases the quality of the feedback.

Step 2 – Select a moderator and notetaker

The moderator is often the project manager, but a meeting facilitator can be selected if the business desires more neutrality.

In any case, the moderator’s primary role is to keep the meeting on topic, set out the agenda, and provide a recap of the project.

Notetakers are especially important for recording details if tech such as smartphones or laptops are banned from the post-mortem analysis.

Step 3 – Establish rules

The moderator then establishes some basic ground rules that help the team avoid straying off-topic. Examples include:

Tech that could distract the meeting is not permitted.
Keep the discussion objective and free from blame.
Maintain a polite and positive atmosphere.
Each person shall be given a set amount of time to speak uninterrupted, and
Feedback should be specific, actionable, and constructive.

Step 4 – Host the meeting

The meeting then proceeds according to the agenda. In the context of project management, questions usually relate to:

Planning – was any aspect of the plan too vague? Were budgets, personnel, and tools allocated correctly?
Execution – where did the workflow fail or where was it not adequately documented? Did any project team member have trouble meeting timelines set in the plan?
Results – did the project meet its primary objective? Was the client happy with the results? Would the team otherwise consider the project a success?
Communication – was the project manager able to communicate with the team effectively? Could the meetings have been more effective? Were there too many meetings or too few?

Step 5 – Celebrate wins and conclude

To conclude, the moderator should make time to move around the room and attribute wins to each individual. The moderator should be specific and thank the team member for their contribution to help them feel valued.

Once the meeting is over, a copy of the main takeaways should be sent to the team. There may also be action items or clarification on what the team can expect when it comes time to work on the next project.

Case studies

Software Development Project:
- Understanding: The team developed a new software feature, but users reported multiple bugs after its release.
- Post-Mortem Analysis:
  - Agenda: Review the software development process, testing phase, and user feedback.
  - Moderator and Notetaker: Lead developer as the moderator, QA engineer as the notetaker.
  - Rules: Avoid blaming specific team members, focus on the process, and be open to feedback.
  - Meeting: Discuss the development process, identify gaps in testing, review user feedback, and discuss communication breakdowns.
  - Conclusion: Celebrate the successful launch, address the identified gaps, and implement changes for future projects.
Marketing Campaign:
- Understanding: A marketing campaign did not achieve the expected conversion rate.
- Post-Mortem Analysis:
  - Agenda: Review the campaign strategy, target audience, and execution.
  - Moderator and Notetaker: Marketing manager as the moderator, digital marketer as the notetaker.
  - Rules: Focus on objective data, avoid subjective opinions, and encourage constructive feedback.
  - Meeting: Analyze the campaign’s reach, engagement metrics, audience feedback, and budget allocation.
  - Conclusion: Celebrate the team’s effort, identify areas of improvement, and strategize for the next campaign.
Product Launch:
- Understanding: A new product launch did not meet sales targets.
- Post-Mortem Analysis:
  - Agenda: Discuss product development, market research, pricing, and promotion.
  - Moderator and Notetaker: Product manager as the moderator, sales lead as the notetaker.
  - Rules: Stick to facts, avoid assumptions, and promote a collaborative environment.
  - Meeting: Review product features, customer feedback, competitor analysis, and promotional activities.
  - Conclusion: Recognize the team’s hard work, learn from the feedback, and refine strategies for future launches.
Customer Support Initiative:
- Understanding: A new customer support initiative did not reduce the ticket resolution time as expected.
- Post-Mortem Analysis:
  - Agenda: Review the new processes, tools used, and feedback from support agents.
  - Moderator and Notetaker: Support team lead as the moderator, senior support agent as the notetaker.
  - Rules: Encourage open communication, avoid defensive attitudes, and prioritize actionable feedback.
  - Meeting: Discuss the new support process, tools’ effectiveness, agent training, and customer feedback.
  - Conclusion: Praise the team’s dedication, identify gaps, and make necessary changes for better efficiency.
Event Organization:
- Understanding: An organized event did not see the expected attendee turnout.
- Post-Mortem Analysis:
  - Agenda: Review event promotion, target audience, logistics, and feedback from attendees.
  - Moderator and Notetaker: Event coordinator as the moderator, logistics manager as the notetaker.
  - Rules: Maintain a positive attitude, be open to feedback, and focus on solutions.
  - Meeting: Analyze the promotion channels used, event timing, venue selection, and attendee feedback.
  - Conclusion: Acknowledge the team’s effort, learn from the feedback, and plan better for future events.

Key takeaways:

In business, a post-mortem analysis identifies the causes of an event to understand why it occurred and better prepare for future projects.
Some teams skip the post-mortem analysis because of time or resource constraints or a belief that it does not contribute to the company’s bottom line. However, these analyses are essential to improve processes and develop repeatable best practices.
The five steps of conducting a post-mortem analysis include creating the agenda, selecting the moderator and notetaker, establishing rules, hosting the meeting, and concluding by celebrating wins.

Key Highlights

Understanding a Post-Mortem Analysis:
- Identifies causes of events to prepare for future projects.
- Typically conducted at the end of a project, but complex projects may require more frequent reviews.
- Some teams skip this process due to time constraints or overlooking its value for process improvements.
How to Conduct a Post-Mortem Analysis:Step 1 – Create the Agenda:
- Outline the agenda detailing what went well, what didn’t, project outcomes, suggestions for improvement, and a wrap-up.
- Use questionnaires sent to participants to gather feedback anonymously.
Step 2 – Select a Moderator and Notetaker:
- Moderator (usually the project manager) keeps the meeting on track and provides a recap of the project.
- Notetaker records details, especially if tech is banned during the analysis.
Step 3 – Establish Rules:
- Set ground rules to maintain focus and objectivity.
- Ban distracting tech, keep discussions blame-free, maintain a positive atmosphere, provide uninterrupted speaking time, and offer specific, constructive feedback.
Step 4 – Host the Meeting:
- Address questions related to planning, execution, results, and communication.
- Discuss aspects like vague plans, workflow issues, meeting effectiveness, and client satisfaction.
Step 5 – Celebrate Wins and Conclude:
- The moderator attributes wins to each individual, acknowledging their contributions.
- Provide a copy of the main takeaways to the team and clarify action items or expectations for the next project.