Post-mortem. After-action review. Debrief. Retrospective. Whatever term you use to describe it, taking the time to go over what worked on a project and what did not can often be invaluable.
“They enable project managers, teams, and organizations to evaluate and learn from past experiences,” says Susanne Madsen, project leadership coach and author of The Power of Project Leadership. “A big part of maturing as an organization is understanding what we are doing well and where we could improve. How many of our projects are successes? How many fail, and how do we measure that?”
“If we don’t review our projects at the end and conclude on them, we have no structured way of understanding how we are doing as an organization and improving on our situation,” Madsen adds.
Post-mortems are not only valuable in avoiding repeated missteps on future projects, but they can also uncover sources of productivity, reveal best practices, and keep IT morale high. Making sure everyone understands the whats, whens, whos, whys, and hows of post-mortems is the first step in institutionalizing these after-action steps in the organization.
[ Counterpoint: If you’re following the agile methodology, you’re learning and iterating daily. Read also: Agile project management, explained and Traditional IT postmortems are dead in the agile age.]
What is an IT post-mortem?
“A post-mortem is an opportunity for all constituents involved in a project to get together to discuss what did and did not work well on the project, and what can be learned from successes and mistakes,” says Mark Broome, chief data officer at the Project Management Institute (PMI).
Ideally, the post-mortem covers all aspects of the project, says Broome. That will include, but not be limited to, financials, technical design and solution, communication, team structure and competencies, sourcing, schedules, risk management, team dynamics, collaboration, and deficiencies.
Why should IT organizations conduct post-mortems?
“The learnings from a post-mortem allow the organization to improve when performing future projects. Post-mortems are incredibly important contributors to a learning organization,” says Broome. “If teams bypass a post-mortem, they are likely doomed to repeat the same mistakes. Past is often prologue, particularly in project management.”
“The future is just as predictable in IT as in the real world,” says Ryan Scott, chief technology officer, product and integrations at DNA Behavior International. “The after-action review is critical to flush out the root cause of issues, calm down everyone that might still be amped up, and resolve any remaining issues.”
When should the post-mortem take place?
The short answer? “Soon enough so we don’t forget details, but also long enough to let people get some rest and clear their heads,” says Scott.
For well-defined traditional IT projects, a single post-mortem after the project is complete may be adequate. “However, if a project is truly unique with many unknowns at the onset, a more agile approach is warranted,” says Broome. “With agile, post-mortems are performed between sprints; same at program increments and at the end of projects. The goal is to uncover opportunities and issues as soon as possible and make adjustments to improve at the team, function, and organizational level.”
What should I do in a post-mortem? Who should be involved?
The scope of the project will help to define who should be involved in the post-mortem. The invite list will also depend on whether the review is for a sprint, a program increment, or the end of a large project. Agile sprint retrospectives typically involve core team members. For program increments, anyone involved during that period should be invited.
For true post-project reviews, all stakeholders should be involved, including the core team, any departments tangentially touched by the projects, and even customers. “It is important to have all necessary representation to get a 360-degree view of the project and identify any challenges, successes, and opportunities for future project work,” Broome says. It can be beneficial, particularly in a troubled or fraught project, to enlist a moderator from outside the project or outside of IT.
What should the process look like?
This depends on the IT organization. Scott likes to have an in-person meeting (with video from remote workers) led by a manager from another department. The project lead gives a brief summary of the project and areas to focus on, and then the after-action will invite the team to offer input on the project, proceeding in chronological order, from documentation to project completion.
Madsen likes to invite the core team to a workshop and ask them two questions: What did we do well? And where could we improve? The post-mortem leader will list answers on a flip chart. Key stakeholders and clients may also contribute.
For Broome, the key elements are discussing the goals of the project; calling out accomplishments, challenges, and opportunities; and deciding what communication needs to occur to get the most out of the process.
How should the results be captured or applied?
The outcome of the post-mortem should be some artifact of the project evaluation. “Basically a document stating what went well, what was delivered, what is outstanding, and what could be done better next time,” explains Madsen.
Should every project have a post-mortem?
“There is always something to be learned from every project that is best captured in post-mortems,” Broome says. “If you do not have a post-mortem, it’s a missed opportunity to learn and improve.”
[ Culture change is the hardest part of transformation. Get the eBook: Teaching an elephant to dance. ]
