Unit 16: Post Implementation Review

1
Unit 16 Post Implementation Review

• CSEM04 Risk and Opportunities of Systems Change
  in Organisations
• Dr Lynne Humphries
• Prof. Helen M Edwards

2
Overview

• What is a post mortem review (and when to conduct
  it?
• Full Post Mortem Reviews
• Plan a Project Review
• Gather Project Data
• Hold a Project History Day
• Analysis the findings
• Synthesise Lessons Learned
• Create of a Plan For Change
• Close the Loop

3
Overview (cont.)

• An Example of a Lightweight Post Mortem Review
• One Meeting Version
• Prerequisites
• People/Roles
• Processes
• Brainstorming
• Structuring
• Analysis
• Reporting

4
A post-mortem review

• Review of a project
• By the project stakeholders
• After it has gone live.
• To build up understanding of the issues in that
  project.
• To take lessons learned
• To improve prospects of future projects being
  conducted successfully.

Diagram from www.epmbook.com/
5
Post-Implementation Review
Diagram from www.epmbook.com/

• Review of a project
• By the project stakeholders
• After it has gone live.
• To build up understanding of the issues in that
  project.
• To take lessons learned
• To improve prospects of future projects being
  conducted successfully.

6
Full Post Mortem Reviews

• Based on
• De Marco and Colliers Guidelines
• www.projectreview.net

7
Main Stages
8
Plan a Project Review

• Project reviews are expensive in terms of
  investment of time.
• So there has to be a justification for conducting
  them.
• and a plan for what theyll achieve
• (cost benefit analysis)
• After the end of a project most team members are
  working on the next project (not necessarily
  together)
• It takes a energy and commitment to successfully
  review a project
• To ensure an effective Project Review, teams must
  select the appropriate activities that suit that
  project and their needs.

9
Gather Project Data

• Each participant has a view on what happened
  during the project and why.
• One goal of the Project Review is to help create
  a common view of reality.
• use objective and subjective data to evaluate
  perspectives.
• The data used should be specific to the project
  and should reveal underlying issues in your
  development process
• Look for information that will reveal where the
  problems lay.
• if the project suffered from scarce resources
  consider the resources on the project (planned
  and actual) by month.
• Problems with feature creep? Check and list of
  each time the features were revisited and list
  the changes made.

10
Hold a Project History Day

• (Aka 'Project Review', or Postmortem)
• A meeting where all of the information you have
  gathered is presented for review and evaluation.
• The Project Review team and other key
  participants review the events that occurred
  during the project along with the rich set of
  collected project data.
• Problem solving methods are used to discover key
  insights into the project dynamics and driving
  forces behind the project.
• The Project History Day is the most complex and
  critical part of the project review process. It
  also is the most valuable in that the output is
  prioritized and actionable.

11
Analysis the findings

• At the project history day participants review
  all of the information that has been collected.
• They identify problems that the team experienced
  during the project
• Then dig deeper so they can understand what
  caused them.
• Often use fish bone diagrams.
• Identify a problem
• Ask why?
• Ask why?

12
Synthesise Lessons Learned

• This step is the most time consuming and most
  valuable activity in the process.
• This is where insight and imagination lead to
• a common view of the problems experienced
• and the solutions needed to fix them.
• (creative thinking techniques come to the fore
  here)

13
Create of a Plan For Change

• Take your lessons learned foreward
• Be pro-active
• assign improvement activities to individuals or
  groups
• check early in the next project(s) to see that
  changes are being
• implemented and
• tracked for impact
• Ask what can be done to improve the way the next
  project is run?

14
Close the Loop

• Collect and study information gleaned from
  Project Reviews from multiple projects.
• Begin to evaluate problems and successes
• across projects and
• between different teams.
• Introduce systemic changes throughout the
  organisation.
• Begin by
• documenting findings and
• communicating them to the team and management.

15
An Example of a Lightweight Post Mortem Review

• Based on
• A practical guide to
• Lightweight Post Mortem Reviews
• Torgeir Dingsøyr, Tor Stålhane and Nils Brede Moe
• Department of Computer and Information Science
• Norwegian University of Science and Technology

16
One Meeting Version

• Aim to capture experience from a finished
  project,
• with 3 to 10 project participants in one meeting.
  
• suitable when a project has been finished, or has
  completed a phase,
• To give new views on known issues,
• To elicit issues that people usually do not think
  of themselves,
• An efficient way of documenting experience.

17
Prerequisites

• As many as possible of the project participants
  for up to five hours,
• and
• two people to facilitate using around eight hours
  each for preparation and
• Materials
• Post-it notes
• Pencils with thick ink
• A meeting room with a blackboard or whiteboard
• Sound recording equipment (optional)

18
People/Roles

• Moderator will announce a Post Mortem Meeting,
  and moderate discussions.
• Secretary will document the results of the
  meeting.
• If possible, the secretary can use recording
  equipment, and later transcribe important parts
  of the meeting.
• Project participants will contribute with their
  experience to get it documented.
• Usually the process manager and secretary rotate
  between each part given below

19
Processes

• Brainstorming
• Structuring
• Analysis
• Reporting

20
Brainstorming

• Acquire important aspects from the completed
  project
• Each participant has four Post-it notes
• writes one topic on each
• Each of the participants sticks up one of their
  Post-it notes, and explains why this issue was
  important in the project.
• Then the next participant presents an issue and
  so on...

21
Structuring

• After the brainstorm session, structure the
  result by placing Post-it notes with similar or
  related topics close to each other, and give each
  group a name that describe the content.
• Give priorities to each topic, so that the most
  important are analysed.

22
Analysis

• Find causes for the most important issues,
• use fish bone or Ishikawa diagrams
• start by drawing an arrow on the whiteboard with
  one issue.
• indicate with other arrows what the causes for
  this issue was
• (possible also with subcauses).

23
Reporting

• Document the result, using report structure-
• Abstract
• Introduction to the project and the method
  applied in the lightweight Post Mortem Review.
• The main problems in the project, with
  explanations from the Post-it note presentations,
  and fish bone diagrams showing causes.
• The main successes in the project, presented in
  the same way as the problems.
• Appendixes All information from the Post-it
  notes, and transcription of the presentations of
  the issues on the notes (if using sound recording
  equipment).