I recently finished reading a fantastic book, The Declassification Engine, which seemingly had nothing to do with project management (I was attempting to branch out 🙄). However, about a third of the way through, I was awestruck by the similarity of what the author, Matthew Connelly, was describing as "issues of not categorizing our nation's history."
Where my life and the subplot to the book come together is the reality of what a good lessons-learned strategy can do for not only an organization but a nation (i.e., the United States). Mr. Connelly does a great job in presenting the fact that could have easily been the catalyst to the saying, “Those who don't know history are doomed to repeat it.” (- Edmund Burke).
To ensure we're in sync, here's the quick version of Connelly's book: In "The Declassification Engine," Connelly discusses how he and his team explored the U.S. government's system of classification and declassification, particularly noting the negative impacts of excessive secrecy and the destruction of historical records.
Why we track Lessons Learned
Be it project or program management or even a long, drawn-out task, the process of documenting and applying lessons learned is crucial for continuous improvement and success in future endeavors. Lessons learned help organizations capitalize on their successes, avoid past mistakes, identify areas of inefficiency, and prevent the repetition of errors. Capturing this information can also contribute to the development of best practices and the improvement of business processes.
In both contexts- the government historian or project manager- there is a clear emphasis on the importance of transparency, documentation, and learning from past experiences. Just as Connelly advocates for a more transparent and accountable system of classification to enhance public understanding, project managers use lessons learned to promote transparency and accountability within their teams and organizations.
Capturing Lessons Learned
In the easiest sense, it only takes a few minutes a day to write down thoughts or issues you found useful, weird, or need to change throughout the day. I keep a running raw digital log for all my projects (via Obsydian or Notion) and it's those notes that help jog my memory for the lessons learned. Here are a few best practices (an attribution) you can follow:
Involve the Entire Team and Stakeholders: Include the project manager, the project team, and key stakeholders in the lessons learned exercise. This ensures a comprehensive understanding of the project from different perspectives. (A Guide to Capturing Lessons Learned)
Conduct Regular Reviews: Depending on the complexity of the project, conduct a lessons-learned session at the end of each project management phase to capture information when it's still fresh. This allows for timely evaluation of what went well, what went wrong, and what can be learned from it. (Asana)
Store Lessons in a Central Repository: Store the lessons learned in a central repository that is easily accessible to all team members. This ensures that the lessons are retrievable and can be used to guide future projects. (Simplilearn)
Review Past Lessons: Make it a mandatory part to review past lessons along with the team. This helps to reinforce learning and ensure that past mistakes are not repeated (Simplilearn)
Samples of Lessons Learned Templates
Here is my personal bare-bones template:
- Project Name | Start Date | End Date
- Sponsor, major stakeholders, and team members (and emails)
Known Issueswhen the Project Started (this is good to know so when taken in context with any issues that came about, there might have been an issue that was known but ignored)
- Lessons Learned
- What was the issue?
- How did it affect the project?
- How was the issue fixed, dealt with, or otherwise nullified?
- What should be done differently if this particular type of issue happens with another project?
- Sponsor or senior stakeholder (or customer*) signature stating they've reviewed the lessons learned.
All of this is pretty straightforward; number five should be done for each of the different issues that a lesson was learned. For item six, this isn't always necessary, but it does allow you to ensure someone further up the food chain is aware of any issues that the project or team had. Worst case, they say "thanks," best case, they send it around for everyone to read.
Here are some other sites for examples you can use:
ClickUp offers a list of the best lessons learned templates that can be used to capture helpful insights for future projects. These templates are designed to be comprehensive and user-friendly.
Monday.com provides an interactive lessons-learned template that is built for all kinds of professionals. This template helps team members review both positive and negative experiences of a completed project and is structured to cover everyday management, communication, technical elements, and overall project management.
TemplateLab features a variety of lessons-learned templates in Excel and Word formats. These templates are highly recommended for documenting and analyzing the lessons learned from projects, and they guide you through defining your project, choosing team members for documentation, storing information, and disseminating the lessons learned.
At the end of the day, it's our responsibility to ensure that what we or our team are doing wrong doesn't happen again.
And if you found the secret sauce to getting this particular type of project done, be sure to capture that too... it's not all about doom-n-gloom.
If you opt to give your customer a copy of the lessons learned, might I suggest you filter them not to include any internal issues your team or company had? Keep that between you and the team.
Also published here.