Article overview
Each project is unique, and each project will have similarities to the previously completed project. A Lesson Learned log documents the experience derived from a project. Documenting the lessons learned from a project can help capture future problems in a timely manner and reduce the number of the repeated mistakes.
Table of content
Every day is an opportunity to learn something new. For a project team, this is true and the lessons about the current project should be documented and be reviewed. The documented lesson should be accessible by all for current and future work. In fact, we would argue that the agile approaches, for example, Scrum, have daily stand-up meetings and post sprint retrospectives, both of which are opportunities for team sharing and learning. No matter the project or work methodology, learning while doing is how our organization grows in competency. We wrote this book with Shawn Quigley who has been studying and helping organizations become a learning organization.
Using words to convey ideas can be challenging. To ensure some measure of understanding, requires we have the same meaning for keywords. You might be surprised to know that, anecdotally, there are people that say quibbling over definitions is a waste of time, but how else can we ensure what is being articulated is understood? To that end, we must first establish a common foundation from which to build. Let’s start by defining some key terms:
1. Lesson: an activity that is done in order to learn something; also: something is taught, a single class or part of a course of instruction, something learned through experience. (Merriam-Webster (Lesson))
2. Learn: to gain knowledge or understanding of or skill by study, instruction, or experience, to come to be able, to come to realize. (Merriam-Webster (Learn))
The purpose of something as trivial as the definition of the words lesson and learn allows gaining the insight that every activity undertaken within a project is potentially a lesson learned – more importantly, only if the organization has applied what it has learned to current and future endeavors. Sadly, in many organizations, these lessons are, at best, merely documented and stored, relegated to the dusty project archive shelves. Within these organizations, teams are very apt at capturing problems that arise during the day. However, these organizations rarely determine why these problems occurred; much less remind themselves of these problems as they ponder which fork in the road to take the next time the opportunity to succeed presents itself.1
A Lesson Learned is knowledge or understanding gained by experience that has a significant impact on a project and/or the organization… A Lesson Learned log documents the experience gained during a project. These lessons come from working with or solving real-world problems. Collecting and disseminating lessons learned helps to eliminate the occurrence of the same problems in future projects.2
Assuming your organization doesn’t have one already, a log template should be set up, in a program such as Microsoft Excel. All Stakeholders should have access to the template. The Lessons Learned Log should be introduced at the Project Kickoff meeting. Traditionally these lessons learned logs have been in physical notebooks. Modern tools, using tags and other categorizable techniques in searchable databases is a more modern method.
An explanation of where the log is located, how to fill it out, and the information required should be a handout to the stakeholders.
''There is only one thing more painful than learning from experience and that is not learning from experience.”– Archibald MacLeish
We tend to think of lessons in terms of Problem-Action-Result (PAR). In recording of lessons, we try to capture the problem. For example, like all organizations, we have a Terms & Conditions. It clearly states our terms for payment and the timing of said payment. When a client challenges our payment terms, we have choices. We can re-enforce our terms, in a nice way. We can accept their terms for payment. Or we can decide not to complete the contract and not take on the work.
The Problem: The client doesn’t accept our payment terms.
The Action: Review our payment terms and the client’s terms. Discussion of pros and cons.
The Result: Accept the client’s terms, as we really want to work with this client. Lesson Learned is when dealing with client X we apply their terms for payment.
This is a document and reviewed so that all of us that interface with clients understands that client X has special payment terms. This also shows how lessons learned can start even before a project does.
This example will not apply to all project managers. Although, it may apply to negotiating with and through buyers with suppliers.
The most common mistake with lessons learned is not to start recording lessons from project kickoff. Too many organizations understand Archibald’s point all-to-well. Like a ritualistic sacrifice, project team members, project managers, and executives review the project’s closing report containing a myriad of “Thou Shall Nots…”, chanting a mesmerizing slogan about learning from past mistakes – and then set fire to the white book and watch it burn, never to be discussed again. “Don’t mention the war”, as they say.3
“Those who fail to learn from history are doomed to repeat it”.
– Winston Churchill (among others)
What’s more amazing, is these same clerics that performed this ritualistic burning are shocked when those same mistakes are miraculously raised from the dead and become re-incarnate in the next project, reducing team performance, morale, and sapping value. What these organizations have failed to realize is that a new thinking is needed in order to change this reality. Reinforcing the same methods, tools, and mindsets that caused the mistakes, means you’ll make these same mistakes over and over, perhaps bigger, faster and more costly.
“We cannot solve our problems by using the same thinking we used to create them”.
– Albert Einstein
Second common mistake is not distributing lessons learned at regular intervals or at all. The log should be easily accessible to all stakeholders. There are protections if you wish to keep data from being edited. We think the Lessons Learned Log should be a recurring meeting agenda item. Having the log as a recurring agenda item, distribution is easily accomplished to those in attendance. Keeping an attendance log will help identify who not in attendance should receive notification after the meeting.
Third common mistake is not referring to the Lessons Learned Log from previous projects. Usually this is because the log is buried and not easily available. In the time before computers, it meant going to storage to search through boxes, mostly mis-marked. Hoping you have the right box, opening it and search through mis-marked manila folders. Usually, costing hours. With today’s technology, creating, filling in, saving, and retrieve should be a breeze.
The fourth common mistake is to wait until the end of the project to document the lessons learned. We are not certain this still happens. However, from our experience, not so long ago, lessons learned were relegated to the end of the project. At this time accurately recalling what happened and what was the most severe of those incidents is difficult.
Each project is unique, and each project will have similarities to previous completed projects. Document Lessons Learned will help reduce the number of repeated mistakes or misses.
Actions:
Review logs from previous projects – identify those from similar projects *You may want to copy and include in the current project file/plan.
Have a log and process for documenting lessons – discuss with the team, include key stakeholders earlier the better in the life of the project. Occasionally, discussing and documenting lessons as early as the Business Case stage is needed. *Lessons from the Business Case stage may become Risks, but that is another article.
Place the Lessons Learner log in a team common, easily accessible area.
Review it weekly, or as often as warranted.