Post Mortem Review Process Send in the clowns

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

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”

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…

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”

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

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.

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

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

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

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

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

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”

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 (?)

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

Questions?