Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
I'm looking for a less ominous term than postmortem1, but that's still clear about the purpose of the exercise. We considered but discarded:
Debrief
Too vague and unfocused. We're not here to chat, we're here to get to the root cause.
Retrospective
Way too vague.
What would be an alternative term that fits the intent without sounding as negative as postmortem?
1: The term is often spelled as both one word and two in various dictionaries. Edits were done to make this searchable either way.
That's the purpose of a post mortem. That's the purpose of a project/phase retrospective also.
What went well, what not so well, what we learned, and what are some action items for improvement to bring to the next project/phase?
A more friendly and less formal alternative term for "post-mortem" is "lessons learned" or "retrospective." This term focuses on the positive aspect of learning from experiences and identifying areas for improvement, rather than the negative connotation of death. It encourages to look at the past with a constructive mindset and to focus on the future.
While post mortem is really the most accurate term, and "lessons learned" or "action items" are the things you want to take away from such an event, the event itself is really a meant to be a collaborative review among stakeholders and participants where blame is explicitly prohibited from the meeting's agenda, communications process, and findings.
"Review" is a neutral term that can refer to the outcome or execution of a project, an examination or enumeration of its results, or simply a consensus-building exercise about what was done and how that turned out in comparison to original expectations. In other words, the focus is kept tightly on processes and outcomes rather than "holding people accountable."1
If you need a term that encourages a detailed examination without triggering an inherent finger-pointing response, definitely consider using "review." Just make sure that the exercise results in meaningful takeaways. Otherwise, if the goal is just to make everyone feel okay about project failure or a sub-optimal outcome, there's really no need to waste everyone's time in a protracted meeting that simply provides an emotional bandage and no lasting results.
We tended to use either the phrase "Post System Implementation Review" or "Project Review" depending on the circumstances. Either of these could be used in the way that you describe, to learn lessons and provide feedback into future plans / projects. Note that without that feedback element, it is likely to be little more than a pointless exercise that just makes the "winners" feel good at the expense of the "losers" - and there should be neither of these unless you are playing the game of pointing fingers of blame.
If neither of these phrases fit your process, you could use whatever descriptor is more valid - e.g. "Stage Review", "Phase Review", "Development Review", "Testing Review", or whatever.
If you are using Scrum, then I understand that "Retrospective" has a specific meaning which maybe you don't like, but would be widely understood by other practitioners.
In my view, I have always separated the types of rear-facing analysis due to the intent of the review. In other words, I do not think that a lessons learned or retrospectives or whatever you want to call it is the same as a postmortem review. While they sort of seem similar, a postmortem is all about finding reasons for the death...or project failure or performance degradation in our case.
Therefore, postmortem or forensic analysis or autopsy is the right word to use.
There is no reason to soften it up. It's what it is. We experienced a crash and we need to find out why it occurred to do the things to attempt to prevent it in the future. When doctors perform autopsies, when the NTSB investigates a crash, when a forensic accountant is sifting through financial documents, they don't soften things up so we can digest them better. We as PMs do not need to do that, either.
However, for a historical review of what was done, trying to learn both from what went well and what didn't, and for reviews that we schedule after all work, call it whatever resonates with your stakeholders.
