Writing Project Lessons Learned

How to Effectively Use Lessons Learned in Projects

Capturing Lessons Learned in projects will provide no value unless your project organization matures its ability to use them.  You might call this retrospectives in an Agile organization.  Either way, each one represents opportunities to improve and respond to your team.

Does your organization do an excellent job of acquiring lessons learned or action items from retrospectives?  Do you apply the knowledge and make positive changes?

Who are the lessons captured for?  Whatever answer you come up with are the builders of lessons learned and retrospective methodology.  If you are using seasoned Project Managers to help you decide the best way to use them, then you may be capturing data just because you can.

Without the application of lessons learned the ability to write a few sentences about a project’s history is wasted effort.  Step outside the Project Manager’s role as administrator of the past and following activities that occur.  Understand that the lessons learned are impacted by many factors such as timing, financial limitations, resource knowledge, and language.


As an example, a lesson learned from a closing project may have been more contingency funding should have been in place due to the type of methodology used.  What if contingency funding becomes a thing of the past?  What value does that lesson provide now?

Another example: The Project Manager noted in lessons learned that the procurement component of the project impacted the critical path and it severely hampered development timing.  She indicates that had the budget approval been submitted earlier that the development would have also begun sooner.  In this project, it is the project budget analyst that completes the necessary documentation to send to the executive team.  A year later this step is entirely automated, and budget approval happens just as the project team is organizing.  Value?

Some lessons learned become process-centric.  Like the above example.  Often the timing of specific events in a project is hampered because of access to resources, or we do not understand how resources are utilized.  Business Process Management (BPM) in project organizations can aid in understanding those funnel points, and I cover those in other blog posts.

Capturing Lessons Learned Data for Application

During my time in the Project Management Organization (PMO), I did a careful examination of Lessons Learned captured over time and attempted to understand their impact.  The projects were a healthy mix of business intelligence, infrastructure, and software development. At the end of my analysis, I found that the information was rarely if ever, acted upon.  That is the key – what happens after the project team collects the lessons is where it counts.  It doesn’t matter who, when, or where they are captured, but what an organization does with the information.

As with most information randomly captured it is the attributes that help discern the applicability.  In the PMO we used a Project Management system that allowed for the capture of lessons learned and it also could add attributes to understand their applicability.  For instance, within the process, the Project Manager was responsible, in the close project phase, to enter the lessons learned.  While they could have been captured at any stage or at any time, the PM was still responsible for introducing them into the system as part of the project management methodology.  I found that some PMs would enter those lessons during the phase they occurred and then others would wait until that last project close check and add them.  Either way, the organization only audited a few projects after close so if the PM wasn’t self-governed then the lessons were not entered.

Either way, the application of those lessons was never used at the Org level.  Lessons learned were project manager-centric, and if you want to build some sort of Lessons Learned effort to engage all of your team in gathering and capturing them, then applicability has to be identified.

That is precisely what I found with my analysis.  The same handful of PMs (in a 40+ PM environment) were entering lessons learned for every project they managed.  The problem relates back to the very first statement I made at the beginning of this post:  Capturing Lessons Learned in projects will provide no value unless your project organization matures its ability to use them.

Imagine that you’ve got a process in place where PMs are supposed to make sure lessons learned capture at specific points within a project life cycle.  What method of governance do you have in place to make sure that’s happening?  Or are lessons learned so much ingrained into your culture where rarely a project is closed that doesn’t have lessons learned entered?  If your project organization isn’t using the intelligence captured from lessons learned then it’s a waste of valuable time, energy, and effort.

I’m specifically referring to the project organization as a whole – an entrepreneurial PM’s attention to detail and sound management practices are never a wasted effort.  The entrepreneurial PM will more than likely have their methods of learning lessons and applying that knowledge as they progress.  It won’t matter what type of system of organization that your team may have for collection because this PM assimilates as needed.

Let’s say, as an organization, you’ve all decided that capture and application are part of your maturation process.  Before you begin utilizing a project management tool like CA’s PPM to capture lesson’s learned you need to decide what information and attributes will better help define how the data is categorized and applied.  Because the team I worked with had already used the system over a few years, I had many examples to use to understand what we might change to better harness the technology and apply the information for the current and future execution of projects.

The first thing I noticed after gathering lessons learned over three years was that with all the information captured only certain teams were reviewing them on a regular basis such as at a phase gate meeting when a project was closed.  As a whole though, the body of PMs was not sharing the information gathered, and in some cases, the data didn’t apply.  If PMs don’t see the info how would they even apply it?  To start, I used the CA PPM reporting tool to create an automated report that would send PMs a monthly report that had the last thirty days of lessons.  Even if most PMs ignored the report, some of them might find the information useful while we then worked on real changes to the lessons learned approach.

This initial report’s goal was two-fold:  First, we knew that PMs were too busy with managing projects to share lessons, so the report enabled information sharing.  Second, the PMs now understood that their information was being shared and in turn, scrutinized.  Thus, the accuracy level would gradually increase.

After extracting everything into a spreadsheet where the information could show trends and patterns, there were several essential elements that were demonstrated:

  • New PMs were more apt to follow the process and make sure that several lessons learned were captured very accurately.  The data showed spikes in the number of lessons when new PMs joined the organization.
  • PMs who were trained in rigorous project management methodology were also more apt to enter lessons learned.
  • PMs who avoided using a system or ignored the lessons learned did not understand how their project lessons could or would be applied at the organization level.
  • Lessons learned about Vendors, the Project Team, and Communication had the highest impact.
  • The execution phase of the project had the most impact when it came to lessons learned.

Here were the challenges:

  • A global PMO had two languages.  The CA PPM system did not have translation services do this, so it was a manual step.
  • There were too many subcategories; sixteen.
  • The process dictated lessons to be entered during the close phase and often in hindsight many lessons learned were merely stated and offered no value.
  • There was currently no way for a PM to browse a Lessons Learned library before initiating a project.
  • Lessons learned were not impacting the process.
  • Lessons learned were not being used for coaching or learning opportunities.

To be useful in your organization’s implementation of practical lessons learned, you need to be aware of those challenges and take steps not to over-process them.  You can do this by following some simple rules:

The Five Why’s

Make sure that the PM understands why a lesson was learned and how it may apply.  Example:  Lesson learned: Provide system application documentation before the project kickoff.  Background: Our vendor failed to meet our timeline.  ?  Because they didn’t understand the complexity of our system at kickoff. ?  Because we only provide our system documentation at kickoff.  ?  The project management method process we use says to provide the vendor this doc at kickoff. ? Because this gives vendor management time to ensure all proprietary security documentation has been signed. ? Because our software is proprietary and needs to be protected from theft.  Wow, we need to change the process where vendor management gets engaged much earlier in the process What happened to that original lesson learned?  Now we’ve got some real work to do on the process that will apply across the organization.  Imagine over time how the same thing resurfacing may impact the process!

Data Attributes

If you use a system to capture lessons, make sure that it asks for the bare minimum of lesson attributes that have meaning to your organization and impact the process.  Which categories make the most sense?  Does affected by or resource associated have meaning if you were looking backward and trending them?  If most lessons are marked as “vendor” associated, then what?  What will your vendor management team do with the information and later impact the process?


Make sure that all of your PMs are using the same methods for capturing lessons learned and that they understand how they will be used.  If you are all using Google Smartsheet to get them, then train the PMs how to use and update, and show how you will apply the lessons.


Develop some sort of review process by PM peers that will cull the most helpful lessons.  Unless you are a PM that understands the execution nature of a project within a specific organization, then you may not speak the “language.”

Let the PMs develop a team that takes a couple of hours once a month to “clean house.”  Do you have a small PM body?  Maybe this is one person who takes a little time to understand the lesson, re-categorize as necessary or remove redundancy.  If over time, the same lesson seems clear and resurfaces every few months then the value of capture is significantly reduced.

Keep it simple.  Keep it simple.  Keep it simple.

Sometimes we see tools like CA’s PPM and think of all the ways we can over-develop something.  It’s our human nature to tinker with it.  Don’t let a system or a spreadsheet demand too much – at the end of the day your team will become beleaguered with details, and there won’t be any movement or improvement.  That’s the only reason you are capturing information.


This is a major goal for lessons learned.  They don’t do anyone or any project good if they are just sitting in some tool.  They certainly need to live inside whatever project management mechanisms, tools, or library your team use but they also need to be very visible to the entire organization.  A project manager who on boards need to have a task to review the last 30 days or more.  Another project manager who may be new to the agile methodology your team use needs to be able to search for “agile” when in the lessons database or library to see some of the lessons learned.  Even in a spreadsheet, that same PM should be able to filter down on specific project attributes to understand how their project may avoid issues down the road.


Have a goal for lessons learned.  That may change over time!  I noticed that vendor-specific lessons learned were the highest in my analysis and my next step should have been to understand why.  That would have been a goal for the next iteration of my lessons learned project.  After an annual review, I may find that vendor has dropped (because of process improvement), and we need to change our approach to procurement trends in the latest lessons.


If I’ve said this once, I’ve repeated it many:  Begin with the end in mind (quoted from another person).  Start your Lessons Learned project with the idea of how you plan to apply it and how it will help the project management organization become faster, smarter, and more engaged.  Don’t fall into the trap of capturing information just because you can and don’t allow your project managers to become wrench turners by following a process because that’s the way it’s always been.  If you can’t be a game-changer, move on to other, more impactful change in the organization!

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.