Ray Sheen on The BEST Project Portfolio Management Show by Appfire

“What’s the right way to run a ‘lessons learned session?'” Find out in this episode of Appfire Presents: The Best Project Portfolio Management Show by Appfire.

Project management expert Ray Sheen joins Appfire’s Kerry O’Shea Gorgone to talk about “post-mortems” or “lessons learned sessions.” We get into why these retrospectives are valuable, when to do them, what to cover, and how to follow up afterwards to make sure your next project goes more smoothly.

About the guest

Ray Sheen is a certified Project Management Professional (PMP) with the Project Management Institute. He’s also a certified Scrum Master with Scrum Alliance, and certified Lean Six Sigma Black Belt with IASSC. He is a member of the Project Management Institute and the Product Development Management Association. Ray is president and founder of Product & Process Innovation, Inc. and is a veteran business leader with more than 25 years of executive, project management, and engineering management experience.

He has worked in several industries including aerospace, electrical distribution and utilities, biotechnology, appliances, electronics, machining, medical devices, pharmaceutical, automotive, and financial services.

About the show

The BEST Project Portfolio Management Show by Appfire covers everything you ever wanted to know about PPM by talking with project management experts who’ve seen it all. And every episode is 10 minutes or less, so you can get back to changing the world, one project at a time.


For your convenience, here is the transcript of this episode:

What’s the right way to run a ‘lessons learned session?’

Kerry:  Today we are joined by Ray Sheen, who is going to talk with us about the right way to run a lessons learned session, which you might refer to as a postmortem, it depends on your preference. Ray is a certified PMP with the Project Management Institute, a certified scrum master, and certified Lean Six Sigma black belt, so he knows what he’s talking about. He’s also the president and founder of Product and Process Innovation. Stick around for 10 minutes of awesome right now.

Ray, thanks for joining. What is the right way to have one of these sessions, to run a postmortem or lessons learned session?

Ray:  The lessons learned when it’s done well provides a tremendous value to both the project team and to the organization. The trouble is most of the time it’s not done well.

Kerry:  Or at all.

Ray:  Or at all. One of the biggest problems, quite frankly, with the lessons learned is we don’t do it until the project is over. You may think isn’t that when you’re supposed to do it? If you think about it, by the time the project is over, in many cases, a lot of the people who were on the project at the beginning are no longer around. They’re off on other projects or maybe at another company. Even those who are still around don’t remember what happened back at the beginning of the project. 

So, we often find that lessons learned session is very ineffective and ineffectual because we just aren’t really in the moment and we can’t apply our lessons that are learned because we’re not on the project anymore, it’s over. My recommendation is do your lessons learned at the end of every major milestone, every major phase. If you’re on an agile project, do it at the end of each sprint. 

When you do that, it doesn’t have to be some great big offsite, go off in the woods and hold hands and think about what happened. Instead, you can do it in half an hour over pizza at lunchtime someday. You just talk through what are the things that worked, what are the things that didn’t work and that we need to change. The things that worked, the things we want to keep doing, the things that didn’t work, what we’re going to try differently this time to see if it will work better.

Kerry:  How do you overcome people’s hesitation to complain about a process that involves the people who are there with them eating pizza? 

Ray:  The way I do it is I typically start off by not being personal right upfront. I’ll ask several questions. The first question I’ll ask is, “Did we achieve the goal of the project,” or at least, “Did we achieve the goal of this phase on the project? Did we get done what we needed to get done?” Right upfront, we can either agree that we made progress or agree that we didn’t make progress and something will have to change.

After I talk about did we make progress or not, then I go to let’s take a look at our plan. Did our plan make sense? Was it a good plan? Did we have everything in there that should have been there? Were our estimates pretty close? Did we have all of the right activities? Did we have a plan that, had we followed it, it would have worked well?

Then I finally get to did we follow the plan. Did we actually follow it, or did we do a wonderful plan, put it on the shelf, ignore it, and go do our own thing? Did we actually follow the plan? As we were following the plan, what went wrong, or what went right? What kinds of risks happened that had not been accounted for, positive or negative? How did we react to those, how did we respond to those?

As we’re getting through all of that, that’s loosening everybody up because it’s not personal. We’re not pointing fingers at any one person. We’re talking about how we worked as a team, how the project unfolded. 

Then, finally, at the very end I’ll ask the question, “Is there anything that any of us need to do or want to do differently going forward?” I first put it on the individual. What do you want to change about your behavior? As we go into the next phase, as we do the next sprint, what are going to do differently? We’re going to hold each other accountable. That’s part of why we’re doing this is so that we can get better. We want to learn the lesson and apply that lesson. We start off letting folks say, “This is what I want to do differently. This is how I want to operate.” 

Then, only if I need to, we will talk with some individuals and say, “We really did have a problem here, notice how we’ve commented all along. We need you to change how you’re doing things. Let’s together decide what that change should be.”

Kerry:  Then you follow up, or you should.

Ray:  Yes. Right. 

Kerry:  A lot of times people, even if they have these meetings, they never talk about these things again.

Ray:  Often it’s because they had it at the end of the project. That project is over, so they never have to deal with it. But if you do it at each milestone, now we have our next project meeting the following Monday. We’re going we just talked about this stuff last Thursday at our lessons learned, now is the time to apply it. We said we were going to do our project meetings or our team status meetings differently, let’s do it now, let’s try it right now. 

You have that immediate follow-on to apply the lessons that you’ve learned, the things you’ve decided you want to do differently, you can apply them the next day. That really does help to lock them in when you do that.

Kerry:  It definitely seems like these should be writing, the things you’re committing to changing or doing differently in writing. 

Ray:  In writing, but we’re not talking about written on a contract and if you miss we’re going to hold you accountable or dock your pay or something. Often what I’ll do with a team, and I’ve facilitated many of these, I’ve done them with my own teams, and I’ve also facilitated many of these for other companies, we’ll put them on a whiteboard. 

If we have a team meeting where we get together, we’ll put them up there and say these are the three things that we’re working on this time. Between this milestone and the next milestone, we want to change this, this, and this. These are the top three. So, often coming out of that lessons learned, we’ll identify the top two or three items, and then we just remind ourselves of those at each meeting. 

You don’t have to fix the entire world after the lessons learned, but you prioritize a couple and those are the ones that you go after this time.

Kerry:  There are some lessons that are not project specific. If there’s a process problem with how you get an email out, that’s going to happen again with the next project. Do you memorialize those in a different spot? 

Ray:  One of the things we’ll do is as we’re talking about either in the project plan or in the project execution, if what comes up is something that is a problem with our process of project management – like you said, our email system doesn’t work well, or this template that we’re using for doing testing doesn’t have a key element on it that we need – we’ll make a recommendation back to the project management office, back to whatever organization is responsible, and we’ll say we need this changed. Then we track with them, we follow that up with them, “Did you change it? Are you doing it? Let’s see the ticket that’s going to actually make that happen.”

It isn’t always something the team needs to do. The team can identify things that others need to do and they get handed off. Usually, whoever is running that lessons learned session, whether it’s the project leader or some outside facilitator, they’ll hand those off then to the part of the organization that will be responsible for updating or fixing that problem.

Kerry:  That’s a good point you’re raising. Who actually runs these, who is the right person to run it? Maybe the problem was with the oversight of the project, in which case maybe the project manager for that project shouldn’t run the follow up. 

Ray:  Which is a reason why I’m often being called in to facilitate a lessons learned. Especially if there has been some strife on the team, it’s great to bring in an outside facilitator. In many organizations, there are lots of people with the facilitation skills. Someone in the HR department or another project leader or project manager who is familiar with how projects should run could easily do this for you. 

A lessons learned, like I said, a half hour pizza lunch should be enough to do this, to keep it informal and talk it through. It shouldn’t be a burdensome activity to have somebody facilitate this meeting for you.

Kerry:  Everybody wants projects to succeed. It’s not like we want things to not come out correctly and then have the same problem again next month. 

Ray:  Right.

Kerry:  Free pizza is a cheap price to pay. 

Ray:  Exactly. And we do get better. I was working with a project team about a year and a half ago, and we were using the Agile methodology, so we were doing two-week sprints. Every two weeks, we were doing a lessons learned, a sprint retrospective as it’s sometimes referred to, but it’s a lessons learned session. 

Initially, the first couple took us about a half an hour. By the time we were on our fifth or sixth one, we were down to doing these in 10 minutes because we could quickly say this worked, this didn’t work, we want to try this differently. We’re moving to a new phase of the project and in this new phase of the project some of the roles and responsibilities change, how do we want to operate now that this person is leading most of the activity instead of being kind of in the background?

We worked through that and would have that lessons learned every couple of weeks. Over time, we quickly honed it down to about 10 or 15 minutes. 

Kerry:  Amazing. Ray, thanks so much for joining us. This has been The Best Project Portfolio Management Show by Appfire. If you’d like to find more episodes, some of which feature Ray Sheen, go visit Hub.Appfire.com where we have all sorts of them. Thanks again. We’ll see you next time.

Last updated: 2022-06-26

Recent resources

Back to Top