Play Now:

For your Project Management Professional (PMP)® Exam

Elizabeth Harrin, FAPM

There is no doubt in my mind that you have heard the term lessons learned before.

It is mentioned extensively throughout A Guide to the Project Management Body of Knowledge, (PMBOK® Guide), I teach it as part of my PMP training lessons and my favorite search engine gives me over 51,000 results for the search term “lessons learned in project management”. In fact, as an experienced project manager you have probably participated or even chaired one or two lessons learned meetings yourself on your own projects.

But let’s consider the bigger picture around lessons learned. What process do we follow? What management techniques are there for lessons learned? Are all documented lessons learned equally valuable?

These questions need answers. And so I’m happy to welcome Elizabeth Harrin (rebelsguidetopm.com -- www.linkedin.com/in/elizabethharrin/ - ) who has the answers for us!

Episode Transcript

Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.

Podcast Introduction

Cornelius Fichtner:   Hello and welcome to Episode # 397. This is the Project Management Podcast™ at www.pm-podcast.com and I am Cornelius Fichtner. There is no doubt in my mind that you have heard the term “Lessons Learned” before. It is mentioned extensively throughout the PMBOK Guide. I teach it as part of my PMP Training Lessons and my favorite search engine gives me over 51,000 results for the search term, “Lessons Learned in Project Management”. In fact, as an experienced project manager, you have probably participated or even chaired one or two lessons learned meeting yourself on your own projects. If you are preparing for your PMP Exam, then the best way to calm the butterflies in your stomach is to take a Practice Exam. Our PMP Exam Simulator offers you nine such exams. To see how it works and take a free test drive, please go to www.freeexamsimulator.com . But let’s consider the bigger picture around lessons learned here. What processes do we follow? What management techniques are there for lessons learned? And are all documented lessons learned equally valuable? These questions need answers and so I’m happy to welcome Elizabeth Harrin who has the answers for us. And now, please pay attention. We’ll be doing a Lessons Learned at the end. Enjoy the interview.

Female Voice:   Project Management Podcast™ Feature Interview.  Today with Elizabeth Harrin, author, blogger and speaker.

Cornelius Fichtner:   Hello, Elizabeth.

Elizabeth Harrin:   Hello, Cornelius.  I’ll certainly do my best.

Cornelius:   [laughs] Oh well, let’s find out because we’re going to be defining our topic first. From your perspective, what are lessons learned?

Elizabeth:   They are the bits of organizational knowledge that we pick up as we go through our projects and you’ll typically find them split into things that went well—so all the things that we patted ourselves on the back about— “Yes, we did a great job on that!”—and then the things that didn’t go so well where we have issues and things. The main thing I would say when we’re defining “lessons learned” is that we need to make the distinction between “lessons captured” and “lessons learned” because often on projects and I know we’re going to talk more about the process of capturing output at the end of the project and later on in our discussion today, we often write things down and capture them without actually learning or doing anything with them. So, I suppose the key point for me as we’re starting this discussion is to think we really need to make sure that whatever comes out of our –whatever organizational knowledge we learn as we go, we actually do something with it and it becomes learned. 

Cornelius:   And what do we mean by “management techniques” for lessons learned?

Elizabeth:   Management techniques are just effective ways of working and lessons learned are very important for our projects because they let us do things better. Management techniques help us get facts and results which is delivering better outcomes and learning and improving on how we run our projects in our companies. So, there are things like how we can capture, record, analyze and use lessons learned for continuous improvement. Generally, the management techniques that we can use fall into three categories: things that relate to people, so staffing, training and that kind of stuff; techniques that relate to processes so that might be the templates or the agenda that you use for your lessons learned sessions and then tools and technology which might be how you then store and recover those lessons learned once you’ve done—finished capturing them.

Cornelius:   And before we do anything else right now, you’ve already put a big elephant into the room here. So, let’s look at that elephant. How do we avoid that our captured, documented, lessons learned are simply filed away and never looked at again so they become documented lessons but they don’t become lessons learned? What do we need to do to actually learn something?

Elizabeth:   I think the organizational co-chair has a huge part to play here because you need to create a culture of continuous improvement where people want to seek help. What was learned from other initiatives so they don’t make the same mistakes? And if you need to talk to –if you don’t think that exists in your organization and you’re talking to people about it, it’s a good idea to frame it in a way of making sure you want to learn lessons because it may seem faster and cheaper. But you’re not reinventing the wheel every time and you’re not making the same mistakes but somebody made our project two years ago but to answer your question, I think we struggled because it’s hard, and if we don’t have enough time and at the end of the project, you’re normally rushing to wrap up the last few things and then move straight into the next thing. So, it’s partly to do with facts and partly to do with just not enough general call for understanding of the cost of reinventing the wheel because it’s quite hard to manage and measure the impact on productivity. It’s quite hard to sell the benefits, if you like, of putting the effort in to getting a good strong culture of lessons learned because it’s quite hard to quantify what the benefit is. I think it all just boils down to a lack of understanding of those benefits. Am I allowed to say that it’s because of the fact that people are lazy?

Cornelius:   [laughs] 

Elizabeth:   [laughs] Maybe we should say they are under a lot of pressure to move on to the next thing and it’s not the most glamorous or exciting area of Project Management, is it?

Cornelius:   Yeah. I have to admit in many of my projects, when the end came, lessons learned was just not something that was on anyone’s mind. What was on their mind was: “Ahh, there’s a new project over there. Bye!” 

Elizabeth:   “I’ve waited for this for months and months I just wanted to give up now. I’m done.”   

Cornelius:   There you go. Yeah. We, project managers, we’re always fond of processes, procedures, is there a particular lessons learned process to be followed?

Elizabeth:   Yes, I think there is.  A generally accepted process for projects is that you will collect the lessons, then you’ll apply some kind of prioritization or validation to them and then store them somewhere while making them available to other teams. And then the final step in the process is that you re-use them so that’s where the learning part comes in.

Cornelius:   Or, if we talk reality, the final step is you forget about them. 

Elizabeth:   Yes, you’re following the drill. But if you don’t use them, then what’s the point of gathering them? The idea there is that they should feed into continuous improvement. And while doing some of the bigger improvements it might be a lot of effort and might put people off. There’s normally one or two small things that come out of a project that you can easily change for the next project to make it better.

Cornelius:   We also have to talk about the difference in how lessons learned are managed and approached on a traditional, multiple-based project versus the Agile world and how they do their lessons learned which they call retrospective meeting. Can you tell us what is the difference here at a high level?

Elizabeth:   Agile teams tend to be a lot more focused on continuous review and improvement and they review performance more regularly. They also do different types of reviews. An Agile team retrospective will focus on the team’s working practices to have it work together, celebrating things that they’ve achieved together, bettering the relationships in the team. A more traditional multiple approach in my experience, focuses more on tasks and deliverables and not how the team perform together. And that’s an area for multiple lessons learned that we should cover but is often forgotten. Agile also has released sprint retrospectives where the lessons learned focused on the product or the service that was looked at and built and not released, and you’ve also got a project retrospective where you look at a whole project and not if probably the one most similar to the traditional word for a lessons learned meeting.

Cornelius:   So, the big difference I can see immediately is, in Agile, the retrospective meetings happen a lot more often.

Elizabeth:   Yes.

Cornelius:   Your sprints are two to four weeks long and at the end of the sprint, you have your retrospective meeting, you take what you’ve learned and you apply it immediately on the next sprint. So, there is really continuous and on-going learning.

Elizabeth:   I think so, definitely. And the co-chair for retrospective is so embedded in Agile. It’s embedded far more efficiently than it is in a multiple context, it might be. So, I think multiple teams might have to work harder to get value out of the meeting. It’s also a risk that lessons learned meetings in a multiple environment on the risk of just turning into a meeting with a lot of finger-pointing and blame. I don’t think that would happen as often in an Agile team. Perhaps because they are much more used to giving feedback and they’re much more used to working on retrospectives more regularly.

Cornelius:   Is one approach better than the other?

Elizabeth:   I suppose the right answer for that is: No, both have their merits, but my personal view would be, I prefer the idea of continuous review on a large project that stretches over more than six months. I mean, how can you remember what happens in project initiation if it is not for until a long time that you then sit down and try and review it? And I think that’s the advantage of the Agile approach for me, it’s easy enough to replicate on a multiple project team because you can schedule mini lessons learned reviews whenever you want—at the end of major stages or even once a month as part of your normal project team meeting. I suppose it’s about finding a right balance, isn’t it really?

Cornelius:   Yeah. I remember an IT project that I was leading some years back and at the end of the project, we had a lessons learned meeting and one of the lessons that we’ve had was the product owner on the other side of the fence, we should have handled her completely differently. We should have approached her completely differently and done work with her completely differently. We figured that out at the end of the project. So, if we had continuously thought about these things and tried to learn from our mistakes in the past, how wonderful this could have been if after two to three months versus fifteen months, we would have realized we have to work with her differently.  

Elizabeth:   Yes.

Cornelius:   So, yeah that is a completely different approach there. Let’s move on and review some types of lessons learned meetings and the high-level concepts behind them. We’ve done some research prior to this interview and we found a few and we’re going to review them here, so generally speaking we talked about that the overall lessons learned meetings—that’s just the general term. We’ve already reviewed that, we’ve talked about it but now let’s take a more closer look at them. We’ve also talked about the Agile retrospective so those were the first two names that we found, Lessons Learned meetings and Agile retrospectives but then we also came up with after-action reviews. What are those, Elizabeth?

Elizabeth:    That’s the term that’s come from the US military. But it means the same thing. It’s a way of taking a course of action and establishing what went well, what didn’t go well and what you’re going to do differently next time. I think whether you call it—because some of the other names that you might hear is described as post-project evaluation meeting, post-mortem, post-implementation review, they all broadly do the same thing which is exactly that—look at what works, what didn’t work and try to put in place an action plan and to capture those lessons learned so no one makes the same mistakes in the future. I think the vocabulary is really important though—which one you’d decide to use on your projects. For me a post-mortem conjures up the idea that it’s the end, something went wrong, you’re actually having problems with your project. It’s dead. [laughs] An off-direction review will go instant when it comes from a military background. It also sounds as if after the action, you missed the opportunity to put something right so I would caution the listeners to choose a phrase that is very positive and that has positive continuous improvement connotations.

Cornelius:   Right. So, depending on what you’re doing and how you’re doing it, the term “post-mortem” maybe right to you?

Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.