mec. musings

Keys To Successful Postmortems – Part III: Deliverables

Posted on May 4, 2011 Updated on September 3, 2014

In Part I, we talked about setting up the postmortem meeting and in Part II, we discussed conducting the postmortem meeting itself.  In Part III, we’ll focus on creating a deliverable that can be used to exploit both short-term and long-term opportunities through Action Items and Lessons Learned, respectively.  Consider the following in completing your deliverable:

• Respect The Framework: The framework focuses on Pluses or Deltas in each phase of the project or incident.  Therefore, only capture those practices that were successful and should be kept (Plus) or that were unsuccessful and should either be changed or discarded (Delta), by phase.
• Action Items or Lessons Learned: Every Plus or Delta captured in the postmortem must result in either an Action Item or a Lesson Learned.  Action Items are specific actions that should be taken in the short-term and are assigned ONE owner and a due DATE.  Lessons Learned are easy-to-understand guidelines or principles that are understandable on their own and do not require extensive knowledge of the project or incident in order to make sense.  More on Action Items and Lessons Learned can be found below.
• Simplicity: Use a simple template and keep the contents pragmatic (I’ve attached a sample template, below).  Some additional content, such as names/roles of participants, overview of the project or incident, etc., can be beneficial but the primary contents are Pluses and Deltas by phase and resulting Action Items and Lessons Learned.  KEEP IT SIMPLE, creating a deliverable that is READABLE and USEFUL.

If you plan to submit your postmortem document to your business partners as part of project or incident closure, you may wish to include additional content.  That said, strive to keep the content simple, direct and to the point unless circumstances DEFINITELY require otherwise.

ACTION ITEMS: Action Items can include, but are not necessarily limited to, any of the following:

• Meetings or Discussions: Meetings to discuss a process change or process development, a potential risk mitigation strategy, etc.  In other words, setting up a meeting that might have otherwise have resulted in a problem-solving or sidebar discussion during the postmortem.  Do NOT conduct such discussions in the postmortem; conduct them on their own, with the appropriate stakeholders in attendance, and call out an Action Item to make the meeting happen.
• Specific Actions: For example, any code changes, configuration changes, etc.  Any specific actions required in the short-term to address any issues that were raised during the postmortem or immediately after project go-live or incident closure.

Action Items have ONE owner, who is accountable for completion.  Even if multiple resources will be involved in completing the work, there is only ONE person accountable for ensuring the item is completed and closed by the due date.

Action Items have a Due DATE.  The postmortem facilitator should have the Action Item owner set the due date, but if the owner hedges, suggest a due date to them and NAIL THEM DOWN.  The due date can always change, but get a commitment during the postmortem and DOCUMENT IT.

LESSONS LEARNED:  Lessons Learned should be archived in a single Lessons Learned Master Document (e.g., a simple MS Word document with bullet points).  You can categorize Lessons Learned by phase, etc., but be careful; the more you play with the list, the more likely you’ll end up making a task out of maintaining the list.  Better to maintain a simple list that can be printed out and reviewed at the start of every project as a reminder of what was learned in past projects and what should be considered in the current project.

Each Lesson Learned should be stated very clearly and concisely and should be understandable ON ITS OWN and on a FIRST READ.  Lessons Learned should NOT require detailed knowledge of the project in order to gain context and understanding.  Therefore, it’s important to edit each Lesson Learned to make sure they are well written.  Have someone who is NOT familiar with the project or incident review the final Lessons Learned for readability before they’re added to the overall Lessons Learned Master Document.

Review the Lessons Learned Master Document after each project or incident to ensure there are no duplicates and also to ensure that, as noted above, each lesson is clear and understandable.  Production support/service restoration issues will now allow the luxury of a review of the Master Document at issue identification, so support teams may wish to review the Document on a regular basis as a risk mitigation strategy.

The template below is a baseline document to be stolen/edited it as you see fit.  As always, I welcome any comments, questions or thoughts and can be contacted at mark.e.calabrese@gmail.com.  Good luck!

Plus Delta Postmortem Template

© 2011, Mark E. Calabrese