How To Really Learn From “Lessons Learned” Reviews

Home Forums Program and Project Management How To Really Learn From “Lessons Learned” Reviews

This topic contains 11 replies, has 8 voices, and was last updated by  Deb Green 7 years, 6 months ago.

  • Author
    Posts
  • #159406

    Bill Brantley
    Participant

    What are your tips for making the lessons learned debriefing (or other knowledge capture methods) more productive for your career as a project manager, for the development of the project team, and for the good of the organization? What questions should you ask in these exercises? How do you best transfer this knowledge to other project managers and to future projects?

  • #159428

    Deb Green
    Participant

    I know this is going to be a “duh” no brainer comment – but document and disseminate after you collect.

    In my experience, collecting data is what a lot of people focus on.

    But if that information goes into a black hole that only one or two know the magic spell to access, you might as well not bothered to collect it to begin with.

  • #159426

    Page 4 of this presentation helps us to apply “lessons learned”: http://www.dtic.mil/ndia/2005cmmi/thursday/midha.pdf

  • #159424

    john clarke
    Participant

    I’ve been through this process three times now. Each time with a different top administrator and a repeat of the same cause. Lack of planning creates bad decisions as they are not fully developed and now I get to deal with the litigation that ensues. My recommendation for my organization is don’t waste the time and energy. The right questions were asked, the responses fully documented, publicly posted for all staff to see, and then not implemented.

  • #159422

    Bill Brantley
    Participant

    Hello John:

    Are you referring to Kari’s example?

  • #159420

    Scott Primeau
    Participant

    Gathering the lessons learned is the easy part. Using them is the hard part. I suggest building a projec management process the includes reviewing lessons learned. Along with that, the lessons learned need to be documented, disseminated, and readily retrievable for future projects. Then, the entire process needs buy-in and adoption from project teams. No problem, right.

  • #159418

    Amy L. Singer
    Participant

    Lessons Learned – Though this refers mainly to things that went wrong during a project, better practices include reviewing every project for things that went right as well as those that didn’t. Identify how/why things went well or didn’t. Collaborate to identify ways to improve in the areas that didn’t go well and to ensure the things that worked well will be repeated. The key to actually “learning” lessons is accountablility. Once methods are identified to avoid the pitfalls, add them to your process for the next few projects and review the outcome to see if they worked, tweak as necessary, and then make sure the perfected process is followed.

  • #159416

    Josh Nankivel
    Participant

    Lessons learned are useless unless they become part of the process. For my teams that may mean a change to our value stream on the kanban board, updating planning templates to ensure we ask the right questions next time around, etc.

    If you are putting them into slides or a document that isn’t a part of the regular daily workflow, don’t waste your time.

  • #159414

    Amy L. Singer
    Participant

    (Exactly!)

  • #159412

    Pattie Buel
    Participant

    GSA has done a great job collecting lessons learned on managing the Presidential Transition process. GSA is responsible for getting the space for the Transition team, configuring it (and all the technology in it), etc. Gets more interesting when the incumbent President is not a candidate because then they have to collect the requirements from multiple campaigns before the election, figure out what they can do before a winner is announced (similar set-ups desired in the space etc) and what has to be done after a winner is announced. One lesson they learned was a better way to capture lessons learned. After the 2000 election, they interviewed folks after the Inauguration when things had calmed down. Got the big lessons learned but missed several of the smaller ones. So in 2008, they had several places designated for leaving lessons learned during the project. If someone had an “I wish we had” moment, they could jot it down on a Post-It, sign it (for follow-up if needed) and leave it in one of the designated areas. Assigned folks gathered the notes throughout the process. They also took the time to talk to folks during the project about lessons learned. In the end, the team turned it all into both a tabbed reference book and also a CD with hyperlinked documents for the next team in 3.5 years

    So collect along the way, and then make the results easy to use for future groups.

  • #159410

    Josh Nankivel
    Participant

    Great point Amy. I encourage my teams to do a fair amount of experimentation to see if a proposed change to the current process might be an improvement. If the experiment yields positive results, it becomes part of our process. One reason I love kanban! 🙂

  • #159408

    Josh Nankivel
    Participant

    Good point Deb, but I’d say that documenting and disseminating is necessary, but not sufficient.

    Unless they are worked into what gets used in normal operations (templates, training, etc.) they won’t really get incorporated.

You must be logged in to reply to this topic.