Project Manager Andrius Ramanauskas shares the key to actually learning from your lessons learned sessions.
“Knowledge without application is simply knowledge. Applying the knowledge to one’s life is wisdom — and that is the ultimate virtue” -Kasi Kaye Iliopoulos
If you have been involved in projects at some stage in your career, you must have been involved in – or at least heard about – the dreaded “lessons learned” session. This session is otherwise known as “witch hunt” season, where all the “wrong doers” are named and shamed, and their heads end up on spears (possibly more applicable to more ancient projects).
Well, it shouldn’t be. First and foremost, lessons learned in projects (operational work, life, etc.) are the key to continuous improvement of the organisation’s processes and a way to ensure successful project implementation in the future. Combine “lessons learned” with a no-blame culture within the organisation and you might just have yourself a combination that will succeed!
“If the team realises that the ‘lessons learned’ will be used against them (and will directly affect their KPIs), they are not going to invest their time and energy”
A no-blame culture in an organisation is crucial to the success of the meaningful “lessons learned”. If the team realises that the “lessons learned” will be used against them (and will directly affect their KPIs), they are not going to invest their time and energy; it becomes just another time-wasting meeting that everyone is dreading to attend.
Take away the implications of “lessons learned” by stripping it back to the simple art of learning lessons. It’s not rocket science. If you burn your finger by touching a hot plate, you most likely will not do it again. Lesson learned. If you tell your little brother and sister not to do it going forward, that is the organisational process change in the making. It’s that easy.
“When managing projects, document ‘lessons learned’ as they happen, as often as needed”
When managing projects, document “lessons learned” as they happen, as often as needed. Encourage the whole team to do the same, to ensure that it is not yet another document (and process) that only a Project Manager will use, close, archive and forget about after the project is complete.
Make it easy and convenient to use for everyone, so there are no excuses – “I couldn’t find the document”, etc. Do not leave it until the end of the project to document the “lessons learned”, as the majority of the useful information gleaned throughout the process will succumb to the ravages of time. “Lessons learned” captured early in the project, however, might just lead to a process change that will improve projects’ performance early on and save valuable time and money in the long run.
“‘Lessons learned’ captured early in the project might just lead to a process change that will improve projects’ performance early on and save valuable time and money in the long run”
For the Project Managers used to standard or waterfall project methodology, take a lesson from your brothering Agile teams (especially using SCRUM) who run and document lesson learned at each iteration or sprint (a sprint is 1 to 6 weeks), and incorporate teams’ feedback into the next iteration or sprint. Learn fast and often, do not be afraid to pivot if the initial plan is not working.
By now we understand that “lessons learned” does not have to be a time-wasting name and shame meeting. No-blame culture is vital and it’s not rocket science – your little brother and sister could do it! We don’t leave “lessons learned” until the end of the project; we document, assess and make small (or big) process improvements as we go. And most importantly, we share the learnings with the whole organisation, to ensure that the knowledge gained does not disappear with the closure and archival of the project.