What went well? What can be improved upon? What issues did you encounter? What should we start doing? What should we stop doing? Who should be recognized for outstanding performance?
Who cares?
As project managers, we ALL should care. A more important question is “What can we learn from the traditional approach to lessons learned?” Let’s start with establishing a common understanding of the lessons learned process.
The approach I learned, twenty or so years ago, goes something like this:
- After a project has closed, not too soon after because of maintenance mode and not too long after or people start to forget details, you get everyone who had a role in the project together in a conference room and ask a few basic questions (see above).
- You take notes on all the responses and spend a couple of hours turning your notes into something cohesive and figuring out how to remove some of the negative emotion and fingerpointing (if there was any).
- You send out your notes, never knowing if anybody read them. Any action that was needed was decided during the meeting and the action was initiated before your notes got sent out.
- You publish your notes to the lessons learned repository, never knowing if anybody will read them.
- In time, your notes get forgotten. Nobody wants to go through multiple years of lessons learned documents. If you’re “lucky” enough to have a lessons learned repository with search capabilities, much like Google, most people aren’t going to review more than the first few results.
Sound familiar? I’m pretty sure it hasn’t changed much in over twenty years, for many people. Some of you might do things a little differently. My experience, limited as it is to anecdotal information from a couple handfuls of people in two PMI chapters and answers to questions on gantthead.com (yes, I’ve been here that long) and ProjectManagement.com, is that the biggest consistent difference is the questions that get asked.
I’m willing to be wrong, but I’m also comfortable in my opinion because lessons learned aren’t a sexy enough topic for people to spend a lot of time or money on improving the process. Who can name a popular and widely used standalone software package for managing lessons learned documents?
A few years ago, I was hired at a new job. Part of what I was hired to do was to help stand up a new PMO. As part of the overall overhaul of our processes, I looked at the lessons learned process through the lens of a lessons learned meeting:
- What is/can be effective? Getting feedback from the team. Identifying issues and areas to improve.
- What can be improved upon? Identifying and using relevant lessons learned.
- What issues do you encounter? Lack of participation. Blame game. Forgotten details.
- What should we start doing? Hold lessons learned multiple times throughout a project. Capture actionable data. Move away from blame toward learning.
- What should we stop doing? Dumping documents in a repository and never looking at them again.
- What should we continue doing? Refining/improving the lessons learned process, finding the right balance between adapting the process to company culture and changing company culture to be a learning culture.
I realize this list is a little on the simple side, but one of the lessons I learned is that there is a lot of data from lessons learned meetings that is specific to the project and relevant to little else. If your project is going to be audited in the future, keep the data for as long as you need it, then get rid of it. For a set amount of time, you might need to know who made what decisions, when, why, and how people felt about it, but the relevance and usefulness of that information has an expiration date. It can be good to know why something broke, but once fixes are in place and processes are updated to prevent the problem in the future, is anybody going to look for that information in your lessons learned documentation?
What do I recommend? I recommend running lessons learned more than once during a project. If you have a phase gate approach, make it part of the phase gate. Or you could hold them once a month. Find the cadence that makes sense for the project. You might not need a lessons learned meeting every other week on a two month project. Maybe it’s not always a formal meeting, but it’s part of the discussions that take place. It’s what you do with the data you capture that really matters.
There is often someone with some sort of requirement for capturing historical data. Meet their needs, and then focus on actionable data. I break actionable data down into the following categories:
- immediate action is needed
- action that should be considered in later phases/cycles of the current project
- action that may need taken in other active projects or in normal business operations
- action that may be needed in a future project
Putting this into action:
- Item 1 triggers varying responses - meetings, emails, phone calls, changes... depending on the action needed.
- Item 2 can result in changes to the project plan, with the appropriate approvals and subsequent notifications.
- Item 3 triggers notifications to the appropriate project managers/sponsors (or notifications to the appropriate person in the business) so that they can determine the appropriate course of action.
- Item 4 goes on a checklist, split into process groups or phases, that is actively monitored and updated.
Using Item 4 as an example, I'll review the checklist when I'm beginning to plan a project, and throughout the course of the project to check for changes that may affect my project. I have a curated list of items to consider, instead of hundreds of documents that never get looked at again (true story).
The checklist is reviewed, regularly, to determine if any items should be removed because they no longer apply. If it grows into a multi-page document with a lot of content that is no longer relevant, it becomes worthless. I've tried to keep mine down to under 1 page; it's never exceeded 1 1/2 pages. Since it's broken into sections (phases for “traditional” projects), you don't have to go through the whole thing all at once to make sure everything is checked off, but it is helpful when planning future phases.
That’s the basics. I’m actively refining the process and don’t plan on having the “perfect process that never needs to change.” What works (or doesn’t) in your lessons learned process?
