Skip to main content

Project Retrospectives: The Complete Guide

parabol-project-retrospectives (1) (1)

Many people never visit a gym. Some sign up but rarely go. Only a tiny percentage build a workout habit and get benefits from their membership.

Project managers are similar.

Many don’t hold retrospectives or lessons learned meetings after a project. Some do, but not on a regular basis. Only the most disciplined project managers hold them consistently and improve future projects.

Retrospectives aren’t just for software development teams. Teams in any industry can benefit from regularly reflecting on their work to find improvements for future projects.

The main challenges you might face with project retros are how to:

  • Find the right format for a project retrospective
  • Build a habit of holding regular project retrospectives
  • Communicate the importance to team members
  • Get buy-in from team members to try something new and participate fully

After reading this piece, you’ll know which format to choose for your next project retrospective, and be armed with tons of tips to make your meetings more effective!

Project retrospective meeting types

There are five common project retrospective types:

  • Lessons-learned meetings
  • Agile retrospectives 
  • Project post-mortems
  • After-action reviews
  • Pre-mortems

All these formats aim to look back at past work to improve future results. The differences lie in how they accomplish this, the type of projects they review, and the outcomes they generate.

Project retrospectives cheat sheet

Here’s a quick reference guide to help you find the right meeting type to use:

1. Lessons learned meeting

Objective: Identify and document lessons at the end of a project to perform better and avoid issues next time.

A lessons-learned meeting has the most flexible format of all project retrospective meeting types. There’s no set structure, but most teams follow these steps:

  1. Set an objective for the meeting
  2. Reflect on the project with strategically selected questions.
  3. Group similar reflections into themes.
  4. Discuss themes to distill lessons learned.
  5. Define an action plan for how to improve your next project.

The goal of a lessons learned meeting is to understand what went well and what could have gone better. After identifying those things, you make a plan for how to improve for the next project, and how to replicate your successes. 

When to use lessons learned meetings 

You can hold a lessons-learned meeting at any time because of its flexible and casual structure. You can schedule one at the end of every project or when you want to involve stakeholders from across the organization. You can even invite external clients, so you can learn how to improve your collaboration.

📚️ Further reading

Interested in learning more about lessons learned meetings? Check out these articles:

2. Agile retrospectives

Objective: Continuously identify ways to improve a team’s workflow, effectiveness, and quality of work.

Teams that follow an agile framework like Scrum hold retrospectives at the end of each work cycle (a “sprint”). The team reflects on their past sprint to discuss what went well, what could be improved, and how to make changes for better results in future work cycles. By holding these meetings after every sprint or iteration, teams keep increasing their performance.

A typical agile retrospective follows this format:

  1. Prepare your retrospective tool and a retrospective template
  2. Set the stage with an icebreaker
  3. Gather reflections about the sprint
  4. Group reflections into themes and vote to prioritize important issues
  5. Discuss, generate insights, and create action items
  6. Make sure action items are documented and assigned to a person so they get implemented

When to use agile retrospectives

Agile retrospectives are ideal for teams that face rapidly changing markets or project requirements. They also provide short feedback loops for teams that want to improve their performance quickly. 

The key difference between agile retrospectives and lessons learned meetings, is how they are used by teams. A lessons learned meeting is usually held at the end of a project. An agile retrospective is held at the end of a sprint, which lasts between one and four weeks. Teams that use agile retrospectives can generate learnings and implement improvements “mid-project”. 

📚️ Further reading

To learn how to run an agile retrospective and dig into more details about this meeting type, take a look at these resources:

3. Project post-mortem

Objective: Find the root causes of a severe problem and implement solutions to prevent it from happening again.

During a post-mortem, the team analyzes an incident or project’s death like a coroner: thoroughly, dispassionately, and scientifically. For example, let’s say your client fired you, or your app had a severe outage; a post-mortem can help you get to the bottom of what happened.

To run a post-mortem, start by reviewing the timeline of events that led to an incident or project failure. Then you analyze the root cause of every problem you’ve identified and develop solutions to prevent these issues in the future. You can use a model like “5 Whys” or create a Fishbone diagram to help you get to the bottom of why certain actions happened. 

When you’ve learned what went wrong, set action items together to protect yourselves from similar issues in the future. 

When to use project post-mortems

Projects, like people, only have post-mortems when something has gone horribly wrong. Turn to this meeting type when you want to get to the bottom of a critical issue.

📚️ Further reading

To find out how to run a project post-mortem and get more details about this meeting type, have a look at these articles:

4. After-action review

Objective: Evaluate a team’s performance after an event, big or small, to identify future improvements.

The after-action review (AAR) comes from the military. After returning from a mission, teams will review whether it was successful, and discuss risky operational hiccups. 

The army’s AAR process is more than just one meeting. It’s a cycle of events – similar to Scrum sprints – that includes short huddles, planning and review sessions, and explicitly connecting lessons learned to future actions.

The AAR meeting has four parts to ensure you analyze a situation from all angles:

  1. What did we expect to happen?
  2. What actually happened?
  3. Why was there a difference between what we expected and what actually happened?
  4. What can we change next time?

In the military, a team holds an AAR immediately after every significant phase of an operation. Some of those meetings only last ten minutes when time is limited.

When to use after-action reviews

You don’t need to be in the army to run this meeting! 🪖 After-action reviews (AARs) are great for evaluating and improving team performance on an ongoing basis after a specific event. You can use them after client meetings, product launches, and conferences you’ve attended or organized. Regular AARs help ensure teams consistently perform at their best.

The difference between AARs and post-mortems is that the goal isn’t to understand what went wrong and why. AARs are also different from lessons learned meetings because they focus on a specific event, like a launch event or a conference, whereas lessons learned meetings usually focus on projects.  

📚️ Further reading

To learn more about AARs and how to run them, head over to these links:

5. Project pre-mortems

Objective: Pre-empt all the things that could go wrong with a project, so you can proactively make plans to prevent them happening.

There’s one more meeting type we haven’t discussed that can improve your project results in advance! It’s the opposite of a retrospective: a pre-mortem.

“In a premortem, team members assume that the project they are planning has just failed—as so many do—and then generate plausible reasons for its demise.” – Gary Klein, inventor of the pre-mortem

By holding a pre-mortem before your project and imagining it already failed, you increase your chances of predicting possible problems by 30%.

You can prepare for those failures and reduce the chances they happen, improving projects before they even begin. You will then have fewer problems to discuss during your project retrospectives and more time to find ways to improve your work – a flywheel for increasing project quality and team performance. 🚀

When to use pre-mortems: You can use pre-mortems before any project, sprint, or event to identify risks and opportunities to mitigate them.

📚️Further reading

Tips, tools, and techniques to improve any project retrospective

The format of each project retrospective is slightly different, but you can benefit from these seven tips no matter what format you choose.

1. Let the team gather their thoughts in advance

Send participants information about the format, topic, and questions they might expect in advance. This approach allows people to consider their contributions, resulting in a higher-quality discussion during the meeting. You can also send a survey if the meeting facilitator wants input to work with in advance of the retro.

Parabol comes with 40+ built-in retrospective templates to help you run your next project retrospective. There’s also a handy list of retrospective questions you can pull together to help guide your discussion. 

2. Run the entire meeting asynchronously

You can run retros fully asynchronously with an online retrospective tool like Parabol. Doing so is handy when your team works across many time zones. Async retros also give everyone more time to contribute their thoughts about the project in advance and in their own time.

Here’s how to run an asynchronous project retrospective with Parabol:

  1. Open the retrospective at the start of the project so your team can add feedback throughout.
  2. When the project finishes, take one day to group and vote on reflections.
  3. Spend a little more time (two to three days) to have async discussions about the topics you have uncovered as a team. Or hold a video call to discuss them together face to face.

💡 For more information, check out How to Run an Asynchronous Retrospective.

3. Use the Five Whys for root cause analysis

Root cause analysis means you identify the source of a problem instead of its symptoms. For example, projects going over budget is a symptom. The causes could be unrealistic financial planning or insufficient oversight of project expenses.

To find root causes, you can use the 5 Whys Process. You keep asking why for every symptom you uncover until you arrive at the cause (”Why did we go over budget?” ➡️ “Because we spent too much on marketing.” ➡️ “Why did we spend too much on marketing?” and so on until you reach the source of a problem).

💡 Want to learn more about the 5 Whys Process? Check out Buffer’s excellent article on “The 5 Whys Process We Use to Understand the Root of Any Problem.”

4. Organize reflections by topic

In most project retrospective meetings, people have a few minutes to think about their contributions before sharing them with others. This practice usually leads to some similarities among everyone’s ideas and suggestions.

For this reason, grouping reflections into themes can be helpful. Say that one person writes, “We need to improve cross-functional communication,” and another “The team wasn’t aware of the changes made to the project plan.” You can then bundle these cards under one topic labeled “Communication issues.” This improves the efficiency of your conversations.

parabol retrospective group phase

Card sorting is easy in a physical conference room but difficult to replicate on a computer screen. That’s why Parabol has a multiplayer drag-and-drop and advanced search function for grouping cards into themes. Team members see where you’re dragging a card in real-time, which makes it feel like you’re in the same room, even when you’re halfway across the globe.

5. Focus on future action

When the army uses AARs, they explicitly link lessons to future actions. All project retro meeting types can benefit from this practice. After all, it’s no use identifying learnings if you’re not going to implement them.

Say client satisfaction ratings for your agency’s ad campaigns are dropping. You’ve traced that problem to an increase in small errors before work goes to clients. In that case, define a specific action that adds in more quality control before any work is sent out.

Another great way to act on project retrospective insights is by updating resources people use for their daily work at the end of a completed project. It takes a few minutes to update operational procedures, templates, and checklists, but those efforts can have a big impact.

6. Make a timeline for big projects

Reflecting on a big project can lead to recency bias: giving more importance to recent events. Another problem is that people mix up the order of events and make incorrect conclusions on why something worked or didn’t.

The best way to counter these problems is by letting people reflect on a project over a timeline (instead of just on a board or list). You can guide the group through the project one period at a time, like in the example below, month by month.

Parabol lets you build custom templates, so you can structure an online retrospective around a project timeline. Instead of by month, as in this example, you could also insert the project’s milestones into a template.

You can also give participants a few minutes to review their calendars, emails, or project plans to recall what they worked on during a period to inspire higher-quality reflections.

💡 Head over to How to Counter Recency Bias in Your Sprint Retrospectives for more insights and solutions on countering Recency Bias.

7. Set an expectation for excellence through consistent retro meetings

Most organizations hold retros occasionally at best. But when you hold retros after each project without exception, team members learn that mistakes they could have prevented will come to light in the next meeting.

This retro consistency encourages people to be mindful of risks and take steps to avoid errors during the project. As an army leader told Harvard Business Review (HBR) in the original article that popularized AARs for businesses:

“We live in an environment where we know we will have an AAR, and we will have to say out loud what worked and what didn’t. That leads to asking tough questions during the planning phase or rehearsals so that you know you have it as right as you can get it.”

8. Build psychological safety for better learnings

Project retrospectives require team members to be vulnerable about failure. It’s hard to create an environment where people feel safe owning up to things that went wrong. So try an icebreaker or team building activity to start your meeting and bring down barriers. Parabol’s project retrospective tool has built-in icebreakers to help people open up. 

retrospective prime directive

You could also try reading out the retrospective prime directive before your meeting to create a safe space. The prime directive states that: “Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”

Which project retrospective is right for you?

When it comes to project retrospectives, selecting the right meeting type can significantly affect the outcomes you get from the meeting. Different types of retrospective meetings are better suited for different insights, project stages, or project types.

Here are some final considerations to help you choose the correct project retrospective meeting type:

  1. Lessons learned meetings are the most flexible of the options we’ve discussed. They are an excellent way to gather feedback from team members and stakeholders and identify areas for improvement in future projects.
  2. Agile retrospectives are recurring lessons learned meetings that take place every “sprint”. That means they’re ideal for teams that want to discuss lessons learned on an ongoing basis, in the middle of projects, and at the end.
  3. Project post-mortems are more in-depth meetings that typically take place after a project has ended. They are ideal for situations when you have experienced major incidents or problems. Project post-mortems can help teams identify what went wrong, what went right, and what could be improved for future projects.
  4. After-action reviews are  great if you want to focus on a specific event or action and learn from it. These meetings are useful for teams that need to assess the outcome of a particular decision or action.
  5. Project pre-mortems are meetings held before you start a project, so you can pre-empt and mitigate any issues that could crop up.

Not sure where to start running one of these meetings? Try Parabol’s free online retrospective tool, which includes 40+ templates to help you run your next project retrospective, whichever type it may be! 

It makes life easy for facilitators by structuring your meeting with clearly defined steps, so you can feel confident running your first project retrospective with your team.

Tim Metz

Tim Metz

Tim Metz crafts content at Animalz for the world’s most amazing startups. He’s passionate about deep work and work-life balance.

All your agile meetings in one place

Run efficient meetings, get your team talking, and save time. Parabol is free for up to 2 teams.