A project retrospective is a short, structured meeting at the end of a project or work cycle where the team looks back at what went well, what did not, and what to change next time. It is the cheapest improvement habit a small business can adopt: an hour of honest conversation that stops the same problems repeating on every client job. This guide explains how to run a project retrospective step by step, which formats work for small teams, and how to make sure the lessons actually change how you work.

Who this guide is for

This guide is for small business owners, studio founders and team leads who finish projects and move straight on to the next one. If you keep saying “we should really talk about how that went” and never do, a simple project retrospective gives that conversation a regular slot and a clear output.

What a project retrospective is for

Atlassian’s Team Playbook entry on retrospectives frames the goal as working out what went well, where the team had problems, and which areas to improve. The emphasis is on the process and the system, not on blaming individuals. A good retrospective ends with a short list of specific changes, each with an owner.

Atlassian’s version is written for software sprints, but the same structure works for a website build, a brand refresh, a product launch or a busy month of client work.

Before the meeting

• Pick the right moment. Hold it soon after the project ends, while details are fresh, but not on the same day as a stressful launch.
• Invite the people who did the work. Include contractors if they were a big part of the project. Keep the group small enough for everyone to speak.
• Book enough time. Atlassian’s play suggests the meeting typically runs about an hour, with a short preparation step beforehand.
• Gather the facts. Bring the original brief, the timeline and any key numbers you track, such as hours spent or rounds of revisions, so the discussion is grounded in what happened.
• Share the agenda in advance. Send the questions a day early so quieter team members have time to think about their answers, and ask everyone to look back through their own notes, messages and timesheets for the project before they arrive.
• Choose a facilitator. In a small team this may be the founder, but rotating the role helps others feel ownership.

How to run a project retrospective in five steps

Atlassian’s play sets out five steps. Here they are adapted for a small business.

1. Set the tone

Open by reminding everyone that the purpose is to improve how the team works, not to find someone to blame. Atlassian highlights the importance of making it safe to speak honestly. A simple opening line helps: “We all did our best with what we knew at the time. Let’s work out how to make the next one easier.”

2. Gather feedback

Give everyone a few minutes to write down their thoughts before anyone speaks, so the loudest voice does not set the agenda. Atlassian lists several prompts teams use, including:

• The 4 Ls: what you loved, loathed, learned and longed for.
• Sad, mad, glad: a lighter way to surface feelings about the project.
• Went well, needs improvement: the simplest two-column version.

3. Turn feedback into insights

Group similar notes together and look for patterns rather than one-off incidents. “Client feedback came in late” appearing on four people’s notes is a pattern worth fixing. “The printer jammed once” probably is not.

4. Create action items

Choose a small number of changes, ideally one to three, and give each one an owner and a date. Atlassian recommends linking action items to the place where work is tracked, such as your project board, so they do not disappear into meeting notes.

5. Close the meeting

Thank everyone, read back the agreed actions, and confirm where they will be recorded. Finish on time.

A worked example: a website build for a client

A three-person studio finishes a five-page website for a local business. The project ran two weeks late. In the retrospective, notes cluster around three themes: content from the client arrived late, the homepage went through more revision rounds than planned, and nobody was sure who could approve small copy changes.

The team agrees three actions:

• Content deadline in the timeline: the founder adds a content due date to the project timeline template, with a note that the launch date moves if content arrives late. Owner: founder, by next Friday.
• Two included revision rounds: the designer updates the proposal template to state how many design rounds are included. Owner: designer.
• Approval rules: the account manager adds a short approvals table to the project brief so everyone knows who signs off what. Owner: account manager.

At the next project kickoff, the team checks that all three changes are in place before work starts.

Project retrospective questions you can copy

If the standard prompts feel stale, swap in a few of these. Pick three or four per session rather than all of them:

• What surprised us on this project, good or bad?
• Where did we wait the longest, and why?
• Which decision would we make differently if we started again tomorrow?
• What did the client or customer find hardest about working with us?
• Which part of our process did we skip, and did it matter?
• What did one person do that the rest of us should copy?
• Which tool helped, and which one got in the way?

Write each chosen question at the top of a column on a shared board or document, and let everyone add notes silently for a few minutes before the discussion starts. This keeps the conversation anchored to specific moments in the project rather than general impressions.

Tips for small teams

• Encourage every voice. Atlassian suggests techniques such as dot voting to find consensus on what matters most.
• Vary the format. Retrospectives get stale if the questions never change. Rotate prompts every few sessions.
• Offer anonymous input if people hesitate to speak openly, for example through a simple form before the meeting.
• Review last time’s actions first. Starting each retrospective by checking whether previous actions were completed builds trust that the meeting leads somewhere.
• Celebrate what worked. Repeating good practices is as valuable as fixing bad ones.

Common mistakes to avoid

• Turning it into a blame session. Keep the focus on the process, the brief and the tools.
• Listing ten actions. Too many changes means none of them happen. Pick the few that matter most.
• Actions without owners. “We should communicate better” is not an action. “Sam sets up a shared client feedback channel by Monday” is.
• Skipping it when things went well. Successful projects hold lessons too, and a short retrospective captures what to repeat.

Where retrospectives fit in your business systems

Retrospectives work best when their actions feed straight into your templates, checklists and standard operating procedures, so each project starts from a slightly better baseline than the last. Our business systems articles cover how to keep those documents current.

Key takeaways

A project retrospective is a focused hour where the team reviews what worked, what did not and what to change. Set a blame-free tone, collect written feedback before discussion, group it into patterns, and agree one to three actions with owners and dates that live on your project board. Review those actions at the next retrospective, vary the format to keep it fresh, and feed every lesson into the templates your next project will use.

Written by the Design Productive Editorial desk. Disclosure: this guide contains no affiliate or sponsored links.