How to Effectively Capture Lessons Learned Using Storytelling
Of all the project management best practices that PMOs attempt to implement, the one practice that rarely seems to be done well in any organization is lessons learned. While seemingly simple (document what went right, what went wrong, what were the learning’s and what should be improved), there always seems to be disconnect between the lessons learned program and day-to-day project activities.
Why Organizations have a Problem with Lessons Learned
According to PMI studies, while there is tangible proof of the business benefits associated with having a robust lessons learned database, most lessons learned programs lack effectiveness in making any positive change. This ineffectiveness in turn makes it difficult to justify the very effort of creating a lessons learned database in the first place.
At CornerThought, we sought to find out why organizations weren’t getting the most out of lessons learned. In our research, the pain points of lessons learned always revolved around the following:
“Lessons learned are done at the end of the project when everyone has forgotten what actually happened”
“It’s too time consuming to conduct a proper lessons learned workshop. We’re too busy thinking about the next project”
“The bigger the lessons learned database, the harder it is to find information relevant to the work I’m currently doing”
“People don’t really look at the database until an issue has already come up. By that point, it’s too late”
“Since nobody looks at the database, nothing really changes”
In this blog post, I’ll cover the first 2 points, as they relate to capturing lessons learned.
Getting Started Using Your Issue Log
First let's look at the traditional method of capturing lessons learned: the After-Action Review Workshop. This practice seems antiquated in our day and age where information is reported and consumed in real time. Why wait until the end of a project to review the issues and successes? The team already knows what’s going right and what’s going wrong, so wouldn't it make sense that they start defining the learning’s while the knowledge is fresh?
The biggest objection to frequent project reviews is the time commitment. If conducting lessons learned workshops at the end of a project is considered unnecessarily time-consuming, it would be impossible to justify conducting them during the project. However, if you’re managing your projects properly, you’re probably already doing half the work in defining your project lessons learned.
Most project teams have some form of daily or weekly review meetings. During these meetings the team discuss project progress, and what happened since the last meeting that affected that progress (i.e. the issues and successes). These issues and successes should be going into a log, sorted by what aspect of the project they affected (i.e. project tasks or functions), as well as how they impacted the project KPIs. There should also be some sort of tracking of any actions needed to resolve the issues. If your team already has a log of this nature, congratulations, you’re already half way towards building your lessons learned database.
Using Storytelling to Construct Your Lessons Learned
Taking the issues/successes defined in your project log, you can start to build stories which will help create compelling lessons learned that future project teams will want to read.
As with any story, the beginning starts with an initial event. This event is something positive or negative, which sets the characters on a journey to complete a goal. Along the way, they gain insights about what caused the event to happen in the first place. Finally, after the event is resolved, the characters come out with some sort of moral of the story.
For your project lessons learned, the issues and successes in your log represent the initial events of the story, and the actions represent the goals the characters are striving to complete. The greater the impact these issues and successes had on your project KPIs, the more important the story, and ultimately the lesson learned. As your team begin resolving the issues, or discussing the successes of the project, they should be gaining insights into the root causes (i.e. why the event occurred). Have them document these root causes, preferably in the same place that the issues and successes are logged. Putting the causes next to the issues/successes helps the team determine the actions needed to solve the issue or enable the success.
Finally, define the moral of the story, or the future project considerations. These future considerations should be phrased in a way to let the reader understand what they should consider when dealing with similar situations, on similar tasks, for similar projects. More specifically, future project considerations should address how to prevent/enable the causes or mitigate/drive the impacts of issues/successes.
Following this method, your lessons learned should be structured as follows:
Issue/Success
Impact on Project KPIs
Causes
Actions Completed
Future Project Considerations
Of course, there's still the issue of time. How do teams fit the time in to define all these aspects of a lesson learned. As mentioned earlier, parts 1,2 and 4 of the lessons learned should be recorded on a regular basis in a project log to ensure the project is on track. As well, regularly documenting root causes in the log as they are discovered will allow you to capture much of the information you need in real time. However, to properly capture the future project considerations, extend one of your daily or weekly meetings once a month by a few hours to focus on the most impactful issues/successes. Define in detail the future project considerations based on the causes and the actions completed. Those few extra hours a month to properly capture the team's experience in a compelling story format will pay off tremendously in the long run.
Why Storytelling for Lessons Learned?
Using storytelling to define your lessons learned takes advantage of the natural way humans pass experiential knowledge. By using storytelling, the learner can follow and relate to the journey that the past team went through and what they ultimately learned along the way.
Click here to learn about CornerThought's smart lessons learned database, which ensures your team is always informed of the lessons learned most relevant to their projects and tasks.
