Post Mortem Report Template

Owners and List of Contacts

Name	Email	Phone	Role

Revision History

Date	Reason for change(s)	Author(s)

1.       Introduction

The goal and purpose of a post-mortem is to draw meaningful conclusions to help us learn from our past successes and failures by describing in detail the specific activities that were most effective and those that need adjustments prior to the next test project. 

1.1    Background

1.1.1           Brief description and overview:

1.1.2           Overall approach taken to complete project:

1.1.3          The deliverables:

Planning

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

Resources

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

Project Management/Scheduling

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

Development/Design/Specifications

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

Testing

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

Communication

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

Team/Organization

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

Product

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

Management (Group and Program Managers)

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

Tools and Practices

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

General

What Went Well?

What Did We Struggle With?

What Should We Do Differently?

1.1.4          Anything that was special about the project:

1.1.5          Where was the most effort spent?

1.1.6          Lessons learned - things the team would/wouldn’t do again and why?

1.1.7          Where could major improvements be made to the process that was adopted?

1.1.8          Team interactions - the positives and the negatives:

1.1.9          Interactions with the customers - any difficulties?

1.1.10       In what way was the project a success/failure?

1.1.11           Was the original Root Cause Resolved?

1.1.12           Project(s) Identified but not implemented?

1.1.13       Actions Required?

1.1.14       Process Improvements Required?

2.     Meaningful Conclusions:

 

3.     Action Items:

Note: The action items themselves must be concrete and objective, that is: dates must be assigned, assignees identified, and a form of “measurement” determined so as to assess the performance towards the action item’s end objective.

Who	What	Start Date	End Date	KPI