Post Mortem Ananlysis (PMA)

I wanted to do a Post Mortem of a recently concluded project - a Fraud Detection Rule Engine on Naukri India. It was the most screwed piece of project management ever. But I did know how a professional Post Mortem Analysis (PMA) should be carried out. It could cause more harm than good. While researching on the net, i came across a line regarding PMA - "Do It Right Or Don't Do It At All".

Well, this prompted me to put together a document. Most of this doc are not my own words but a collation of points from various sources so as to make it relevant to our industry. Check it out:

Conducting Post Mortem Analysis of a Project (PMA)
(also referred to as Post Implementation Review)

Overview

The current paper on Post Mortem Analysis (PMA) of a Project covers the following:

1. Why Post Mortem is essential?
2. When should a Post Mortem be done?
3. How to ensure Post Mortem as a process?
4. How to conduct a Post Mortem?
5. What to extract from a Post Mortem exercise?


Why Post Mortem is essential?

All of us are very hard pressed for time. One project gets over and the next one is in pipeline. And days are planned accordingly so any effort in a Post Mortem exercise for a project that has already gone live seems such a waste of time!

“Its going to affect my pipeline.”

“There are too many meetings happening for the projects in hand. I can’t squeeze in meetings for a project thats already live and kicking fine!”

“Look ahead, no point digging out graves!”

However, the difference between an organization with a culture of postmortems and one without can be dramatic. Because of the good effects of postmortems, companies that lack the discipline to perform postmortems tend to be at a rather chaotic level of development.

Companies that do not conduct some form of postmortem are doomed to repeat the same mistakes. This statement holds true for individuals and teams.

It's important for Product Managers and team members to take stock at the end of a project and develop a list of lessons learned so that they don't repeat their mistakes in the next project.

When should a Post Mortem be done?

The best time to conduct a postmortem is about two weeks after a product is released. This allows you to regain your objectivity without forgetting the details. Your memories will still be fresh, and you'll have a good perspective to see the project as a whole rather than focusing too strongly on the most recent work.
However, this timeline can vary but the basic idea is that it should not be too close to the release nor too far away from it. Ideally, anything from one week to a maximum three weeks.

Launch the product, have the celebration, and then roll right into the postmortem, within one to three weeks rather than waiting for a convenient break in the action (which never comes, anyhow).


How to ensure Post Mortem as a process?

Effective use of postmortems can only happen when all stakeholders understand the benefits and management is supportive of this exercise.

In essence, an atmosphere needs to be built that promotes post mortems and all team members embrace it for betterment.

Plan for Postmortems - Your project plan should explicitly set aside time and space for the postmortem. To get the most value out of this activity, you need to take it seriously; people need to have time to think without being thrown immediately into the next project. The postmortem should be a scheduled activity, with time for a meeting of the team to discuss the lessons learned and time for someone (or some group) to write the postmortem report. People need to distance from the day-to-day workspace and see more clearly what they spend their regular workday doing.


How to conduct a Post Mortem (project post mortem, i.e.)?
Follow a two step process for conducting these reviews:

1. First, prepare and circulate a whole bunch of specific questions about the project and give team members time to think about them and prepare their responses individually.

Important: Involve all contributors.

2. Next, hold a meeting and discuss the team's responses to the questions. The result of this discussion is often a list of "Lessons Learned."

The benefit of the first step is that it allows the quieter, more analytical people to develop their responses to the questions without being interrupted by the more outgoing, vocal types who might otherwise dominate in the face-to-face meeting. Also, it allows everyone the time to create more thoughtful responses.
So what would be on the list of questions?

General Questions
1. Are you proud of our finished deliverables (project work products)? If yes, what's so good about them? If no, what's wrong with them?

2. What was the single most frustrating part of our project?

3. How would you do things differently next time to avoid this frustration?

4. What was the most gratifying or professionally satisfying part of the project?

5. Which of our methods or processes worked particularly well?

6. Which of our methods or processes were difficult or frustrating to use?

7. If you could wave a magic wand and change anything about the project, what would you change?

8. Did our stakeholders, senior managers, customers, and sponsor(s) participate effectively? If not, how could we improve their participation?


SPECIFIC QUESTIONS

Documentation Phase

1. Did our analysis identify all the project deliverables that we eventually had to build? If not, what did we miss and how can we be sure our future analyses don't miss such items?

2. Did our analysis identify unnecessary deliverables? If so, how can we be sure our future analyses don't make this mistake?

3. Did those who reviewed the SRS, provide timely and meaningful input? If not, how could we have improved their involvement and the quality of their contributions?

4. Did we have the right people assigned to all project roles? (Consider subject matter expertise, technical contributions, management, review and approval, and other key roles) If no, how can we make sure that we get the right people next time?

5. List team members or stakeholders who were missing from the kickoff meeting or who were not involved early enough in our project. How can we avoid these oversights in the future?


Development Phase

1. How accurate were our original estimates? What did we over or under estimate?

2. How could we have improved our estimate so that it was more accurate?

3. Were all team/stakeholder roles and responsibilities clearly delineated and communicated? If not, how could we have improved these?

4. Were the deliverables specifications, milestones, and specific schedule elements/dates clearly communicated? If not, how could we improve this?

5. Did the test facilities, equipment, materials, and support people help to make the test an accurate representation of how the deliverables will be used in the "real world?" If not, how could we have improved on these items?


What to extract from a Post Mortem exercise?

Here are a few suggestions to make PMA exercise fruitful:

1. Discuss what went wrong.

2. Discuss what went right

3. Document the postmortem in writing. A series of postmortems can ultimately evolve into a valuable record of your hard-earned wisdom.

4. Assess mid-project changes. What unanticipated changes occurred throughout the project? How did you respond to them? Did you incorporate some great mid-project additions, or was excessive feature creep a problem?

5. Draw meaningful conclusions. What conclusions can you draw from your project history that will help you improve in the future? What should you start doing, keep doing, or stop doing? Describe new practices you should try for your next project. This is perhaps the most important part of the postmortem, so be prepared to spend more time here than in any other section.

6. Take action. It would be a great waste of time to create a beautiful project postmortem, archive it, and forget about it. The final step is to develop an action plan that can be applied to your next project. Review your project history, reflect on the lessons you've learned, and specify new guidelines to follow in the future. I recommend creating a checklist for your next project. If you already have a checklist, then update it with new refinements.