1. Post Mortem Review Process
Send in the clowns

2. Jesse Chunn President of Standard I-O 11 years as a programmer
Primary project lead on hundreds of projects
Experience with both successful and unsuccessful projects

3. What is the “Post Mortem Review” Process?
Project post mortem is an opportunity to:
Review performance
Expose bad practices
Discover best practices
Understand the difference between compromises and mistakes
Understand the difference between innovation and showmanship
Operate as a “Learning Organization”

4. Why Do They Call It That? Post mortem suggests the project is “Dead”
Has negative connotations
Should be called “Post Project Review” or something like that…

5. Anatomy of a Successful Post Mortem Review
Part of original project schedule
Dialog vs. Discussion
Constructive vs. Destructive Criticism
Open sharing of Lessons Learned
Provide for application of knowledge to future projects
Record of “session”

6. The difference between “Discussion” and “Dialog”
Discussion implies debate
He said: “You should have done it this way…”
She said: “I did it like that because…”
Dialog implies insightful consideration
He said: “What if you had done it this way…”
She said: “That could have worked if…”
Dialog promotes open and honest communication without the fear of reprisal or the concern of accepting blame or admitting mistakes

7. The difference between “Discussion” and “Dialog” (cont.)
In a discussion, we assume someone is responsible for everything, good or bad.
In a dialog, we assume everyone did the best job they could, given what they knew at the time.
A positive result will come not from judgment, but from learning and growing from our collective experience.

8. Goals of Post Mortem Review
Personal growth
Organizational growth
Team building
Knowledge sharing
Documented results
Enhance “Big Picture” view of future projects
Shared vision

9. Personal Growth The Post Mortem Review is ALL about personal growth
Without personal growth as a key consideration, organizational growth is impossible
Organizational growth IS the personal growth of a large number of long term contributors

10. What Are NOT the goals of Post Mortem Review?
Finger pointing / blame placement
Checking “PMR” off of the schedule
Comparison against previous PMR’s
Software development training
Celebration
Recognition

11. Who Should Attend the PMR?
ALL Contributors
Yes, that includes testing staff
Yes, that includes documentation staff
MAY include client reps, depending on involvement and other factors
No, that does not include anyone that was not involved, like the boss* (especially the boss?)
* Unless the boss was involved in the project, of course

12. How to Conduct a Post Mortem Review
Project Overview (carefully…)
Acknowledge mid-term changes, if any (ha ha)
Compare expected results to actual results
Identify new discoveries / mistakes
Identify adherence, non-adherence to “Best Practices”, and why or why not
Dialog
Document

13. Document, Document, Document
What went wrong
What went right
What is known
What is unknown
What should be tried or experimented with
What should be adopted as “Best Practice”
What should be avoided as “Worst Practice”

14. What Should Be Covered?
Project priorities (in the beginning and in the end)
Initial expectations
Results (how did things turn out)
Excluded requirements (why?)
Lessons learned (ongoing list from all projects)
Success or failure of risk management
PERSONAL goals for improvement
Organizational goals for improvement (?)

15. What Should You Be Focused On During the PMR Process?
At all times, all participants must be consciously aware of the purpose of the Post Mortem Process:
To become a more effective individual as part of a larger team, to become a more effective team as part of a larger organization, and to become a more effective organization as part of a larger universe

16. Questions?