After finishing a consulting project, my instinct is always to dive straight into the next one. There’s usually another client waiting, deadlines approaching, and the completed project feels like yesterday’s news. But over the years, I’ve learned that taking time to reflect on what just happened is one of the most valuable things I can do for my consulting practice. Here’s why I write a retrospective after every project.
The Lessons I Used to Lose
When I first started consulting, I’d finish a project and immediately move on. I thought I’d remember the important lessons, but I was wrong. Six months later, I’d find myself researching the same topics I’d handled past projects, or struggling with problems I’d already solved.
With clients, we were often deciding which date/time library to use or the reasons why we went with a particular framework, middleware solution or database system, making the same decisions and approaching similar problems. I realized I should be documenting our prior approaches so I could have a stronger foundation to build from just my fallible memory.
Building My Knowledge Base
Now keep notes and I write a retrospective after every project, and it’s transformed how I work. After documenting insights from quite a few engagements, I’ve built up a knowledge base that guides how I approach new work.
When a potential client describes their project, I can quickly identify patterns from past work. I know which technical approaches have served me well in similar situations, which client communication styles work best for different types of projects, and what warning signs to watch for.
This accumulated wisdom has continually aided me as I talk with clients. I can walk into new engagements with confidence because I’ve documented how I successfully handled similar challenges before.
What I Track
My retrospective format has evolved over time, but I’ve settled on five key areas that capture both the technical and relationship aspects of consulting work.
What went well? I get specific about successes worth repeating. Instead of writing “good communication,” I’ll note specific things unique to that client that made the engagement enjoyable and I should attempt to replicate.
What went poorly? I’m honest about what didn’t work, focusing on things I can control or influence. “The client changed requirements frequently” becomes “We should have structured more formal requirements review sessions upfront.”
Client collaboration & communication. Which communication channels worked best? When did misunderstandings occur? How did different stakeholders prefer to receive updates? These insights often matter more than technical decisions in terms of how successful the engagement is.
Technology decisions. I document both what we chose and what we considered but rejected. Future me will thank present me for remembering why we picked Angular over React for a particular project, or why we decided against microservices for a specific client.
Lessons learned & future recommendations. This is where I note how I can improve things. What will I do differently next time? What processes should we implement earlier? What should be settled early rather than coming up and causing issues later?
The Compound Effect
The real magic happens after you’ve documented several projects. Patterns emerge that you wouldn’t notice from any single engagement. I started seeing common patterns for handling similar situations.
These patterns now inform how I approach new clients, scope projects, and structure engagements. I can avoid common pitfalls because I’ve seen them before and documented what happened.
How It’s Changed My Practice
Consistent retrospectives have made me a better consultant in ways I didn’t expect. I’m more confident in client conversations because I can reference specific examples of how I’ve handled similar situations. I waste less time repeating past mistakes. I can more quickly and confidently recommend architectures and technologies because I’ve compared them before.
Clients notice the difference, too. When I can confidently say “based on similar projects, here’s what typically works well in this situation,” it demonstrates experience and professionalism that clients value.
Starting the Habit
If you’re not doing project retrospectives yet, start simple. I began with just a few bullet points after each project. Over time, I refined my format and made it more thorough, but the important thing was starting to keep track of the things I knew I’d forget.
I take notes when important decisions are made or issues arise and then summarize them immediately after project completion, while the details are still fresh. The time you spend keeping track of what you learned will more than make up for it when you don’t have to hunt down the same resources you used to navigate issues the first time.