Lessons Learned and Risk Management
| I was recently asked “…what is the difference between ‘lessons learned’ and a ‘risk register’ other than when they are accomplished?” The conversation is still in progress, and I hope to continue it, but as I was responding I realized that I should probably post a follow up to my article “Lessons Learned from Lessons Learned” (https://www.projectmanagement.com/blog-post/73046/lessons-learned-from-lessons-learned) discussing the connection between lessons learned and risk management. I’m not going to rehash my approach to lessons learned here – you can follow the link for that – but the checklist created and maintained through the process can have direct ties to risk management on future projects. It’s entirely possible for something identified during lessons learned on one project to present itself as a risk on a future project. Here are some real examples:
The risks that make it onto the lessons learned checklist should go through risk analysis for each project where they are relevant; the probability and impact may not be the same on each one. Some ongoing risks may get absorbed into Business as Usual (BAU). They’re not ignored, it just becomes accepted that it’s likely they’ll have to be dealt with, so they’re included in the plan without being part of that project’s risk analysis. I don’t have a good average for how long a risk will stay on the lessons learned checklist. This would be either until it is no longer considered a risk or until it becomes part of BAU. To be clear, this doesn’t change how you manage risks, it just creates a new channel for risk identification. It might even make it easier if you’re one of the few people who reviews old risk registers from past projects to identify risks that may affect future projects. If you find this helpful and have additional insights, or have a better approach, drop a note in the comments. Feedback is always welcome. |
Lessons Learned from Lessons Learned
| 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:
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:
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:
Putting this into action:
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? |
