Conducting the Post Mortem

06 October, 2014

If you run your projects strictly according to the processes laid down in the Guide to the Project Management Body of Knowledge (PMBOK® Guide), then you will ensure that all of the project’s deliverables are complete and acceptable to the customer (Validate Scope) and then you will carry out the Close Project or Phase process.

While preparing for your Project Management Professional (PMP)® exam, you learned that closing the project involved archiving all the project artefacts, so they can contribute to the organization’s process assets for future projects and recording the lessons learned from the project.

Archiving the project’s artefacts is straightforward enough. If your organization is well established in terms of project management maturity, you are likely to have used defined templates for your plans and reports and these can easily be stored using the organization’s Project Management Information System (PMIS). Even if you are the only PMP® on the books, you should have a well-organized set of documents that you can store safely and whose location you can publish for future reference.

It is the lessons learned bit that can cause problems. The PMBOK® Guide mentions meetings as a way of gathering lessons learned, but has no words of wisdom to offer as to how these meetings should be conducted and what exactly are lessons learned. Similarly, they shy away from the familiar term used for these meetings: Project Post-Mortems. This is understandable as the term “post-mortem” does suggest that something bad happened and the purpose of the meeting is to determine the cause of that problem.

If you, as the Project Manager, invite the team into a Project Post-Mortem, you have automatically put everyone on the defensive. So it might be better to call the meeting a Project Review, or maybe borrow from Scrum project management and call it a Project Retrospective. Set the agenda clearly. Basically the Project Manager needs to get three types of information from this meeting:

  1. What went well
  2. What went badly
  3. What we should do differently next time around.

If you have ever conducted a Project Post-Mortem, you will find that sitting at the table with a notebook in your hand and asking the team: “What went well in the project?” will elicit few responses. Getting on to “What went badly?” you can expect stony silences. This is understandable. While modesty forbids many individuals from boasting about their achievements, there are very few team members who will candidly highlight mistakes they made during the project.

For the Project Manager, going into the really useful part of the meeting – “What should we do differently next time around?” – without any sort of momentum will mean that suggestions will be few and far between.

As the Project Manager, you cannot go into this meeting as a passive recorder. Instead you have to present an overview of the project. Show where it came from – what corporate goal was it meant to contribute to. Then summarize the planning process, especially highlighting where the team got involved. In order to put the planning work in perspective, show the baseline plans against the actual values. This is a very useful trigger for discussions. If there were lots of change requests, why did that happen? Were our estimates significantly out? If so, how can we improve? Did risks materialize that we had not identified? Why was this?

Of course, it is important not to focus exclusively on the failures of the project. This is a good opportunity to distribute some public recognition for people who did good work. For instance, a team member might have constantly met targets throughout the project. The Project Manager could ask why this person is so effective at estimating. If there is some technique involved, this may be considered universally on the next project. Another area to highlight is new techniques that were applied. Did they work? Was the team comfortable with using them? Should we continue using them on future projects?

Of course the really difficult part of a post-mortem is investigating the issues that arose. Language is crucial here. Leading with “Johnny really screwed up the flux capacitor development” will guarantee a stilted response. However, using less aggressive language, such as “Johnny had a disappointing project – he was into a headwind all the way” should yield better results. The crucial thing is to focus on the obstacles – new regulations, the initial design failing, or new tools and techniques. Then put it to the team member: “How would you handle this differently if we were to do this again?”

Unfortunately, not all issues arising on the project relate directly to the project. Team members can fall ill or face domestic tragedies. Even good events in someone’s private life can conspire to give Project Managers ulcers – planning a wedding or expecting a baby can distract someone profoundly from their work. These issues need to be discussed in private and the person involved should be reassured before the post-mortem that they will not be criticized in public. For the Project Manager, human factors are largely unpredictable and allowances need to be made. In other words, among the risks identified for the project, some contingency needs to be put in place to facilitate team member distractions during the project.

Project closure is covered in Velopi’s PMP® exam preparation courses. If this is of interest to you, please visit our training page or contact us directly. For your convenience, our PMP® training is carried out in Dublin, Cork, Limerick and Galway.

By Velopi Seamus Collins

© 2018 Velopi : PMBOK, PMI and the R.E.P. logo, PMP, PgMP, CAPM, PMI-SP and PMI-RMP are registered marks of the Project Management Institute, Inc.

Web Development by Granite Digital