Project Retrospectives: The Complete Guide

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:

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!

There are five common project retrospective types:

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.

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

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:

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. 

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:

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:

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:

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. 

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:

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:

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.

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:

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

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

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. 

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:

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

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.”

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.

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.

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.

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.

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:

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. 

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.”

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:

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.