Postmortem Meetings: Guidelines (Part 1)

Postmortem is touchy issue, but if handled well, it is an enriching process as you can discuss and document all the personal and professional growth you have experienced during the project. You can have a postmortem meeting that improves how you and your team manage projects, or you can have a meeting that demotivates and demoralizes you. The result depends entirely on the spirit with which you take it.

Take it in the right spirits, and you emerge out as a better and seasoned writer. This will help your from repeating the mistakes that can be avoided. This section describes what to do during the postmortem meeting so that it will help you to get the most out of this process. It also describes the guidelines for conducting productive meetings.

1. Don’t Delay the Meeting

The best time to conduct a postmortem is about a week or two after a product is released. This allows you to regain your thoughts good, bad, and ugly about the project without forgetting the details. It gives you enough time to think back and collect your thoughts.

The right time to have such a meeting is when the successes, problems, and mistakes are still fresh in mind. It is the ideal time to discuss what went right and what went wrong. You will be able to see the project as a whole, rather than focusing on the most recent activities of the project (which is fresh in mind).

2. Involve All Contributors

Involve all the contributers of the project in this meeting.

  • Collective meeting: This should involve all the contributers from the various teams (development, testing, documentation, and support engineers, etc.). This could be a generic meeting where you discuss the entire process of the SDLC and the DDL.
  • Team meeting: You also have to arrange a separate project review meeting with everybody in the documentation team who were involved in the project (writers, editor, team/project leader, and documentation manager) to reflect on the project experience.
  • This will give you an opportunity to discuss the documentation specific problems, issues, process, and suggestions for changes.

In either case, note down all the problematic areas and solicit ideas for improving or changing them in the future projects.

4. Use Review Forms

Most of the organizations use a project review questionnaire, which includes a 1-10 rating system to quantify subjective feedback. It contains questions for specific areas that might need improvement and use a comments section for open-ended feedback. A series of postmortem can ultimately evolve into a valuable project review form and use it to record your hard-earned wisdom. Later, a consolidated report should be put up for every one to see, read, and use.

5. Have a Clear Agenda

A planned meeting will help in including all the areas of concerns you may want to discuss and you can get the most out of the postmortem meeting. Certain factors you can focus on while creating an agenda are:

      • Project planning.
      • The processes followed by the different teams.
      • Communication between the team members and between different teams.
      • Clarity of roles within and outside the team.

Project Planning and Process

Look at the success or failure of the project plan, identi ed risks, and the schedules.

  • Were you able to accurately estimate the time required for tasks?
  • Did you coordinate the activities and tasks well?
  • Did you follow the sequence of the tasks effectively?
  • Did you come to a clear consensus as to which tasks had the highest priority?
  • What is the main reason for not meeting the deadline?
  • Were the risk factors taken into consideration during the planning phase? 


 Examine how well the project members communicated with each other.

  • Were the goals for the project clear to all the teams?
  • Were team members accessible to each other to help answer questions?
  • Did the team come to consensus about the decisions impacting the document?
  • Did the group respect the expertise of the team members and use them productively without disturbing them?
  • Did any team members have to wait for another team member to complete a task?
  • Were there any issues in communicating with colleagues outside the product team?
  • Were you kept in the loop regarding the changes to the product?
  • Was the communication regarding schedules clear?

 Clarity of Roles

 Explore how well roles were defined within the team and outside the team as well.

  •  Were roles within the team clear?
  • Was it clear who had decision-making power at every stage of the project?
  • Were the roles of the other team members known to you?
  • Were the priorities set for the project clear to you?
  • Did the members perform the functions necessary for the success of the project?

5. Don’t Look For Scapegoats

As a rule conduct positive and constructive meetings; do not look out for scapegoats.Postmortem meetings must be honest and should have an open communication. If you have any issues, raise them during the meeting rather than crib about it later. If a project has been diffcult or unsuccessful, expect some emotional venting. However, channelizing that in a constructive direction will benefit you and the team.

But, managers will have to confront non-performers. They will have to discuss it with the specific team member on a one-to-one basis regarding what went wrong and why, and areas for improvement.

6. Discuss What You Wanted to Achieve

Come prepared with your notes and observations for the meeting. Begin the review meetings by refreshing everyone on what you all initially thought the project to be and how you thought things would turn out. It would be helpful to include a brief overview of the project an estimated budget, resources, tools, project schedules (start and finish dates), milestones, and effort estimates.

Then, compare that information with what actually happened with the project. For example, you can compare the time frame and resources allotted to the project in the beginning (assuming ideal conditions) and the time and resources it actually took to complete the project.

7. Review Performance of Team Members

The postmortem meetings (when restricted to specific teams) can also act as performance reviews, because it happens right after the project. This will help you:

  • Focus on the skills that have to be improved or developed.
  • Focus on improving project strategies.
  • Understand the concept of self-review accurately.
  • Assess and improve performances.
  • Make changes to the way you do certain things to make the work process more effective.

The review should be done on a personal basis, where in managers can confront the writers who were at fault and tell them where they were wrong and why. Writers have to look at this as a learning process and learn to take such feedback gracefully.

8. What Went Wrong?

Focus on things that turned out worse than expected, especially the unexpected problems that crept in and took a wild turn. Also focus on problematic areas which you could control. Compile a list of the shortcomings and what went wrong with the project:

  • Were the problems anticipated?
  • Could you have avoided the problem?
  • What were the problems and diffculties that you encountered?
  • How well did you adhere to processes?
  • How accurate were your original estimates?
  • Did you deviate from the original estimates of the plan? If yes, why?
  • Where there any drastic changes in the plan?
  • What kinds of mistakes did you make?
  • What problems were unexpected, but solvable?
  • What issues were unexpected and extremely problematic?
  • Did the assumptions prove incorrect? Which ones did and which ones did not?
  • Were any targets missed?

Identify each and every problem, however small, insigni cant, and irrelevant it might seem to be. Try to nd answers for the the questions that arise with these questions which? why?, how? The answers will eventually help you improve.

9. Identify the Reasons

After identifying the problems, try to identify the reasons for those problem and for the change in the original plans, schedules, or processes. Is it because:

  • The plan was not accurate? or
  • The code changed very often? or
  • You did not receive information on time? or
  • The change in the development schedule? or
  • You were unaware of the last minute changes.

10.  Review the Risk Plans

Analyze the problems and issues faced during the project. More importantly, analyze and discuss the approach taken to come out of it:

  • Did you take risks or did you play it safe?
  • Did you encounter any problems or unpredicted risks?
  • Did you resolve them?
  • If yes, how did you do that?
  • If you did not, why did you not resolve them?

Pay particular attention to how you would change your approach for the next project. The approach should be what should I do in such a situation? Try to make a list of all the aspects that you should avoid that would create problems or hinder the flow of work. Also make a list of possible solutions to the anticipated problems.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: