5

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?

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
Andrew
  • 51
  • 1
  • 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 [ask] for more guidance. Good luck, and welcome to PMSE! :) – jmort253 Dec 12 '12 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 Dec 12 '12 at 14:47
  • I think it is an excellent question. – MCW Dec 12 '12 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 Dec 13 '12 at 04:28
  • Additional Details: Looking to Conduct a Post Mortem Review with Senior Management, regarding a Project that had multiple unfulfilled/half-fulfilled deliverables, that caused issues for Clients. Looking for a Word, Excel, Visio, or Powerpoint Template to conduct Post Mortem Analsysis, linking Issues to unfulfilled/half-fulfilled Project Deliverables. Thanks for your help. – Andrew Dec 14 '12 at 11:43
  • 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 Dec 14 '12 at 13:14
  • Great edits, @CodeGnome! :) – jmort253 Dec 14 '12 at 15:39

2 Answers2

5

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.

MMMM
  • 639
  • 3
  • 10
  • 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 Dec 14 '12 at 13:19
1

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.

Trevor K. Nelson
  • 6,781
  • 2
  • 17
  • 17