At the end of a project, you'll be completing tasks like archiving documentation, invoicing the client, conducting performance reviews for your team, and, of course, the most important thing—the project retrospective.
Retros are meant for reflecting on how the project went and what could be improved in future projects (and they're not an excuse to throw an 80s themed party, even though it might sound like it).
What is a Project Retrospective?
The project retrospective is a formal activity where project stakeholders are asked to look back on the completed project and reflect on what went well, what didn’t go so well, and what could be improved. You'll create an action plan for improving your future projects and processes.
As one of the key agile events, or ceremonies, project managers use retrospectives to assess how the team is working together and improve their process. The project manager must create a safe space so open and honest (and possibly unpleasant) feedback can be shared during the session.
Why Are Project Retrospectives Important?
A successful retrospective will improve your project processes and increase the likelihood of future project success. Here are some other reasons why project retrospectives are important:
- Continuous improvement: The team can reflect on what went well and what didn't. Learn from any mistakes and identify successes that you want to replicate. As you make changes to your processes and workflows based on this, the team will improve and work better together over time.
- Better team building and teamwork: The retro is a chance for the team to bond. It's a safe space where they provide constructive feedback and figure out how to collaborate better moving forward. Use retros to celebrate wins as well, as this improves team morale and motivation.
- Improved problem solving: The team can problem solve around challenges and blockers that they faced during the project and how they can solve similar challenges in future projects. They can also share best practices with each other, improving their collective knowledge.
- Better accountability: By getting the team together to discuss what went wrong, retros boost accountability and encourage team members to take ownership over their work. Don't assign blame for mistakes and focus on what needs to change to avoid those same mistakes in the future.
- Improved project planning: Documenting risks, project assumptions, blockers, and other things that went wrong during the project will ensure you can account for those things in project plans for future projects.
How To Run Project Retrospectives
Let’s take a look at some practical steps and advice for how to facilitate an effective retrospective session for your project.
Step 1: Build a culture of trust
Getting people to be open and provide feedback can be hard. It is even more difficult to do when there is distrust among the project team and stakeholders.
- In the past, was feedback criticized?
- Were team members made to feel intimidated by sharing ideas and feedback?
- After feedback was shared, were negative actions taken that may be viewed as punitive (for example, taking away certain perks)?
- Was the blame game played if problems were uncovered?
If you answered yes to any of these questions, these are definite reasons why there may be mistrust and an unwillingness to be open.
So how do you get people to be open and share feedback? How do you build a culture of trust and make people feel they are in a safe space?
You can try the following:
- Encourage open and honest communication: Ensure that your team feels that they are valued and appreciated. They'll be more willing to open up and share if they know they won’t be ignored or marginalized.
- Create opportunities for collaboration: These could be daily project status check-ins or non-project tasks like a team building activity. If people are given opportunities to collaborate, they will be more comfortable communicating.
- Make feedback part of the team’s culture: In software development projects, it is common for team members to have their code peer-reviewed by others on the team as part of the regular development process. Look for opportunities to do something similar on your project and for the team to get and receive positive and negative feedback on a regular basis.
Step 2: Determine what type of feedback you would like to collect
A lot happens during a project and as such, there is a lot of opportunity to collect a broad spectrum of feedback during a retrospective. This is okay, but it can also be overwhelming.
When planning to do a retrospective, define the scope of the feedback you would like to receive from participants.
Try defining some themes that you would like to collect feedback for, such as:
- Team performance: How did the team perform during the project? Were deadlines met? Was the work of quality?
- Communications & stakeholder engagement: Was information shared to the right people at the right time and using the right tools? Was it too much or too little information?
- Project deliverable: Did the project deliverable meet the expectations of stakeholders? Why or why not?
- Project processes and tools: Did any processes help or hinder project performance? Were processes missing or too much? Were the agile tools used in the project helpful or harmful?
Step 3: Set a dedicated time for the project retrospective
Set aside and schedule a retrospective at a dedicated time when participants will be available. If possible, try and schedule and send out calendar invitations (or ‘save-the-date’ appointments) a few weeks in advance.
Likewise, when scheduling your retrospective, send out your agenda with the invitation too (which we will get to soon).
Also, include any expectations for participants (for example if participants are required to complete any pre-meeting tasks such as downloading a specific software tool) in your invitation.
Project Retrospective Meeting Agenda
A retrospective does not have to be a super complicated activity. The purpose of a project retrospective is to gain feedback on the project to make continuous improvements for your next projects.
As such, here’s a sample agenda that can be used and tailored based on the length of the session:
- Welcome and introduction: Welcome participants to the session, introduce the facilitator, and state the purpose & objectives of the session
- Overview of how feedback will be collected: Provide a brief summary of how feedback will be collected during the session (oral, written, hybrid, anonymous, etc.) and what tools will be used (a virtual whiteboard, roundtable discussion, etc.)
- Review any rules of engagement for the session: Tell participants about any ground-rules (for example: feedback should be constructive and honest, provide both positive and negative feedback, etc.)
- Collect feedback: Capture the feedback you wish to collect using your desired tool.
- Review feedback with participants: Review all feedback collected (the good, the bad, & the ugly). During this part of the session, feedback should only be presented. Questions and discussion around specific feedback points should be limited (this is to ensure that you get a chance to review all the feedback and that the time is not spent on 1 or 2 items)
- Discuss feedback and questions: Gather thoughts, opinions, and responses from the participants. Do they agree with the feedback? Is there additional insight/context that needs to be shared? Discuss and capture the results.
- Formulate actions and next steps for improvements: Based on the feedback, brainstorm takeaways and action items that can be taken by the project team to make improvements. During this section of the session, detailed plans on how the improvements will be implemented do not need to be discussed (this can be done in a follow-up session). Ask for volunteers to take ownership of any follow-up actions or improvement items.
- Summarize feedback and improvements: Before you end the session, do a quick summary and highlight the feedback captured in the meeting notes and any next steps or actions that will be taken.
- Thank-you and session adjournment: Thank the participants for their time and feedback. Share the details about any follow-up sessions that may be scheduled. Likewise, share information on where the feedback collected during the session will be stored and if it will be available to participants later (for example, on a shared Google Drive).
FAQs About Project Retrospectives
Here are some frequently asked questions about project retrospectives. If you’re looking for in-depth information on agile concepts more broadly, consider trying an agile certification.
What is the difference between a sprint and project retrospective?
A sprint retrospective is an agile event that is completed at the end of a sprint or iteration. The purpose of a sprint retrospective is to examine what improvements can be made to the processes for the subsequent and future sprints.
As sprints are time-boxed events (ranging anywhere from 2 weeks to a month), a sprint retrospective will generate feedback and improvements from a short period during the project’s timeline, whereas a project retrospective looks at the entire project: what went well, what did not go well, and what improvements can be made for future projects.
Should You Include The Client?
That depends on the type of feedback you wish to capture during the project retrospective. If you are seeking feedback on the project’s communications, stakeholder engagement, and deliverable(s), then yes. If it is on the project team’s performance—maybe, but likely not. This is up to the discretion of the project manager and team.
Who Should Run A Project Retrospective?
The project manager or Scrum master usually facilitates a retrospective session, but any member of the project team that is willing to facilitate the session can do it. If the retrospective session may bring up negative or controversial feedback, you should consider using a neutral-third party facilitator.
In an organization I previously worked at, project managers would be asked to facilitate retrospective sessions for other project teams within the organization to ensure a neutral facilitator, but to also allow the team’s project manager to fully participate in the session as a stakeholder.
What Tools Can I Use for a Project Retrospective?
There are some great agile project management software tools available for organizations to use to conduct retrospectives. Here are a few recommendations.
Online Collaboration/Whiteboards
- Miro or Mural: both of these tools allow users to create virtual whiteboards and canvasses for teams to post their feedback. Ideal for remote teams.
- IdeaBoardz: Free and easy-to-use tool that allows users to create customizable online boards for retrospectives and feedback gathering anonymously via virtual sticky notes.
Check out more collaboration tools (for agile projects or otherwise).
Retrospective Software
- Atlassian Confluence: Online collaborative workspace that has built-in retrospective templates. Good tool to use if an organization is using other Atlassian products such as Jira
- GoRetro: Customizable, agile retrospective tool that offers many free templates
For in-person or on-site retrospective sessions
- A white-board and erasable whiteboard markers
- Post-it-notes
- Flip-chart paper
- Camera phone to take pictures of the whiteboards or flip chart papers to save for later & share
What is the Difference Between a Retrospective, Lessons Learned Session and a Post-Mortem?
A lessons learned activity is similar to a project retrospective. If you’re using the waterfall project delivery methodology, you would complete the lessons learned activity during the closing phase of a project. The intent is to document any useful lessons and learnings for improvements that can be utilized by future project teams.
Retrospectives come from the Scrum (agile) delivery methodology and are mostly conducted at the completion of an increment or ‘sprint’. They serve the purpose of asking a team to reflect on what went well, what did not go well, and what could be improved based on the completed increment.
Retrospectives aim to uncover improvements that can be acted on immediately, whereas lessons learned activities provide inputs for future improvements. Alternatively, if a project has ended prematurely (whether it was canceled before the scheduled end or was not completed successfully), a post-mortem may be done to determine what happened during the project.
Does a Project Retrospective Have to Be Done at the End of the Project?
No—a project retrospective can (and should) be done at any point during a project. If a significant milestone or phase has been completed, it may make logical sense to schedule a retrospective. Likewise, if something has gone wrong during a project, a retrospective can be done too. The important thing is that feedback is captured and that steps and actions are taken to make any necessary improvements.
What's Next?
Find out more about the agile principles that guide retrospectives, and the original Agile Manifesto that set out these principles, and join DPM membership to get access to conversations in Slack about agile (and more) with 100s of other digital project managers!