4 questions to ask for an effective technical postmortem

A technical postmortem is a retrospective of a failure. It’s a preventative step that can help you quickly identify and address issues with your assets, systems, or other technology platforms so they don’t happen again. They are commonly used in maintenance but also have applications in software development and design as well.

What is a technical postmortem?

A technical postmortem is a retrospective analysis of events that resulted in a technical failure.

The purpose of a technical postmortem is to:

• Find out what went wrong and why
• Identify trouble areas
• Determine what can be done to prevent future failures
• Create best practices for your business
• Inform process improvements, mitigate future risks, and promote iterative best practices

4 questions to ask during a technical postmortem

This postmortem outline is not meant to be comprehensive but to serve as a starting point for your technical postmortem. These questions generate discussion about what went well, what the team struggled with during the failure, and what the team would do differently moving forward.

Here’s what you and your team should be asking during a technical postmortem:

1. What happened?

You can’t analyze what you don’t understand, so establishing a clear understanding of what went wrong is crucial.

Get to the bottom of failure with this free root cause analysis template

Check it out

2. Why did it happen?

Identify the major events that led to the failure and try isolating the root causes for the failure. Determine if the events are the underlying causes of the failure, or if they initiate a process that leads to the technical failure. Some underlying causes can include defects in design, process, or poor maintenance practices.

Look strictly at the technical causes of the failure and examine the underlying management and team environment. Sometimes team members ignore warning signs of impending failure due to the organizational culture, time crunches, and budget pressure.

3. How did we respond and recover?

How your team responds to failure can determine how quickly you identify the root cause and fix it. A major technical failure can have a direct impact on shareholder value, revenues, market share, and brand equity, so a quick recovery is paramount.

A useful technical postmortem requires a reasonable level of honesty, insight, and cooperation from the organization. The outcome of the postmortem should be to recognize what worked and fix the processes that didn’t. Remember, the idea is to learn from your successes and failures, not just to document them.

4. How can we prevent similar unexpected issues from occurring again?

Unexpected technical issues do arise in mission-critical or complex hardware systems. However, the key to prevention is technical planning to prevent problems from affecting the entire system. Each of the failures uncovered in step two represents a risk going forward, so schedule regular inspections or system checks in your maintenance management software.

When a risk is detected, certain actions should be triggered immediately to prevent similar failures. Planning must also consider the business process and management responses the team initiates when a failure occurs. A complete postmortem addresses both technical and management issues.

Don’t turn your postmortem into a blame game. Instead, management has to develop a reputation for listening openly to input and not punishing people for being honest. A well-run postmortem can help a maintenance team create a culture of continuous improvement.

Create fool-proof failure codes with this FMEA template

Check it out

The benefits of conducting a technical postmortem

As we can see from our example, a technical postmortem has a series of positive benefits including a detailed analysis of why an asset failed. It can help you avoid future problems by identifying issues that are present before any kind of launch.

A technical postmortem can also benefit you by:

• Identifying potential problems with an asset
• Improving the way your team approaches new projects
• Learning from mistakes so they don’t happen again
• Gaining insights into how other teams have handled similar situations

Some next steps after your technical postmortem is completed

After a technical postmortem is conducted and the project is concluded there is a postmortem meeting. This meeting is intended to understand the project from start to finish and determine what can be optimized and improved for the next postmortem. Generally, the project manager and team attend these meetings, but it’s open for anyone part of the project to join.

Tips and tricks to keep in mind during and after your technical postmortem

• A postmortem can help you become more effective by learning from mistakes and focusing on what worked best, but it’s up to you to structure the meeting to get the most out of it. A way to structure your meeting is by setting a clear agenda, beginning with a recap of the project objectives, reviewing the results and whether or not the project met the set objectives, and lastly, analyzing the successes and failures and why they occurred.
• You can ensure that your technical postmortem is successful by carefully preparing in advance, analyzing the failure systematically, producing actionable findings, and actively sharing the results.
• Don’t let the momentum fade with your team. Schedule the postmortem right after the end of the project. A technical postmortem should occur within one to two weeks of the technical failure.
• Make sure to store your postmortems in the asset record in a CMMS so they can be easily found in the future to prevent similar failures going forward.

A technical postmortem is an important tool for maintaining and improving your systems

A technical postmortem is a tool that allows you to learn from mistakes, identify the root cause of a problem, and improve your systems. It may sound like an abstract concept, but it’s actually quite simple: you document what went wrong and use that information to prevent the same issue from happening again.