Whether you choose to call it a retrospective, post-mortem, project review, or lessons-learned, the idea that we need to look back on past actions and judge them in hindsight is a popular concept that exists in the dozens of project management methodologies that are in use today. Loren Walker, wrote a paper for the PMI Global Congress, that states lessons-learned discussions are one of the "most important 'value-added' aspects of a project". But the article also states that they're the most ignored. Odd. If it's so necessary, why is it so easily overlooked?
Lessons-learned are probably the greatest failure in project management. Let me explain: in a previous post, we discussed how a project completed on time, on budget. and within scope is a failure unless it provides some kind of value. Project managers stopped conducting lessons-learned discussions because we project managed the heck out them: they were on time, on scope, and on budget — but they didn't provide any value!
We need to let go of the guides, standards, and methods for running these meetings and instead, craft a process that will create something valuable that will set us on the path to continuous improvement.
A little of this, a little of that...
In my experience, retrospectives, project reviews and lessons-learned all miss the mark on some level, but they also have a lot of strong points. In order to make this kind of exercise more valuable, I think we need to combine a few key aspects of each one of them (and drop another few):
Don't wait until the end of the project
These meetings should happen all throughout the project's lifecycle as well as at the end of the project. In cooking, there's a basic rule that is ingrained in young chefs: taste as you go! Once your dish is complete, you can't un-salt or un-spice a dish. It's over. We can draw the same parallel to project management: a successful project is about creating repeatable processes and optimizing them over the course of the project. That can only be done if you take the time to stop once in a while, gather data, ask questions and adjust. Once it's over, it's over. In addition, by the end of a project most people can't even remember what went right or wrong unless it was a major source of frustration, so your feedback will be biased and incomplete.
Expand your learning scope
You can gain some valuable insight from so many resources outside of running meetings with your team. Whether you're approaching distant players like stakeholders or clients, external sources that work in proximity to the team or work supporting roles and even similar projects done by other firms, these additional perspectives can offer eye-opening feedback.
Think of it this way: everyone has a different palate and different food preferences. If you want good feedback about your roasted sweet potatoes and ask a bunch of people who don't like sweet potatoes, there won't be much you can do improve your recipe. Finally, don't be afraid to turn informal conversations into valuable lessons-learned opportunities. You don't need to isolate feedback to these meetings, all you need to do is ask the right questions.
Highlight the positives
One of the biggest mistakes we fall into as human beings is that we tend to focus on what went wrong instead of what went right. Too many times, retrospectives or lessons-learned turn into finger-pointing blame games that do more harm than good. Not only that, but the sessions can turn into opportunities to vent where no solution or constructive idea for improvement is provided. The key to these meetings is balance: a good mix of sweet, salty, bitter and sour. Every negative should be balanced out with a positive, and meeting attendees should leave feeling as though their frustrations were heard and improvements will be implemented.
It's too easy to say that the team has "communication problems". Every team has "communication problems". It's like saying this food doesn't tasted good. That's great, but what exactly makes it bad? Is it too salty? Did you break a tooth on it? Is your mouth on fire? Identifying issues in a general category is only the starting point of the diagnosis. Use this information to dig a little deeper and find the root cause for which you can actually suggest a solution. Perhaps the team members don't all use the same chat system or perhaps there's too little documentation. Once you get to the root of the problem, a solution is much easier to find and has a better chance of being implement. Which brings us to the final point...
Now, implement it!
Let's pretend running a retrospective meeting is like making cookie batter and the couple dozen post-its suggesting improvements up on the white board are the chocolate chips. Now imagine grabbing all of those chocolate chips and... throwing them in the garbage. Your cookie will taste OK but not great, and you probably wasted a couple of bucks.
See the parallel? If you don't bake those improvements into the process, your project not completely derail. Sure, you wasted a couple of salary dollars, but it's not a massive amount of money, considering. And so we mosy on with our day.
Here's where I see the core of why we no longer conduct lessons-learned: we throw out the chocolate chips! They're the best part!
Like I said at the start of this blog, we need to use this information to create value and we need to do this by optimizing our processes. Unfortunately, we tend to focus so much on making sure we're on time, on scope, and on budget that we forget our primary responsibility: driving processes, improving them, engaging people to solve issues and continuously improving based on lessons learned and new ideas. That's whey at Pie, we built visual project management tool the way we did: we love those chocolate chips! Now it's time for you to find yours and add them to your recipe. And while you're at it, you could add walnuts and bananas, too.
Written by Isabelle Blondin
Photo by Clem Onojeghuo