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

Change and Release Questions

CHANGE:

ü Change requirement is identified

ü Change request is submitted

o   Identify the requirement to make a change to the project

o   Document the requirement by completing a CRF

o   Submit the CRF to the Change Manager for review.

o   Description

o   Reasons

o   Benefits

o   Costs

o   Impacts

o   Classification

ü Approvals

ü Change request is reviewed

o   Receiving all CRFs and logging them in the Change Register

o   Categorizing and prioritizing all CRF

o   Reviewing all CRFs to determine whether additional information is required

o   Determining whether or not a formal change Feasibility Study is required

o   Forwarding the CRF to the Change Approval Group for approval

o   Escalating all CRF issues and risks to the Change Approval Group

o   Reporting and communicating all decisions made by the Change Approval Group.

o   Reviewing all CRFs forwarded by the Change Manager

o   Considering all supporting documentation

o   Approving / rejecting each CRF based on its relevant merits

o   Resolving change conflict (where 2 or more changes overlap)

o   Identifying the implementation timetable (for approved changes).

o   Number of change options presented

o   Complexity of the change options requested

o   Scale of the change solutions proposed. ©

ü Was there a need for change feasibility study?

o   Undertaking research to determine the likely options for change, costs, benefits and impacts of the change

o   Documenting all findings within a Feasibility Study Report

o   Forwarding the Feasibility Study Report to the Change Manager for Change Approval Group submission.

o   Requirements

o   Options

o   Costs and benefits

o   Risks and issues

o   Impact

ü Recommendations and plan

ü Change documentation is submitted?

o   The original CRF

o   The approved Change Feasibility Study report

o   Any supporting documentation.

ü Change documentation is reviewed?

ü Change is approved?

o   Reject the change

o   Request more information related to the change

o   Approve the change as requested

o   Approve the change subject to specified conditions.

§  Risk to the project in implementing the change

§  Risk to the project in NOT implementing the change

§  Impact on the project in implementing the change (time, resources, finance, quality).

o   Change approval notification sent to client

RELEASE:

ü Change schedule is approved

ü Change is reviewed

ü Change is implemented:

·         Develop release strategy

·         Publish a build plan

·         Publish a testing plan

·         Publish deployment plan

·         Conduct release plan reviews

·         Receive, log, qualify, and assign all release requests.

·         Participate in release control gates (as needed)

·         Develop installation scripts

·         Develop configuration scripts

·         Develop roll back procedures

·         Develop release procedures

·         Develop test scripts

·         Develop test readiness review

·         Procure release components

o   Review releases and assign appropriate release testing tasks

o   Compile and Review the Testing Deliverables

o   Conduct testing as needed

o   Conduct supporting documentation review

o   Schedule release readiness reviews

·         Conduct release readiness reviews

·         Communicate release dispositions

·         Participate in CAB meeting

o   Conduct installation procedure tests

o   Conduct functional testing

o   Conduct performance testing

o   Conduct integration testing

o   Conduct user acceptance testing

o   Conduct operational readiness testing

o   Conduct back-out testing

o   Conduct supporting documentation review

o   Compile test results

o   Conduct release test review

·         Conduct post release testing

·         Deploy release

o   Identifying the date for implementation of the change

·         Communicate release status

·         Update Master Release Calendar & FSC

·         Request CI update

·         Participate in Post Implementation Review (PIR)

·         Establishes security permissions and access to managed environments

·         Report exceptions to the Release process

·         Ensures that all Customer, support staff and Service Desk staff are trained and provided with the appropriate documentation and information

·         Report KPIs

POST IMPLEMENTATION:

o   Review the success of the change implementation

o   Communicate the success of the change implementation

o   Close the change in the change log.