I'm conducting a Post-Mortem Review with Senior Management, regarding a project that had multiple unfulfilled/half-fulfilled deliverables that caused issues for clients. The deliverable for the Post-Mortem is a document that should link issues to unfulfilled/half-fulfilled project deliverables.

How can I ensure the format of the Post-Mortem connects Project Issues to Project Deliverables?

  • Hi Andrew, welcome to Project Management Stack Exchange, the Q&A site for project managers. Can you edit and tell us more about the problem you hope this will solve? Answers in the Q&A format typically work better when we know more details about your specific problem. Please see How to Ask for more guidance. Good luck, and welcome to PMSE! :)
    – jmort253
    Commented Dec 12, 2012 at 14:43
  • 1
    @Andrew - Can you provide more details on what you are trying to accomplish, what are the key items you are looking for, etc? Your question as written is very broad and you are likely to not get what you need.
    – Doug B
    Commented Dec 12, 2012 at 14:47
  • I think it is an excellent question.
    – MCW
    Commented Dec 12, 2012 at 18:35
  • If anyone has an answer, I'd say go for it, but just keep your eyes on your post in case Andrew provides some updates, this way you can be sure to update your answer as well, if need be. Good luck!
    – jmort253
    Commented Dec 13, 2012 at 4:28
  • 2
    @Andrew While answers often contain links to templates, PMSE isn't a search or referral engine. I've refactored your question to address what your deliverable needs to contain so that it's not marked as an off-topic "shopping" question. Please feel free to edit further, especially with details about what you've already tried to build and why it isn't working for you.
    – Todd A. Jacobs
    Commented Dec 14, 2012 at 13:14

2 Answers 2


Unfortunately, I cannot recommend you a fixed template of Word/Excel/PowerPoint or other template, but I hope, that this answer can help you by creating one.

A Postmortem Analysis is composed by a meeting and a documentation. Their base idea is the same, to figure out why was the client lost or why did the project fail. The investigation has to be documented. I propose the following document structure:

  • Short presentation of the project:

    1. Project's aim, what wanted the client to see
    2. Team members, everyone's role in the project

    3. Planned time, deadlines and milestones

    4. Team member's role, responsibilities, tasks

    5. Resources, data requests [for ex. design elements from the clients] with deadlines

  • Project analysis - risk management, if your team member's professional level is at the needed level (this idea doesn't appear in many studies, but I think it's a base thing), if you have the needed device background (I mean, it's pretty hard to develop a mobile application without device, only on simulator).

  • Present the realized part of the project: where did it stop, until the "dead" what task were completed/began.
  • The breakup: in what circumstances was the project declared failed; what exactly happened - in details; identify everybody who was in case, directly or in indirect mode. This is the critical part of the analysis. People hate critics (it's a normal thing), but you have to do your best and be real (avoid to kick the goal to the other team members), but you have to think that the people working in your team have responsibility, and this means to stand up and confess the decisions even in failed cases. This should be the descriptive part of the analysis, where you take out each failed issue, and describe it's details.
  • Conclusion: what should be modified next time, situations to avoid, paradigms to be fixed at the beginning of the project.

If you will take a presentation/meeting about the failed project, it should go through the steps presented upper, with highlighting the risky points and the failures. In many cases, not only one failure brings to the whole project dead, there should be a range of failures.

EDIT: If you would like to read a little bit more about this, I suggest this (especially slide nr. 19), this and this link to be useful.

  • 1
    What went wrong, why it went wrong, and what lessons can be learned...I think that's a good summary of what you said above, and a solid framework to start with.
    – Todd A. Jacobs
    Commented Dec 14, 2012 at 13:19

This is fairly easy. Break it down the same you did to plan the project and follow the paths - scope to deliverables to tasks to responsibilities.

Outline the scope and what specific deliverables were required. Then review what in the scope and deliverables wasn't completed, and what were the issues that prevented it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.