In the army, it’s unthinkable to end a mission without a debriefing meeting to uncover lessons learned. In many businesses, it’s unthinkable to end a project with a lessons learned meeting, retrospective, or post-mortem because “we’re too busy.”
And so we rush on, making the same mistakes again and again in our next projects.
In fact, we waste much more time and money by repeating mistakes than by holding a short lessons learned meeting after each project milestone.
Takeaways from lessons learned meetings are taking into account in the team’s future projects can can also be spread across the organization.
Lessons learned meetings may also be referred to as project post-mortems, after-action reviews, or retrospectives.
Lessons learned meetings typically happen at the end of a project or on a fixed cadence. You can also hold a review meeting in the middle of a large project whenever you complete a milestone.
Lessons learned meetings can be run:
You can also plan a lessons learned meeting at the beginning of a project. That timing allows you to review learnings from past projects before starting a new one.
In such a meeting, you can also include a premortem exercise, where you anticipate what could go wrong and then make plans to avoid those unwanted scenarios.
Agile teams practicing Scrum hold a special type of lessons learned meeting called a retrospective. The goal of a retrospective – like a lessons learned meeting – is to look back and review how the last working period went. Agile teams often do this every 2-3 weeks. The goal is to achieve “continuous improvement”.
A lessons learned meeting should only involve folks who can contribute meaningful insights. An overbearing manager who wasn’t involved in a project shouldn’t be invited. But a salesperson who talks to clients daily may be able to bring helpful insights, even if they didn’t work on a product or project directly.
Determining who to invite should stem from your meeting’s goal. Asking outside stakeholders to join isn’t helpful when you want to focus on collaboration within the project team.
But suppose your goals are to make future products or project deliverables more valuable for customers and improve cooperation between departments. Then you’ll want to invite people from outside your team.
Whoever you invite, try to aim for no more than five to 10 attendees. Fewer folks means you’ll likely miss diverse perspectives and input, but a large group makes the meeting unwieldy – unless you have a black-belt meeting facilitator. 🥷
Running a lessons learned meeting doesn’t have to be difficult or anxiety-inducing. We’ve put together a simply 6-step process you can follow.
To run a successful lessons learned session, you must gather the right info, people, and agenda items in advance.
You should also be clear on what you want to achieve with the meeting. After all, failing to prepare for your meeting is preparing to fail.
Your meeting’s goal informs all the other steps we’ll go through, so it’s essential to work on this first.
Often you want to do a general review of a project when it finishes to uncover lessons learned. You might have a more specific goal at other times, like “learn what happened during the Christmas server outage from the engineering team.”
Sometimes you also know in advance what deliverables you want from a lessons learned meeting, like “create a report for the executive team” or “share our learnings in a blog post.” It’s helpful for everyone involved to know what will happen with the insights from your meeting.
Try asking attendees to provide input in advance of your lessons learned meeting.
Running a partly asynchronous lessons learned meeting has several benefits:
You can gather input from attendees through a survey you send them, or you can use an online lessons learned tool like Parabol. Our app lets you create a virtual space where attendees can leave their thoughts anonymously and answer your meeting prompts asynchronously before the actual meeting starts.
🏢 Back in the office?
Learning lessons means thinking deeply about what has happened. You can trigger such reflections with pointed questions and a psychologically safe environment where everyone feels comfortable chiming in.
Before diving into contemplation, announce meeting rules that put everyone at ease to share freely and candidly. Consider using or adapting these practices that are common in retrospectives for agile teams:
Without questions to guide people’s thinking, you’ll end the meeting without valuable insights. But not every question will do. Vague questions lead to vague answers and leading questions to misleading answers.
You need pointed, open questions. Such prompts give participants some direction, but not too much. The default question-set for lessons learned and retrospective meetings is:
These prompts work, but you can swap them for other questions that match your meeting’s objective. Our retrospective templates are a great source of questions, even for non-agile teams, with sets like:
