Post Mortem Review Process

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? • 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” Project post mortem is an opportunity to:

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?