project post-mortem

What is a project post-mortem?

A project post-mortem is a business process that lets the project team, project management, and other stakeholders review and evaluate the results at the end of the project or after the resolution of an incident.

A post-mortem is typically associated with a project failure or serious incident, such as an IT service outage resulting in downtime or other business consequences. However, a post-mortem process can also be applied to successful projects, often called a retrospective meeting instead of a post-mortem.

The goal of any post-mortem is improvement. When performed properly, a post-mortem helps business and project leaders understand what worked and what didn't. It helps participants identify and understand mistakes, missteps and oversights that affected the project or the resolution of an incident.

The insights gleaned from a post-mortem can then be applied to the next project, or they can prompt updates to processes, staffing, tools and infrastructure. This enhances efficiency and prevents repeated problems. A proper post-mortem seeks to learn and improve -- it doesn't place blame.

For example, consider an IT service provider that experiences an outage, possibly violating service-level agreements and damaging its reputation. In that case, a post-mortem analysis might reveal that the outage occurred because of an accidental system misconfiguration which wasn't properly approved or documented. This insight might lead to improvements in IT systems management workflows, approvals, tools and documentation processes.

What are the seven steps involved in a project post-mortem?

A post-mortem is often held in the wake of a project failure or critical issue. The natural human concern about facing criticism and blame can make a post-mortem a stressful and unrewarding experience for project participants. Fortunately, a blameless approach to post-mortems combined with emphasis on transparency and productive communication alleviates much of the stress and results in more effective post-mortem efforts.

There are seven steps that can help post-mortem participants understand the goals and flow of a typical post-mortem:

1. Plan to meet promptly. Whether concluding a project or addressing a critical event, plan the post-mortem as soon as possible after the project is completed or the event is remediated. Prompt post-mortems ensure all aspects of the project are fresh in the minds of participants, especially if participants are involved in other projects that will quickly consume their attention. In some cases, post-mortems are even included in the overall project plan.
2. Establish topics in advance. A post-mortem is more efficient and less stressful when the goals and objectives are identified in advance. Some cases make this clear, such as an incident involving an intrusion or data loss, where the issues to be covered are relatively straightforward and specific. In other cases, the topics focus on more general takeaways from the entire project, the participants and the stakeholders, such as what went well, what didn't go well and what improvements can be made. An example is addressing and eliminating a bottleneck in the workflow.
3. Gather relevant data. Most meaningful post-mortems require supporting data. For a general project, this might involve schedule, cost, market and other business-centric data. For an IT project or incident post-mortem, data might include log files, system configuration data, user activity records, metrics and benchmarks, other technical details, and even questionnaires or open-ended questions circulated ahead to participants. These can all assist in understanding the chain of events. It may take several days to find and prepare the necessary data.
4. Create an agenda. Establishing topics and identifying issues in advance is a good way to create a post-mortem meeting agenda. The agenda does two important things: It sets objectives for the discussion, and it places limits on the discussion. This forces business leaders to focus on the salient points, get answers and move along. Circulating the agenda in advance of the meeting ensures participants understand the goals, know what to expect, prepare thoughts and gather any additional data beforehand if necessary. Relevant data may also be circulated with the agenda to let participants review it prior to the meeting.
5. Assign meeting leaders. The push toward blameless post-mortems means that project managers and other staff involved in the project or incident won't lead the post-mortem meeting. Instead, another senior staff member who wasn't directly involved with the project typically assumes the role of a moderator while a second staff member takes notes. This ensures all participants can speak freely and the meeting is run objectively.
6. Hold the meeting. The moderator has three main jobs: set and enforce ground rules for meeting conduct; guide the conversation forward, largely according to the established agenda; and limit tangential and unproductive discussion. A savvy moderator can take opportunities to tease out details by asking thoughtful post-mortem questions about the project, its perceived challenges, its scheduling and budgeting, whether participants would take on similar future projects, and what they might do differently. It's important for the meeting to address underlying problems, reach meaningful conclusions and offer suggestions for future remediation: "What occurred? Why did it happen? How do we fix it moving forward?" A truly blameless post-mortem won't assign direct responsibility or blame.
7. Report the findings. The post-mortem meeting is typically followed by a recap or report that highlights the findings, takeaways, recommendations and action items arising from the post-mortem meeting. The moderator might be responsible for assembling notes into this final report. The report is shared with the project participants and might be circulated to upper management for business impact study and review.

Who are the key players in a project post-mortem meeting?

There is no universal set of attendance requirements for project post-mortem meetings. The reasons for the post-mortem, the size and scope of the project, the severity and criticality of the incident, and the nature of the business itself might drive different attendance requirements for different projects or incidents. However, some guidelines for required participants include the following:

• Moderator and notetaker. Two staff members who aren't involved in the project typically handle the formalities of leading and documenting the meeting. They will then follow up the discussion with a post-mortem review or report.
• Project leaders or department managers. If the post-mortem is in response to a project, project leaders are required to participate. If it's in response to an incident, department managers, such as IT operations or IT security managers, should participate.
• Project or departmental team members. If the post-mortem is in response to a project, the project team members should attend. If it's in response to an incident, participation will generally involve IT engineering and administrative staff, especially those staffers assigned to a help desk incident.

Beyond the essential participants, other participants might be invited depending on the nature of the business and the impact of the project or incident. These additional participants might include the following:

• Project stakeholders. Project stakeholders, such as the project client or project owners, are ultimately affected by the project's outcome or the remediation of an incident. Their presence might help ensure business transparency and integrity.
• Compliance leaders. Projects and incidents that impact the organization's regulatory or compliance posture include compliance leaders in a post-mortem. For example, an IT intrusion incident that leads to data loss may require the direct intervention of compliance leaders to handle corresponding reporting and remediation in accordance with regulatory compliance requirements.
• Business leaders. Depending on the size, scope and importance of the project or the business impact of an incident, business leaders up to the C-suite might attend the post-mortem. A routine project with simple deliverables and a favorable outcome might not warrant executive participation, but a critical project failure, such as new data center investment gone awry, might justify the presence of senior management.

Project post-mortem mistakes to avoid

The project post-mortem can be a valuable tool for analysis and continuous improvement, reinforcing what went right, understanding and fixing what went wrong, and communicating lessons learned to all of the participants involved. However, there are some common oversights and mistakes that can reduce the value of post-mortems to participants, stakeholders and the business. Common post-mortem mistakes include the following:

• Inadequate preparation. Good post-mortems require data, ranging from system logs to project budgets and customer communication. Relevant data is typically identified and gathered before the post-mortem. However, a lack of goals or clear agenda as well as missing, incomplete or biased data can create a chaotic or poorly handled post-mortem. Participants could miss valuable insights and potential opportunities, effectively wasting the post-mortem opportunity.
• Inadequate communication. A successful post-mortem depends on communication and team collaboration, from soliciting participant feedback to gathering data, holding open and productive post-mortem discussions, and understanding the lessons learned. Poor communication damages the process and limits solution sharing among the participants.
• Assigning blame. Humans don't respond well to blame. Blame creates a toxic and defensive workplace environment. Staff members become more concerned with deflecting blame and defending their actions than participating in an objective discussion. Businesses must embrace a blameless post-mortem environment that encourages honest, open and transparent conversation focused on finding answers.
• No answers. Every good post-mortem should conclude with lessons learned. This may include recommendations for workflow or project management process improvement along with an action plan for implementing those recommendations. Even if underlying issues are identified in a post-mortem, the lack of remediation will waste the post-mortem opportunity. Staff will simply conclude the meeting and the same problems will likely happen again. There must be answers or lessons learned.

Does every project need a project post-mortem meeting?

A project post-mortem can be a stressful and time-consuming exercise, often engaging team members in difficult and uncomfortable discussions. Consequently, conducting a post-mortem on every project completion might not yield corresponding benefits for the business.

Small or experimental projects, such as proof-of-concept projects, might fail simply because they failed. For example, a new tool doesn't integrate with other tools or access a data set as expected, or a new hardware device demanded IT infrastructure changes that couldn't be accommodated without compromising security or network performance. A simple project summary or review with recommendations for further action often suffices in such cases.

The best candidates for a full post-mortem as part of the project are those with the potential to yield the biggest opportunities for business improvement and future project success. Large, long-term investments that haven't delivered the expected business benefits are classic post-mortem targets. Similarly, complex troubleshooting incidents with tangible business impacts should be reviewed to prevent them from recurring. For example, a data breach resulting from a malicious attack would be an ideal candidate for a post-mortem analysis.