When you’re tasked with project management and you’re managing a project, once a project is over – there are no tasks left to complete, the work is signed off, the client is happy – it’s tempting to get busy and just start in on the next project.
The likelihood is that your team already has one project on the go, if not two or three.
But you know what, even if you’re using a linear Waterfall approach to project management, it’s a much better idea for everyone to pause to mark the end of a project and review what happened.
Then you can ask yourself and your team: what did we learn?
All too often, teams just crash from one project to the next without learning anything. And if you don’t learn anything, people will perform in the same way, you’ll encounter the same frustrations, and you’ll get the same results.
Even if the results are great, you could be missing an opportunity to make them even better.
End of Project Wash Up
Reflection and review at the end of a project is an idea borrowed from the Agile method of project management. Agile does reviews very well and recommends two separate and very different kinds of reflection.
The aim of the review or wash-up meeting is to look at things such as what did we achieve? Did we do all the things we said we’d do? What’s still in the pipeline? What have we learned that we need to respond to?
It is very task orientated. It’s about what you did, how much progress you made against your plan and how good it was from a technical perspective.
In the agile approach, this is done before you decide what you’re going to do in the next sprint, because it’s a key tool for deciding what you need to do next.
Retrospectives make a team great
The end-of-sprint wash-up includes what you did, by contrast a retrospective is about how you did it. This separation of retrospectives from end-of-sprint reviews is interesting.
Separating out the work from how you did the work in this way is important.
Say what you like about techies – and Agile was originally designed for tech projects – at the end of a project they actually make a huge effort to talk about their experience of working together. They talk about how they communicate. They talk about how they felt, about their interactions, the whole dynamic of the team. They give each other feedback.
It’s very powerful. And useful for project management.
Talking about these things isn’t necessarily easy, but there’s much learning to be had from doing it and it’s a great way to build continuous improvement into your organisation.
We encourage our clients to do them even if it’s not a tech project, because great teams are born from it.
“what makes great teams are the ones who are confident enough to talk about this stuff.”
Retrospectives force you to pause, talk about what could be better, think about ways that you can improve and then apply that to the work going forward.
Then you’re building a culture where feedback happens, where learning happens, where you are iterating processes. It’s intelligent, it’s wise. It’s built in.
How to do a retrospective
Here’s how we structure retrospectives:
-
- Start with a check-in to set the tone
- Clarify the purpose of the meeting
- Explain the process – we suggest using a simple matrix with four questions (see below for more formats you could use):
• What went well?
• What could have been better?
• What questions have you got about it?
• What recommendations would you make for us to take forward, or practical steps?
- Everybody writes their answers to these questions on sticky notes.
- Put the sticky notes up on a whiteboard or a wall – using quadrants for each question – and gather round them (or use an online whiteboarding tool like Miro or Mural).
- Do a sorting exercise – look at the clusters and review what it means together. For example, does everyone agree on what went well? If someone says something didn’t go so well, when everyone else thought it did, have a conversation about it.
- Go through each quadrant in the matrix, have the necessary conversations and answer any questions that people have.
- Move on to recommendations: what concrete proposals could you implement to try and ease problems that came up?
- And perhaps within this, there might be subcategories: What about relationship dynamics? Was anything edgy? Was anything particularly good?
Depending on the scenario you might choose to find ways of anonymising this feedback using a whiteboard tool, a form or a survey before the session. Then bringing it out in the meeting.
What could go wrong?
There are so many benefits to introducing retrospectives to your team. However people often have concerns and might avoid trying them because of a fear they’ll feel awkward or it’ll go wrong.
There are probably two worst case scenarios here, and both have silver linings:
1. If people are reticent, don’t contribute much, or stick to safe subjects.
Acknowledge it and suggest that it’s limiting your progress.
Then ask what ideas people have for how you could do things differently next time. So rather than forcing the issue, you can all get involved in how you might be more comfortable with it in future.
If I was leading that group, I might do some homework and check-in with people afterwards to try to find out why it was weird in that session.
2. What if someone gets angry, or upset or has another extreme response?
If this happens you could try…
i. Pause
ii. Ask everyone to write down how they’re feeling in the moment, why they’re feeling that, and what triggered it.
iii. Invite all to agree to listen.
iv. Go round and ask everyone to say what is going on for them using an I statement (so it doesn’t get into blame or attacks.)
v. Then you could explore what questions people have about the different perspectives.
vi. Ask people for proposals for what to do next.
vii. Commit to some of these.
This process might derail the retrospective but it could be an essential diversion, as you’ll end up dealing with an elephant in the room or dissolving a tension that might otherwise block everyone.
As a result you’ll have helped to build trust in the group, and you can always come back to the original conversation at a later date.
It’s worth saying that retrospectives might not be brilliant the first time you do them. They get better with practice. And of course, the more you practice them, other things get better too. It doesn’t mean that difficult things get easy, but at least you’ll have created a forum for raising issues and dealing with them.
Plus it makes it easier to give feedback generally because it normalises it, and that’s helpful in one-to-one situations too.
Other ways to do a retrospective
As well as “What went well, what could have been better” there are dozens of other ideas and formats – try googling retrospective frameworks. These are our favourites:
1. Start, Stop, Continue
Focus the team on processes, and form new team habits by defining what to start, stop and continue doing.
2. Make the Boat Go Faster
Define the vision for the team and identify any problems along the way.
3. The 4L’s: Liked, Learned, Loathed, Longed For
Look at the current situation from a factual perspective.
It’s good to try different structures, or mix them up. Some people find some of the questions harder than others.
What’s important
It works best if you allow a good chunk of time to do it – say a whole morning or afternoon, just spending half an hour on a review meeting won’t dig up the gold.
You don’t necessarily need to use a structured approach to do a retrospective. It’s not disastrous if you don’t use a tool nor follow a predefined format. Those are available to make it easier to have the conversation, to allow you to approach it with some sense of security and safety. This makes it easier for your team to be honest and open.
What’s important is that it’s not about blaming. It’s about learning and talking about whether you need to change anything to make things better, if at all.
Other Top Tips
What to do when you’re all remote
There are several good tools for running retrospectives online. Try Miro, Mural or Retrium. Doing it online is a different experience to doing it in the real world. But in some ways it’s better too.
Make sure someone owns the process
It’s really helpful if someone owns the process. Make a commitment as a group that you are going to do this, and then have somebody be responsible for making it happen. That might be the project manager, the product owner or an external facilitator.
The size of your team doesn’t matter
The bigger your team, the more important it is to do a structured review, though it’s still relevant even with tiny teams. There’s a cliche about small teams: two people work well together, three people is tight but you can handle it. But with four people work starts to fray: you suddenly find the dynamic of four is such that it’s hard to keep everyone aligned and clear without someone feeling like they’re being taken for granted, or being left out of the loop.
So once you start getting bigger than three people, you will find it much easier if you have an agreed structure, stick to it. And if it doesn’t flow, use a tool, learning and iterating as you go.
Think about power dynamics
The boss almost always has the most to say in a review but it’s best if they don’t always run the meeting otherwise they’ll dominate. Instead rotate it amongst the team.
In addition, you want feedback and input from the people that have been most involved in doing the work so you don’t necessarily want the big boss or the sponsor of the project at the review meeting. Have a separate conversation with them. Would you want to talk about all the things that you messed up in front of the boss? You may not. You just want the boss to be pleased that you got it out the door, she doesn’t need to know the rest of it. But the team needs to know. So keep it casual to get honest feedback.
Here’s some examples
At Then Somehow we often operate in very small teams to produce things quickly. When we do reviews, they’re incredibly useful. For example when we were building the first version of AdviceSheet – there were three of us in that team – to stop progress getting stuck it was important that we talked to express the frustration of our different working styles.
For another project last year where we piloted webinars for a large organisation, there were five of us on the team, plus two or three people on the client side. It was really important we had wash-up meetings at the end of each pilot phase. Because the client was there and we had a good relationship, we were able to say things such as: “you guys are incredibly slow at feeding back,” which they acknowledged and accepted.
Because we spoke about it, we were able to come up with actions to improve the process:
- we included the client in the project update emails
- we warned the client when we were going to send them something that we needed a quick response to, in order to avoid bottlenecks.
That was enough to make a big difference.
Your projects will benefit
End of project reviews are a way of bringing learning behaviour into your organisation or a team. It’ll benefit your projects and you can also use them as a way to talk about things that really matter. You’ll build trust, you’ll enable healthy conflict, and you’ll be able to acknowledge the good stuff and the bad stuff. They’re also an opportunity to praise people and thank them.
Then you can move on and do better work together.
If you’re struggling with projects and project management, and need some help, get in touch. At Then Somehow, we have tools and programmes that can help. Get in touch here.