Go to...

We didn’t learn our lesson

As the project I support enters a new period of performance, I reviewed the lessons learned documented a year ago and compared them to the documented lessons learned from a few weeks ago.

To be identified at any point of a project lifecycle (PMBOK page 437), all project managers should collect and document lessons learned.  In reality, everyone on the project should be collecting and documenting lessons learned.  But, as many will attest, you need to be able to implement approved process improvement activities (PMBOK page 83) or you will just continue to revisit history at the end of each cycle or project.  If that is the case, you really didn’t learn your lessons.

Do you learn from your mistakes?  You should be able to at least be aware of them.  Document your mistakes and revisit them at the beginning of the next project or cycle.  Group them into three categories: Correct Actions, Preventive Actions, and Defect Repair.

Corrective Action: Document your direction for executing future project work. Bring expected performance of the project work in line with the project management plan.

Preventive Action: Document your direction to reduce the probability of negative outcomes associated with project risks.

Defect Repair: Document a defect in a project component with the recommendation to either repair it or completely replace the component.

Though the process of documenting, reviewing, and implementing lessons learned may differ between Waterfall and Agile projects, the process still needs to happen.

Again, don’t just document lessons learned.  Act on them!

Graphic: Flickr: sopheava

About Derek Huether

I'm Vice President of Enterprise Engagements at LeadingAgile. I'm super focused on results. But I also take the hand waving out of organizational transformations. I come from a traditional PM background but I don't give points for stuff done behind the scenes. The only thing that counts is what you get done and delivered. Author of Zombie Project Management (available on Amazon)

20 Responses to “We didn’t learn our lesson”

  1. July 20, 2010 at 11:22 am

    Hi Derek – good reminders. thanks!

  2. July 20, 2010 at 6:22 pm

    Hi Derek – good reminders. thanks!

  3. July 21, 2010 at 3:17 am

    In the wake of the BP oil spill, I’ve been doing a lot of thinking about lessons learned. Given that it happened before in the 1970s, under almost identical circumstances (except the previous one was much more accessible to repair crews), I wonder, what happens to lessons learned after they’ve been captured?

    Lessons learned appear to have intrinsic value to the very next project. But the further and further removed lessons are, the less value they seem to have, until the lessons are forgotten, or deemed irrelevant. This is especially true of project risk, where the absence of a previously triggered risk event can put the consequences of such out of mind.

    How can lessons learned be captured and retained in a manner that they continue to have value even after the consequences of the original lesson have faded away?

    • Derek Huether
      July 21, 2010 at 1:18 pm

      Geoff, your comment is very apropos.
      If you’re question isn’t rhetorical, I have my own take on this.
      It’s not that BP didn’t learn from it’s mistakes. I think they weighed the risk, did a cost/benefit analysis, and decided this was a lesson to ignored. It makes me angry to think about. But, that’s what I think happened.

      Lessons learned absolutely have intrinsic value, but only if they are integrated into business processes. If not, it’s going to be like Ground Hog Day. It’s all about refinement of the process. I understand that if an event only happens once in a blue moon, it’s hard to plan for it. Still, how often does BP drill a well?!

  4. July 20, 2010 at 8:17 pm

    In the wake of the BP oil spill, I’ve been doing a lot of thinking about lessons learned. Given that it happened before in the 1970s, under almost identical circumstances (except the previous one was much more accessible to repair crews), I wonder, what happens to lessons learned after they’ve been captured?

    Lessons learned appear to have intrinsic value to the very next project. But the further and further removed lessons are, the less value they seem to have, until the lessons are forgotten, or deemed irrelevant. This is especially true of project risk, where the absence of a previously triggered risk event can put the consequences of such out of mind.

    How can lessons learned be captured and retained in a manner that they continue to have value even after the consequences of the original lesson have faded away?

    • Derek Huether
      July 21, 2010 at 6:18 am

      Geoff, your comment is very apropos.
      If you’re question isn’t rhetorical, I have my own take on this.
      It’s not that BP didn’t learn from it’s mistakes. I think they weighed the risk, did a cost/benefit analysis, and decided this was a lesson to ignored. It makes me angry to think about. But, that’s what I think happened.

      Lessons learned absolutely have intrinsic value, but only if they are integrated into business processes. If not, it’s going to be like Ground Hog Day. It’s all about refinement of the process. I understand that if an event only happens once in a blue moon, it’s hard to plan for it. Still, how often does BP drill a well?!

  5. July 21, 2010 at 4:00 pm

    No, my question absolutely wasn’t rhetorical, I’m very interested. This is something I’ve seen in my own project environments from time to time so I continue to grapple with it.

    “Why are we doing this?” I’ve heard people ask regarding processes that don’t make immediate sense on the surface.

    “Because if we don’t and x happens, we’ll be in trouble.”

    “Oh,” they reply, unconvinced.

    With the right (or rather, wrong) set of circumstances and management, it’s very easy to make a decision that eliminates an important step from a process, thus reopening risk exposure.

    Time seems to efface the value of lessons learned. (Okay that was more of an observation LOL)

    I totally agree with you about the “lesson to ignore” where BP was concerned. Chevron (a Canadian oil company *cough*) has integrated the drilling of relief wells into their BAU oil drilling processes (the only approach known to minimize widespread economic disaster in the event of a rupture). Chevron has protected themselves. In BPs case, one bad decision created a legacy of exposure that lasted through multiple management chains.

    • Derek Huether
      July 21, 2010 at 4:37 pm

      I’ve gotten those “why are we…” questions before. With a previous client, I mapped process changes back to a Process Change Management document. It was interesting to see how our processes evolved over time. If you were really into it, you could dig down and find out what the triggers were for the changes. With any Change Management (CM), changes had to be vetted and approved, sometimes requiring funding. It was all good stuff! There was proper risk analysis and everything. What’s the cost if we do this? What’s the possible cost if you don’t do this? It sounds more complicated than it was. It all flowed very nicely.

      As for BP, this was not one bad decision. This looks like a series of bad decisions at many levels, from people working on the rig, all the way up to the senior executives at BP or the U.S. Federal Government. Someone at some point should have raised a flag. We’ve all learned the earlier an issue is discovered on a project, the cheaper it is to correct it.

      Now we have a massively expensive sh!t sandwich and we’ll all have to take a bite.

      • July 21, 2010 at 6:00 pm

        Mmmmmm sh!t sandwich! (I actually know the taste well *snicker*)

        I stand corrected. 🙂

  6. July 21, 2010 at 9:00 am

    No, my question absolutely wasn’t rhetorical, I’m very interested. This is something I’ve seen in my own project environments from time to time so I continue to grapple with it.

    “Why are we doing this?” I’ve heard people ask regarding processes that don’t make immediate sense on the surface.

    “Because if we don’t and x happens, we’ll be in trouble.”

    “Oh,” they reply, unconvinced.

    With the right (or rather, wrong) set of circumstances and management, it’s very easy to make a decision that eliminates an important step from a process, thus reopening risk exposure.

    Time seems to efface the value of lessons learned. (Okay that was more of an observation LOL)

    I totally agree with you about the “lesson to ignore” where BP was concerned. Chevron (a Canadian oil company *cough*) has integrated the drilling of relief wells into their BAU oil drilling processes (the only approach known to minimize widespread economic disaster in the event of a rupture). Chevron has protected themselves. In BPs case, one bad decision created a legacy of exposure that lasted through multiple management chains.

    • Derek Huether
      July 21, 2010 at 9:37 am

      I’ve gotten those “why are we…” questions before. With a previous client, I mapped process changes back to a Process Change Management document. It was interesting to see how our processes evolved over time. If you were really into it, you could dig down and find out what the triggers were for the changes. With any Change Management (CM), changes had to be vetted and approved, sometimes requiring funding. It was all good stuff! There was proper risk analysis and everything. What’s the cost if we do this? What’s the possible cost if you don’t do this? It sounds more complicated than it was. It all flowed very nicely.

      As for BP, this was not one bad decision. This looks like a series of bad decisions at many levels, from people working on the rig, all the way up to the senior executives at BP or the U.S. Federal Government. Someone at some point should have raised a flag. We’ve all learned the earlier an issue is discovered on a project, the cheaper it is to correct it.

      Now we have a massively expensive sh!t sandwich and we’ll all have to take a bite.

      • July 21, 2010 at 11:00 am

        Mmmmmm sh!t sandwich! (I actually know the taste well *snicker*)

        I stand corrected. 🙂

  7. July 21, 2010 at 4:59 pm

    Great discussion!

    It is funny how we get the looks and huffs when we want to introduce something new…whether it be lessons learned, a new PM platform, etc. I will stay away from that rant.

    I think Geoff had it right with Chevron…they implemented the changes into their BAU processes. I have done it before, hosted some great lessons learned sessions (self-proclaimed as that may be), shared results with management, and archived the documents only to find out 2 years later that almost every manager has since left, a new round of contracted PMs are in at the client, and no one is looking at my awesome lessons learns (okay, I will stop with that).

    Point being that the corrective action needs to be put into the systems, process, and very life of the organization. The ‘way we have always did it” is the only thing that remains when management and resources change at a company.

    • Derek Huether
      July 21, 2010 at 5:49 pm

      Robert,
      Thanks for including your experience. I think the hardest part is getting the changes to become “the way we’ve always done it“.
      Here comes my analogy.
      You go to the dentist. He or she says if you don’t start flossing, you’re going to be toothless within a few years. You know the risk if you don’t brush and floss. But, unless you do it daily some 21 times (debatable), it won’t be second nature to you. It’s creating that habit that is the most difficult. Now, what is missing from many situations is the control point or mechanism preventing the project from continuing any further unless the defined process is followed. You refined the process for a reason. First time you make the mistake, shame on you. Second time you make the mistake, shame on me.

      • July 21, 2010 at 6:04 pm

        Good points, all. Creating habits is tremendously difficult and even good habits come under fire by well-meaning people looking to save time or money (I’m not talking about BP now, just in general).

        It’s Robert’s stories about changes in management that result in the collective “forgetting” of WHY habits exist.

        So another question (not rhetorical). As difficult as it is, is creating new habits within an organization enough? Or is it also important to create company “lore” that serves as cautionary tales why certain processes exist and why they shouldn’t be eliminated?

        • Derek Huether
          July 21, 2010 at 6:41 pm

          Let’s use Google or Zappos as the examples. Company culture helps make the hard questions easier to answer. For Google, do no evil. From the top, all the way down to the engineer, anyone can stop the machine if they think it goes against that motto. For Zappos, anyone at any level can go over and above the normal process if it means they’re going to provide excellent customer service. Either way, it’s part of their company culture. Until it becomes culture, it’s just going to be another pain-in-the-rear process change.

  8. July 21, 2010 at 9:59 am

    Great discussion!

    It is funny how we get the looks and huffs when we want to introduce something new…whether it be lessons learned, a new PM platform, etc. I will stay away from that rant.

    I think Geoff had it right with Chevron…they implemented the changes into their BAU processes. I have done it before, hosted some great lessons learned sessions (self-proclaimed as that may be), shared results with management, and archived the documents only to find out 2 years later that almost every manager has since left, a new round of contracted PMs are in at the client, and no one is looking at my awesome lessons learns (okay, I will stop with that).

    Point being that the corrective action needs to be put into the systems, process, and very life of the organization. The ‘way we have always did it” is the only thing that remains when management and resources change at a company.

    • Derek Huether
      July 21, 2010 at 10:49 am

      Robert,
      Thanks for including your experience. I think the hardest part is getting the changes to become “the way we’ve always done it“.
      Here comes my analogy.
      You go to the dentist. He or she says if you don’t start flossing, you’re going to be toothless within a few years. You know the risk if you don’t brush and floss. But, unless you do it daily some 21 times (debatable), it won’t be second nature to you. It’s creating that habit that is the most difficult. Now, what is missing from many situations is the control point or mechanism preventing the project from continuing any further unless the defined process is followed. You refined the process for a reason. First time you make the mistake, shame on you. Second time you make the mistake, shame on me.

      • July 21, 2010 at 11:04 am

        Good points, all. Creating habits is tremendously difficult and even good habits come under fire by well-meaning people looking to save time or money (I’m not talking about BP now, just in general).

        It’s Robert’s stories about changes in management that result in the collective “forgetting” of WHY habits exist.

        So another question (not rhetorical). As difficult as it is, is creating new habits within an organization enough? Or is it also important to create company “lore” that serves as cautionary tales why certain processes exist and why they shouldn’t be eliminated?

        • Derek Huether
          July 21, 2010 at 11:41 am

          Let’s use Google or Zappos as the examples. Company culture helps make the hard questions easier to answer. For Google, do no evil. From the top, all the way down to the engineer, anyone can stop the machine if they think it goes against that motto. For Zappos, anyone at any level can go over and above the normal process if it means they’re going to provide excellent customer service. Either way, it’s part of their company culture. Until it becomes culture, it’s just going to be another pain-in-the-rear process change.

Leave a Reply

Your email address will not be published. Required fields are marked *