Postmortem Meeting: Guidelines (Part II)

11. Did You Manage the Change

Documentation by default is prone to changes. Here, we discuss the unexpected changes:

  • Did unanticipated changes occur in the project?
  • Did you encounter any problem that you had not forseen or taken into account?
  • How did you respond to such problems?
  • Did you have a risk management system in place?
  • Did you have an alternative method to do certain tasks?
  • Did the documentation su er from excessive change of features of the product?

12. What Went Right?

Having dealt with the wrongs, problems, and errors, it is time to deal with the rights.

  • What went right with your project?
  • What are the areas that went on as you had planned and/or anticipated?
  • Where did you beat your estimates?
  • Did the document turn out well despite all the problems that you encountered?
  • Problems for which you had alternative approaches or appropriate solutions.

13. Focus on the Facts

The meeting should not discuss personality or mistake made by any particular participant. It should address the outcome of the project, suggestion for changes to the processes, and alternative methods to perform certain activities. People often react to situations in di erent ways. Different interpretations may cause hard feelings and bruised ego. Hence focus on project related facts and don’t blame individuals.

Wrong: This mistake happened because Ram did not perform the XYZ task.

Better: We would not have made this mistake it we performed the XYZ task.

Note here that the blame on we, not Ram. However at a later stage, the documentation manager or the team leader should talk to Ram regarding this problem in a personal meeting.

14. Create a Report

For maximum benefits, compile the lessons learned from your meeting and create a postmortem report. The report can include the following information:

  • The project information (overview of the project, estimated resources, tools, project schedules, milestones, effort estimates, etc.).
  • Differences in the initial plan and the final plan.
  • What went wrong and how it could have been avoided.
  • Anything that went wrong, but was corrected and taken care of on time.
  • Recommendations for implementing the lessons learned.
  • Any change in the existing process that will be helpful.
  • Alternative approaches of doing certain tasks.

15. List the Lessons Learned

After analyzing the projects, make a list of lessons you learned form the project. For this ask a few questions:

  • What did you learn from those mistakes?
  • Did you nd alternative methods to perform these tasks?
  • Did you find solutions to the problem you had?
  • Where can you apply these solutions and alternate approaches to future projects?
  • Is there any specific factor that you have to change in the process to make the project work better?

The answers to these questions will be the lessons you have learned while working on the entire documentation process.

16. Don’t Ask Demoralizing Questions

The success of a postmortem depends on the manner it is handled. Asking for information in the appropriate way minimizes the risk of blaming or demoralizing the team members. So, frame the questions appropriately.

Wrong: Rita, how did this happen?

Better: How did this happen? How can we avoid such a mistake?

In this manner the managers can give the the writer who made the mistake an opportunity to speak up, share the problems and issues faced, and explain the situation in which it happened. It is a healthy process if the writers are able to self identify the mistakes and own up rather than others pointing ngers at them.

17. Rephrase the Answers Accordingly

When participants in the meeting describe the facts related to problems, those answerscould blame other team members. These answers can be rephrased to communicate the same thing in a better manner.

Wrong: You said you were too busy with your project and could not concentrate on the edits.

Better: We must make the editing a formalized process. It might reduce the possibilities of errors!

This response suggests a solution to the actual problem, without targeting at a particular person. It also informs the writer in a very mild way to take peer-edits seriously. If need be, the manager or the project manager can have a formal talk with the concerned writer on a one-to-one basis.

18. Don’t Take Comments Personally

There can be two outcomes (good or bad) of any project you handle. Similarly, there are two ways you can react at the postmortem meeting. Whatever happens, do not let it a affect you deeply. If any of the team members takes any comment personally, discontinue the meeting until they can handle it in a positive manner.

  • If things go well, you should feel pleased that you have done a good job, but let your feet be firm on the ground. Try to do better the next time.Remember, you had the support of the team members who helped you do your work in a better way by giving you the right advice, by helping you with tools, by informally editing your work, by helping you to clear some issues, and by sharing your workload.
  • If things don’t go well, take it to heart just enough to make you a stronger person. Try to learn from your mistakes and try harder not to repeat them the next time (that is, you should try to avoid those mistakes). If you take it to heart, you will suffer lowered performance, lack of trust, bitterness, betrayal, and a lowered self-esteem.

19. Create Action Items

The postmortem meeting will not be of any use if you are not able to define some core action items. These action items should address the key lessons from the project. For each action item, clearly define an owner and time-line for completion. You can add statements as shown in the following table:

 
 

Holding a postmortem will only be successful if you are prepared, follow a clear agenda, and execute the action items resulting from the meeting.

20. Act on the Conclusions

Turn the knowledge you have collected into action plans and try to incorporate it into your project processes and methodologies. It is a productive way of closing a project because you actually gain enriching experience. Don’t get the e ort in getting people together, documenting experiences, creating action items, and a project postmortem report go wasted by forgetting to act on the conclusions of the report.

An action plan that doesn’t lead to concrete actions is useless.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: