7.2 Learn to get the most out of lessons learned meetings - Video Tutorials & Practice Problems

<v ->So one of the things, one of the biggest details</v> from these how these reviews, how things went, is lessons learned meetings. Lessons learned meetings is our opportunity to sit down and depending upon how good the manager is, and how honest they are, and how much trust has accrued in that team, sometimes being brutally honest. What worked? What didn't work? What did we learn from this that we're never gonna do again? What did we learn that we can immediately apply to our other projects? What are some of the things that help us get better as a company by what took place here? In order for that to happen though, lessons learned meetings have to follow certain guidelines in order for them to be useful. For example, clear rules of behavior. Make clear what's appropriate in a lessons learned meeting. Lessons learned meetings are not an opportunity to finger point. They're not a chance to park blame on other people. They're an opportunity to try and grow as a team. So organizational learning can take place here if we allow it. But in order for that to happen, we have to push all the other pathologies out of the way that oftentimes pop up. For example, the first time someone says, well, why did that occur? That was a real disaster with this project. We barely survived it. What some people want to do is to start pointing fingers. Instead of why did that occur, they wanna say, who caused that. That's not helpful. So establishing clear rules of behavior is critical. Describing objectively what occurred. Not putting anyone's tone into it, not any spin of why it happened, but being objective is very important for these lessons learned meetings as well. This happened under these circumstances and this was unforeseen, and then this occurred, et cetera. Be specific, but be objective about it. Number three, our job here is to fix the problem. It's not to fix the blame. It's not to find a fall guy, somebody who's convenient. Well, you can point at this person. The worst case scenario here is when we fix the blame on somebody who's not even in the room to defend themselves. So somebody who's no longer part of the project, or the customer, or top management, or somebody who doesn't even have really a stake in what occurred here, but they're not in the room. They're a convenient fall guy. So let's just kind of sweep all the blame on that person, and that way we mutually absolve ourselves from all guilt. That's not, again, helpful. Fixing the problem, first and foremost, consists of getting away from finger pointing and saying there's an issue that occurred here. I don't care who originated it. Here was the issue. We have to take steps to minimize this ever happening again. So some of the common errors that we see in these lessons learned meetings is number one, what I call misidentifying systematic errors. There's a difference between variation, meaning errors that are systematic, what we call common cause, and errors that are unexpected, special cause errors. And sometimes what happens, there's a natural human tendency to see a mistake and to say, oh, that happened because of a special circumstance. That wasn't the normal state of affairs. That was just a lightning bolt out of the blue or that was a one in a million shot. Nobody expected that to happen. Because when we do that, we very conveniently identify all mistakes made as the result of something that was totally random or totally unforeseeable. What I'm suggesting here is we have to take a hard look at this and step back and say when there's systematic errors, when this is happening again and again and again, it's not the result of a bolt of lightning. It's the result of a inbred problem that we've allowed as a corporation or as a project team to become a systematic part of our operation. So one thing we have to do with these lessons learned meetings is get away from this idea of trying to create randomization in the mistakes, and look hard at 'em and say what mistakes are not random, but they're systematic. And that's the idea of special common cause versus special cause variance. Another common mistake is misinterpreting these lessons based on events. So something happened and we put a different spin on it rather than interpret it as well, this occurred on this team. We had the client who contacted us and said that this is not what they were looking for. They wanted this. And so we got into this big argument about change orders because they insisted they weren't gonna pay extra money for the change orders. We said they had to be paid. They pulled out the contract, we pulled out ours, and then we wasted six weeks while the lawyers got into it. We have to look at these events and say, how did this occur? What could we have done differently about it? So let's not misinterpret the lesson. Maybe somebody in the room says, well, I guess what that lesson showed us is we need to get the lawyers involved very early. No, I think that's a misinterpretation of events. How can we look at it in another way that's maybe a little more positive or more constructive? So lessons learned meetings are just that. They're intended for us to go over what took place, particularly the main events, particularly the review gates, particularly the really extraordinary good and the really extraordinary bad, and try and make sense of them. Try and come to a rational conclusion about the causes of these things occurring and what lessons we can take away for future from these events. The last main error, and I was guilty of this myself all the time initially when I first started with projects is this failure to pass along conclusions. Remember, I wanted to bury the final information, the administrative stuff. I wanted to fill out my reports, get 'em done, and then move on. And that's a bad way to operate. In order for lessons learned meetings to really be meaningful, we have to take this information and we have to be willing to pass it along. Now, the US Army, when they allow officers, let's say you're a captain and you're looking for your next promotion. Well, before you can go the next rung up the ladder, they're gonna put you in charge of some program. They're gonna make you a program manager which is oftentimes a project, but they're gonna make you a manager of some program or project within their organization. Now, in the Army, they require that all previous projects of a similar type, all projects have to be put into databases with a very formal lessons learned write up and all of the reports and everything, and they require future project managers, the ones who are now going to take that ball for their own career, to first demonstrate that they went back to those databases, they looked up these similar projects, and they have an action plan in place where they recognize here were problems that occurred, if they happen in this situation, here are the steps that I've already started identifying for how I can address those things. Now, they have to do this before they're even given the sign off and allowed to take that project and get started. Think in our own organizations, if we were a little bit more formal like that and a little bit more purposeful in terms of these kinds of ideas, so that we really did require that conclusions that we came up with were passed along and embedded in the organizational culture. Then learning is going to occur. There's an old saying about the difference between a manager with 10 years experience and a manager with one year's experience 10 times. Well, clearly the manager with one year's experience 10 times has never learned anything along the way and keeps making the same mistake again, and again, and again because he's never gotten it. What I want you folks to be is that manager with 10 years experience or 20 years experience because that's a manager with a knowledge base.