“Read any good Lessons Learned Logs recently?” Said no-one, ever.
And the reason isn’t simply that they rival “Great Canals of Our Time” for some of the dullest text ever put to paper.
The Lessons Learned session has become a staple of project management: the essential end-of-project debrief and collective sigh. An opportunity to unburden yourself of the many and several irritations that you picked up on your way through the project. I’ve been in some sessions that might have been better titled “AND ANOTHER THING…!”
The point of a lessons learned session is to understand what went wrong or well on a given project so that future projects might avoid the same pitfalls and emulate the successes. So how come they sometimes dissolve into blame sessions or outright chaos? And how come, after years of lessons learned sessions, we’re still making the same old mistakes? To put it simply: why aren’t we learning any lessons?
I think it comes down to some basic problems with the way we’ve approached lessons over the years and I think there are some straightforward solutions. So here are my top five tips for really learning from your projects.
- Don’t play the Blame Game
Needless to say, lessons learned sessions are usually at their most demoralising when a project has gone horribly wrong. In some cases these sessions can end up being actively career-limiting, as blame is (often pointlessly) assigned to individuals who then must carry the can for all the project’s failures.
Let me be clear on three points here. First: a project is a piece of work that involves multiple people working towards a common aim. If something goes wrong, it is rarely the fault of an individual and usually the result of something more complex such as a lack of safeguards or immaturity of the project delivery environment. Second: with the exception of contractual obligations and disputes, there is rarely much that can be gained from attempting to apportion blame. More likely you will simply be adding to an already toxic delivery environment by signalling that failure will be punished. Finally: it is just not the interesting question to be asking. Even if someone is genuinely culpable; even if the blame for an issue can be laid squarely at one person’s door, that will not prevent the issue from recurring. Only when you look at how the process allowed an individual to fail do you start getting to the real learnings.
- Actions, not lessons
Which brings me to the next issue with these sessions – or, more accurately, what happens after these sessions. In a lot of organisations, either formally or informally, these lessons get summarised up – maybe put in a closure report – they are circulated and then added to The Great and Venerable Lessons Learned Log. This is done in the hope that the next PM running a similar project will come along at the start of their project and rather brilliantly be able to identify which of the things that happened to you will also happen to them. I feel very strongly that this is a terrible practice and must be stopped. This is not learning. This is hoping. And there are much better ways to improve project organisations.
If you come off a roundabout too fast and crash your car into a building, the investigating police officers don’t write down what happened in the hope that future motorists will read the incident report and moderate their driving accordingly. The road layout is reviewed, perhaps the signage is changed, or they might even consider whether a roundabout is the correct measure at all, as opposed to a set of lights.
If a plane crashes, the accident investigators write a report and then changes get made, and systems are in place not simply to stop the issue occurring again but to make it physically impossible for that same issue to cause another crash.
In project management, we tend to write the report and file it, but it’s an exceptionally mature organisation that keeps its processes under constant review based on the learnings of each newly delivered project. But! If you thoughtfully review the conditions that allowed issues to arise, then make changes to your process you will actively prevent them happening again. At which point, a lessons learned log is completely redundant.
- It’s not therapy
Lessons learned sessions frequently descend into a combination of mutual back-patting, comparing of war stories and therapy sessions that allow people to talk through their experiences on the project. All of these are excellent things to do and should be heartily encouraged. Just not in a lessons learned session. That’s not what it’s for. When the project is done, the project team will have committed months, if not years of their time to it and will have gone through emotional ups and downs. They might have experienced career-defining moments, seeded life-long friendships, or even undergone physical challenges to get to the end.
A project team’s shared experience is wonderful – it’s one of the best things about project life. Give your team a space to reflect, to discuss, to enjoy and to celebrate. Take them out for a meal, give them a day off, go climbing together, or bowling, or deep sea diving. It doesn’t matter. It is incredibly important to give your team a chance to celebrate the highs of the project and reflect on the lows.
Do that. And THEN have your lessons learned session. The lessons learned session should, as much as possible, be constructive, objective and low on emotion. Only when you have worked the highs and lows out of your system can you look at the project objectively and decide what could have been done better. Which takes me nicely to point 4.
- Impartial facilitation
It ought to be obvious, but please: stop having lessons learned sessions facilitated by the PM who ran the project (or a similarly invested party). Not only are you tipping the scales, you will reduce participation and run the risk of losing valuable feedback. If you are going to commit to learning lessons from your projects, have the sessions facilitated by someone who is a.) independent of the project and b.) trained and skilled in facilitating such sessions. There is an art to ensuring everyone in the room has a voice and if you are to do this properly it is essential that everyone feels that they will be heard.
- The same issues
As with all good things – I’ve saved the best until last. My final observation is that the vast majority of lessons are not lessons at all but predictable and preventable failures to get the basics right in the first place. When you assemble all the lessons in a log you will see clear and present themes, that come up time and again, irrespective of organisation or project-type. Roles and responsibilities poorly defined; sponsor insufficiently engaged; inaccurate reporting, no health-checks or otherwise weak governance; no clear objectives; lack of communications/stakeholder engagement. If any of these are sounding familiar, there’s a reason. They are all the underlying reasons that projects tend to go wrong. They are all the simple building blocks of project management which people, for various reasons, forget or overlook. They are all avoidable. They are all lessons that can be learnt.
Incidentally, and please forgive me for mentioning it, but… they are also the skills and techniques we train people to use. Every day. The best way to achieve project success is to get the basics right from the outset. It’s a lot cheaper than learning lessons.
So those are my top 5 tips for improving how we learn the lessons of our project successes and failures. Do you agree? How does your company approach lessons learned? Are they improving the way they deliver their projects as a result? I’d be really interested to hear your thoughts and experiences on ways to do lessons better. It’s important if we’re going to improve the world of projects.
Image by Rudy and Peter Skitterians from Pixabay
To receive these blogs, project management tips and video tutorials straight to your inbox click here to sign up to our newsletter.