mec. musings

Keys To Successful Postmortems – Part II: Conducting the Meeting

Posted on April 13, 2011 Updated on September 3, 2014

In Part I, we talked about setting up the postmortem meeting.  The postmortem is part of a project or release close out and is also beneficial (and should be used) at the close of any security or production support incident, etc., as part of the RCA (root cause analysis).  Bottom line is that any time a project, incident or initiative is closed, there’s an opportunity to capture any lessons learned and leverage the knowledge going forward.

I’m a big fan of the ‘Plus/Delta’ framework for capturing postmortem findings. In this framework, a Plus is any practice, process or finding that worked well and should be kept or repeated in the future.  Conversely, a Delta is any practice, process gap or risk that resulted in a problem and should be changed or fixed.  Identify Pluses and Deltas for each phase of the SDLC/Project Life-cycle:

• Initiating
• Planning
• Executing
• Controlling
• Closing

You can use this framework to conduct the meeting, as well.  Keep it simple; for each phase, discuss and document all Pluses and Deltas.  For incident postmortems/RCAs, you can be flexible on the specific phases (as the SDLC or Project Life-cycle may not be appropriate).  For example, incident postmortems can make use the following phases:

• Identification
• Communication
• Short-Term Resolution (how was the problem fixed?)
• Long-Term Resolution (how do we make sure the problem doesn’t happen again?)
• Closure

The point is to go through the incident or project in a logical, chronological fashion, capturing Pluses and Deltas.

FACILITATION

Here are some guidelines to consider in facilitating the meeting:

• Who Should Facilitate the Meeting: The facilitator should NOT be a member of the project or incident team. The reason that the facilitator shouldn’t be someone involved in the project or incident is that you want THOSE resources to contribute content, while the facilitator is responsible for guiding the meeting, keeping it productive and acting as…..well….as the facilitator. It’s also best to have a neutral party facilitating the meeting in the case of a not-so-successful project or issue resolution.  This avoids anyone thinking that, for example, the developers got off easy because the facilitator was the lead developer on the project.  The facilitator should be someone familiar with the team who can keep the meeting controlled and productive. You can facilitate the meeting if necessary, but it’s always better if it’s someone at the same level as those on the postmortem team.
• Pre-Meeting by Functional Teams:  The postmortem team should not just “show up” for the meeting and figure it out as they go along.  Each functional team (e.g., the Development team, the QA team, the network team, etc.) should meet on their own beforehand to discuss their specific observations.  During this pre-meeting, each functional team should use the framework below to document their findings, then publish these findings to the rest of the postmortem team in advance of the meeting.  This will help stimulate thought and discussion, resulting in a more productive postmortem.  Strongly encourage all participants to review the combined findings beforehand.  The facilitator can also combine all the findings into a draft document and send it to participants in advance as well as using the document on the overhead to guide the meeting.
• Documenting: Use an overhead projector and a laptop to avoid any double-work in documenting the findings.  If that’s not an option, use a white board or easel and get everything written down and into the document as soon as the meeting is over (and throw all that paper away).  Only document findings that will result in an ‘Action Item’ or a very clear ‘Lesson Learned’.  For example, documenting that the QA team did “a really great job” feels great but it has no pragmatic benefit going forward.  The point is to create a deliverable that is useful beyond the project or incident.

GROUND RULES

Establish and communicate the ground rules in advance of the meeting and review them as the meeting begins.  Make sure you follow the same rules for each postmortem.  The facilitator MUST be very clear on the ground rules and tactfully enforce the rules while not quashing discussion (particularly with the ‘No Problem-Solving’ rule; that is the hardest to enforce, I guarantee!).  Here are some ground rules to consider:

• No Problem-Solving: The purpose of the postmortem is to capture Action Items and Lessons Learned and NOT to solve all the problems that came up during the project or incident.  Problem Solving sessions are Action Items and should be conducted outside of the postmortem and will include all stakeholders in resolving the particular issue or process gap.  While you will DEFINITELY have people in the meeting who’ll want to tear into a problem and start kicking around ideas, the facilitator has to stop this and instead, note an Action Item to set up a meeting to tear into the problem and NOT do it during the postmortem (if you ever want the meeting to end, anyway!).  Trust me – this is the one rule you’ll be enforcing right up to the end of the meeting, so be very tactful and positive about this – again, you do NOT want to quash discussion and have people shut down/not participate.
• Processes, Not People: When focusing on some of the Deltas, avoid focusing on the actions of specific people.  Focus on the process gap and not the person.  If someone’s actions caused a problem, this is evidence of a process gap that allowed something bad to happen.  If someone falls through a hole in the floor, firing the person who fell through the hole WILL get rid of the “faller” but the hole remains; fix the damn hole.  Besides, focusing on the people will lead to bad blood both during and after the meeting.  Don’t allow this to happen.
• No Distractions: This one is obvious.  The “no sidebars” rule is important and, to my mind, goes without saying.  I also recommend a ‘no Blackberries/iPhones’ rule.  With the sole exception of someone who has a specific reason, production support issue, etc., that necessitates that they keep their phone near them during the meeting, instead set up a “coral” (i.e., a shoe box or something) to house everyone’s phones and allow a break every 45 minutes / 1 hour for people to retrieve and check their phones.  This keeps the meeting focused and is respectful of other people and their time.
• Action Items: Action Items have ONE owner, who is accountable for ensuring the action is completed.  It’s true that Action Items usually have many stakeholders/participants, but only ONE person accountable for delivering – period.  Also, ‘TBD’ is NOT a due date.  Due dates have specific dates, months and years.  You can always change a due date but do NOT let anyone walk out of the meeting with an Action Items assigned to more than one person and with no firm due date.
• Follow the Framework: Make sure you follow the framework in order to maintain focus.  For example, for a project you’ll start with the ‘Intiating’ Phase and discuss what went well and should be repeated/kept (Plus) and what went badly and needs to be fixed/changed (Delta).  The idea is to keep the framework simple and clean and focus on identifying the action items and lessons learned.

Basically, your facilitator ensures that the brainpower in the room produces a solid list of Action Items and Lessons Learned and makes excellent use of everyone’s time.  The facilitator should ask for anonymous feedback after the close of the meeting – what could have been done better/different?  Another good opportunity to capture some learnings.  Also, allowing others to facilitate and avoiding the task yourself is a good way to build leadership skills in your team.  If your team is new to this process, you facilitating the first few sessions to establish precedence is worth considering.

In Part III, we’ll discuss the postmortem deliverable and I’ll include a sample.

© 2011, Mark E. Calabrese