Sign up to the Decent Group newsletter.
Get monthly insights about how software can improve your business performance.
Subscribe now
Ever since Decent Group has existed, we have always wanted to keep getting better at what we do. And we have got better at it. In fact, as time has passed we have got better at getting better. We use a number of techniques to ensure that if there’s a lesson to learn, we learn it – we don’t just let it drift away. One of these techniques is the post-project review.
They say that the definition of madness is doing the same thing and expecting a different result. Yet that’s how most organisations operate, most of the time. If a project didn’t go well then usually you just move on and put the problems down to some random combination of circumstances.
But it’s when things don’t go well that you can learn the most.
Spending time reflecting on what didn’t go well is strangely powerful. It’s also important to reflect on what did work well in order to embed that success in future projects. But the difficulties, the bottlenecks, the crises are the gold dust. They bring to the surface the fact that something is missing or that a weakness exists. Fixing the problem yields potent gains.
Here’s how we use the post-project review to achieve those gains.
Our post-project reviews are face-to-face meetings between the project’s client manager and the developers who worked on it, chaired by our Head of Technical and Operations, Jason Furnell. This is the structure we follow:
The way we approach the review contains some important lessons – ones we have learnt along the way. First, the meeting’s chair should be a neutral observer. Jason won’t have worked directly on the project, because he is neither part of our client services team nor is he a software developer himself. Because he doesn’t have a dog in the race, he can view things impartially. What’s more, Jason is, as our director James Ducker puts it, ‘the fairest person I know’. The post-project review works best if the meeting is run by someone with no agenda beyond learning the most important lessons.
Second, we use storytelling to unpack the learnings. Jason will simply ask: ‘Tell me what happened,’ and the story will be told from the start. As people tell a story, they naturally highlight the moments of greatest tension, difficulty and revelation. These moments are usually where the most important learnings lie.
We learn different kinds of lessons. One key type is the client-specific lesson that help us to work better with them in future. This matters, as we typically have long-term relationships with our clients.
For example, a particular client’s users might need to be given plenty of time to test new tools rather than being asked to feed back within 48 hours. Or, the client might like to receive an explanatory video that offers guidance on using new tools, rather than an open-ended Teams call in which they can ask all the questions they want. If a client has an IT support company who we need to set up important IT infrastructure, we might need to give them notice long in advance of delivery. Once we learn these things about a specific client, we can work better with them in future.
Another key type is a general lesson. Years ago, we tended to deliver many changes to a system all at once. It seemed more efficient, after all. But the impact was confusion, lots of fighting fires, long hours worked each day and a general sense of crisis. We learnt to make changes to a company’s software system in small chunks, so the changes can be rolled out in non-disruptive ways. This is a great example of how you learn most when things go wrong.
A third key type is the internal lesson – something specific about Decent Group and our resources. For example, if a new kind of specialist development technique is needed on a project, we add this to our skills matrix – a list of around 150 development techniques against which we assess all our developers to ensure we have an even spread of skills with plenty of overlap across the team.
When things go well we also learn and improve. If we’ve used a new approach as part of the development work and it worked successfully, we will remember the approach and recommend it to the wider team. In these cases we take the learning from the post-project review and into the monthly developers’ meeting for wider debate and discussion. Likewise, if there’s a lesson that’s relevant to the client managers, it gets taken to their monthly meetings.
The result is that everyone is learning throughout the organisation. If one person discovers something, good or bad, when working on a project, the post-project review multiplies the impact of that discovery across the wider team. Individuals across the wider team then apply the discovery in their own work, and very often it generates a further discovery or breakthrough.
This becomes a vital part of the company culture: we have developed a learner mindset in which everyone participates. This makes life at Decent Group more interesting. But above all it means we remain flexible, open-minded and outward-looking as an organisation. It means we keep getting better. And that’s an inspiring thing to be part of.
It all starts with the post-project review. The time we spend forces us to remember, to extract the negative events from out of the past (where we’d often prefer to leave them), to tell the story of what happened, and to articulate the lessons learnt. This is all part of the service we provide our clients, building stronger partnerships and delivering better results for them.
No post-project review is ever wasted. We recommend them to every organisation.
Fill in your details and give us an idea of what you’d like to talk to us about, and we will contact you shortly.