How to Lead a Successful Project Retrospective Meeting (2019 Update)

We do not learn from experience … we learn from reflecting on experience.

John Dewey

These meetings go by many names – postmortems, retrospectives, after-action reviews, wrap-ups, project “success” meetings. Regardless of what you call them, they all have the same goal and follow the same basic pattern.

What is a Project Retrospective?

The Project Retrospective dedicates time to reviewing a completed project and learning from both the successes and the failures so the team and organization can improve how they work going forward.

Formalized as the after-action review by the US Army, these meetings ensure a team quickly learns from each engagement.

There, the classic questions go something like:

• What did we set out to do?
• What actually happened?
• Why did it happen?
• What are we going to do next time?

The Core Process

The process for debriefing a project covers roughly the same topics as the quick after-action discussion. I’ll go into more detail below, but in brief, it looks like this.

1. Review the project.

Start by reviewing the project facts: goals, timeline, budget, major events, and success metrics.

In order to come up with useful ideas that everyone can agree on, the team needs a shared understanding of the facts and insight into the parts of the project in which they may not have been involved.

It’s important not to skip or rush through this step, especially for larger projects. People will arrive at the retrospective ready to discuss and solve problems, often assuming they know everything they need to know about what happened. This is rarely true.

If you are reviewing a project as a team, that means it took many people with unique experiences to get to that point. This step ensures everyone gets all the facts straight before they try to solve problems they may only partially understand.

2. Discuss what worked well and what didn’t.

This is the heart of the meeting. Everyone shares what they learned during the project: both the good and the bad.

In my opinion, this is the most fun and most challenging part of the meeting. As the meeting leader, you have an enormous impact on the success of your retrospective by deciding which questions you’ll ask and how the team shares their answers.

3. Action planning: identify specific ways to improve future work.

Have you ever worked with a group that talks about their aspirations, problems, and what needs to change, but never actually does anything about any of it?

That sucks. It’s de-motivating, discouraging, and a waste of time.

Real change is the ultimate measure of a retrospective’s success. To ensure that your retrospective results in something actually getting better, you’ll end the meeting by creating a specific action plan for improvements.

Framing guidelines

Retrospectives are a Practice.

Leading a really great retrospective takes skill that you can only gain through experience. Participating effectively takes practice too.

These meetings go better and get better results after you’ve done them a few times. People need to get a feel for what kind of feedback proves useful. They need to see that their ideas are heard, and that some real change comes out of the meeting. Practice helps the team prepare more easily, and to make better agreements faster. More importantly, a well-executed retrospective leads to changes that improve how the team works going forward; a real opportunity to create meaningful change is a huge motivator.

Plan enough time.

Each meeting needs to be AT LEAST 1 hour. Rule of thumb is 45 minutes per week of project work. 
As an example, I once managed digital web projects that lasted 3 to 6 months. We ran shorter retrospectives after every major milestone, then one big “Project Wrap” or “Success Meeting” at the end. The Project Wrap typically lasted 3 hours, after which we all went for nachos and beer.

Preparation is required.

You’re asking the team to reflect on their experience, pull out key learnings, and turn that into tangible change. If you rush it, you’ll get whatever comes to mind in the moment, which will usually say more about how each participant’s current project is going than what happened in the last one.

Don’t wing it. Have a plan, and make it easy for the team to come prepared.

Start positive by focusing on successes first.

I know this sounds a bit Pollyanna, and certainly setting a positive tone is one big reason for this guideline.

More importantly, though, you must start with successes to ensure they get discussed. Once you start talking about problems, there’s no turning back. People are naturally wired to recognize when things aren’t going well, and to focus intently on how to fix problems. This leads us to take our successes for granted, assuming that things went well because we did a great job.

That’s a trap.

For example, have you ever met someone deeply privileged, who sailed through childhood and college on their parents’ dime, trophies for all their “accomplishments” on the wall, only to be shocked and disillusioned when the “real world” didn’t reward their special unicorn self for just showing up? If you’re lucky enough to live in the US, of course you have.

Businesses do the same thing. An enormous part of what helps one project work where another doesn’t is luck – and we take it for granted. Instead, we should be looking for ways to learn from our lucky breaks and design ways to be successful that we can manage directly.

To make sure that happens, and to avoid the special unicorn trap, you must dedicate time to inspecting your successes first.

See this great article from HBR for more on this one:
Why Leaders Don’t Learn from Success

Make it safe.

Have you heard of “blameless” retrospectives? In the software community, we see a lot of emphasis on ensuring the retrospective is about sharing insights and learning, and not about placing blame, venting, or working out your interpersonal issues.

If your group might be prone to playing the blame game, study up on blameless retrospectives. Also, consider sharing the Retrospective Prime Directive at the beginning of the meeting.

The prime directive says:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass.

Norm Kerth, Project Retrospectives: A Handbook for Team Review

Small changes have a bigger impact than good ideas that never happen.

At the end of the meeting, you need to walk out with some concrete actions to take. Big exciting plans feel great, but it’s a real let-down if the change never happens. If people see that these meetings generate all kinds of ideas, but nothing real ever comes of it, they’ll stop participating.

For a meaningful result, make sure the action plans coming out of your meeting are realistic, and that the people responsible for the changes can actually implement them. The change can be big if the person responsible has the time and authority to put it in action. But if not, get creative and go for the quick win that the team can control.

Another tip on this one: if you and your team only have enough influence to make tiny changes, retrospect more often. Those tiny changes will compound over time.

See more: The ROI of Agile Retrospectives: How Effective Rertros Can Improve Your Bottom Line

Step-by-Step: Designing Your Project Retrospective

The Agenda

1. Welcome
2. Project Review
3. What did we learn?
   • Successes
   • Challenges
   • Other Insights
4. Priorities: What matters most?
5. Changes to Make: Action Planning
6. Closing

Preparing

1. Identify your audience.
   To whom will you “hand off” the results of this meeting? Is this to help your team improve an internal process, for a team inheriting your project, or for the department or company as a whole?
2. Assemble a project report and timeline, including major events and milestones.
   Also, review the original project definition, success criteria and any metrics you have regarding the project’s outcome. 
3. Refine the agenda.
   Decide how you want to run the different parts of the meeting and update the agenda accordingly. If this is your first retrospective, we recommend sticking with the simple format outlined below.
4. Schedule the meeting at least 3 days in advance.
5. Invite the team.
   Ask them to come prepared with their key insights, observations, and ideas for improvement.
6. Get supplies.
   Several retrospective techniques require additional supplies, such as sticky notes or online voting systems. In-person meetings benefit from snacks!

Bonus: if you can get a neutral facilitator and a dedicated note taker, awesome. That lets you focus on contributing your insights as an equal, and frees you from having to serve the group.

Running the Meeting

1. Welcome

Connect to each other, and the goal.

First, welcome people. Confirm for everyone what the meeting end result will look like, and the process you’ll use to get there.

Then, if you have people who don’t know each other well, run a round of personal introductions.

Finally, set the tone by sharing the Retrospective Prime Directive or something similar.

2. Project Review

Next, make sure everyone has a shared view on the project.

You can do this one of three ways.

Option 1: Ask the group to talk about it.

For shorter projects or for mid-project retrospectives, you can ask the group to discuss the facts.

Questions to ask:

What was supposed to happen?
What actually happened?

or

What did you set out to achieve?
What was your plan to achieve this? How did this change as you progressed?

Option 2: Share a report

The project leader presents a project report, and the team comments along the way.

Option 3: Create a shared timeline

For example, see the Peaks and Valleys exercise

This is one way to create a shared timeline. It takes longer, but it makes for a better conversation and a stronger shared experience. And it’s fun!

3. What did we learn?

This is the bulk of the meeting, where you talk about what you learned that you will hand off to other teams or use to change what you do going forward.

There are lots of ways to ask for this feedback. Our downloadable facilitator’s guide lists several options. Before you decide how to collect answers, though, you need to figure out exactly which questions to ask.

In our online template, we keep it simple. We ask about:

Successes

What worked really well during this project?
What should we make sure we do again in the future?

Challenges

Where did we run into challenges?

Other Insights

Where did we get lucky?
What was unexpected?
Who helped you on this project?

Questions to Ask in Retrospectives

Here are some other questions you might ask, depending on what your team needs to pull out of the conversation.

4. Priorities: What matters most?

Once you’ve collected all the feedback, you’ll be looking at at a big set of ideas. You can’t practically tackle all of them at once, so now’s the time to focus in on those 3 to 5 things that will have the biggest impact.

As a group, pick the top ideas (or themes) that you want to discuss as a team.

5. Changes to Make: Action Planning

Turn each prioritized idea into an action plan. Get specific. Document who will do what by when, and when the team can check back to see results.

6. Closing and Evaluation

Then start closing the meeting. Thank everyone, recap what you’ve accomplished, and tell everyone when and how they can expect to see the meeting notes.

As a final step before you leave, or in a follow-up email, get feedback on your meeting. You want to know if people found it useful and how to improve the meeting design next time.

See 2 Fast and Easy Ways to Get Meeting Feedback

The Take-Aways

There’s a lot to running a successful retrospective. I’ve shared a lot here, and there’s even more in the guide.

Don’t let this intimidate you. As you get started, remember:

1. Anything your group learns that helps you improve makes a difference, even little things that felt weird to talk about.
2. It’s a team effort. As the leader, you set up the framework, but it’s up to the whole group to get the result.
3. You don’t have to know all the tricks to get started. Some people run retrospectives simply by posting the questions and letting everyone talk.

As Confucius said:

By three methods we may learn wisdom:
First, by reflection, which is noblest;
Second, by imitation, which is easiest;
and third by experience, which is the bitterest.

Confucius

The retrospective is your opportunity to elevate the bitterness of experience into the nobility of reflection.

Bringing this Process to Your Team

The Meeting Guide for successful project retrospectives

And if you’ve found something that works especially well for you, please share it in the comments below for future readers to see too.

General FAQ

Additional Resources

There are SO Many good resources for learning about retrospectives. Many come from the Agile software development community, but the practices apply no matter what kind of project you run. These are just a few of our favorites.

• Fun Retrospectives www.funretrospectives.com
• Retrium: Dedicated software and great resources for running online agile retrospectives, retrium.com
• Retro-mat: provides you with a random plan, ready to refine (Thanks, Diana!)
• 10 Tips for a Successful Post-Mortem
• Redefining the Post-Mortem Meeting
• After-Action Reviews
• Which questions do you ask in retrospectives
• Esther Derby and Diana Larsen , “Agile Retrospectives: Making Good Teams Great” 2006
• James Shore, “The Art of Agile”, 2007