I could hear Dan, one of the other project managers, from across the hall. Excusing myself to my co-worker, I hurried over.
He gestured to his computer screen, which looked like it had a new Easter egg screensaver. “Paul sent this UI to the client without running it by me first.”
“Didn’t Mary do the same thing last time?” I asked.
“Yeah, and I spoke to her about it. It’s okay to ask the client for input, but no sending mockups unless I see them first.”
“Did you update the communications SOP (standard operating procedure)?”
Dan sighed. “No.”
As a project manager, I felt his pain and let him know as much. But it was hard to feel sorry for him.
Henry Ford once said that “Failure is simply the opportunity to begin again, this time more intelligently.” I’m going to expand on that quote by adding, “Provided that you documented the lessons learned.”
Each project is a learning opportunity, even if it’s so successful that the CEO names his new yacht after you. (Hasn’t happened to me yet!) You gain insights into how teams work and processes develop, and can use those insights to create better teams, implement changes that work, and deliver more successful projects- IF you document all lessons learned and analyze what went right (or wrong).
What is Lessons Learned?
The Project Management Institute describes lessons learned as knowledge and understanding acquired via experience. These lessons may be positive ones, such as a project delivered on time and without exhausting the budget, or they may be negative, such as a blown budget and inferior deliverables. What matters is that they-
- Are factually correct
- Have a real impact on team operations
- Identify a decision, design, or process that supports a positive result or reduces the potential for failure
Lessons learned in project management provides the most benefit when they are documented, communicated, and archived after all project participants have been able to confirm or question the conclusions.
Below are some lessons learned examples in different categories.
- Supply Management. The project manager was not fully involved with the contract preparation process, so when a contract was finally awarded to a supplier, it did not include everything that was needed for the project. The result was a document modification that set back the project kickoff by over a week. The lesson learned was that the project manager must be involved in all supply contract preparation and sign-off.
- Team Management: The project manager asked for and received approval to recognize and reward successful teamwork by arranging a catered lunch after achieving a project milestone. Team members were more enthusiastic about their work and supportive of one another, so the decision was made to institute some type of reward for successful completion of key stages.
Why Lessons Learned Is Important
If your project experienced a catastrophic failure due to scope creep, budget overruns, a product that fell below expectations, or any other problem, the only way to prevent the same outcome in the future is to:
- Understand what went wrong and why
- Identify what can be done differently in the future
The same principle applies to successful projects: when you know what went well and why, you can duplicate the appropriate steps across all your teams and yield positive results with other projects.
How to Document Lessons Learned
In my opinion, lessons learned should not be confined to the project wrap-up. As the saying goes, there’s no time like the present. The best time to document something is immediately after it happened, otherwise key information can be accidentally forgotten or, in the case of negative outcomes, intentionally glossed over.
These are the steps I take. You may do it differently, but there’s no right or wrong way as long as a valid and effective lessons learned document results.
- Solicit information. Everyone on my teams knows that if something happens, whether it be good, bad, or ugly, I want to hear about it. Lessons learned must be a collaborative undertaking in order to be effective. Everyone knows that I’m more interested in collecting information than passing judgment, so there are days when input is overwhelming, but the time spent documenting everything is well worth the effort.
- Publish a report. Once all information is collected, examined, and revised as needed, I create a PDF and distribute it so that everyone involved, from the team to the upper management, is aware of and understands all lessons learned.
- Store the report in a central location. A lessons learned document is meant to guide future projects, which is impossible if you don’t make it readily available. I keep all of my reports in a central location so that other project managers can adopt successful routines and avoid pitfalls from previous projects.
Documentation of lessons learnt should include:
- Naming the scope of the lesson (e.g., graphic design shortcuts that expedite image processing)
- A description of the problem or success (with lessons learned for software projects, this could be adding new features without significantly driving up cost)
- The impact on the project (e.g., the deadline was missed or outstanding results were achieved without exhausting the budget.)
- The process improvement recommendations (lessons learned).
All reports should consist of the information received during the lessons learned session and be distributed to all participants, who should be given enough time to review them and either confirm their accuracy or offer corrections. Once the report is finalized, send a copy to the entire project team and store it with the other project documentation.
When you prepare a project summary for the senior project stakeholders, such as your boss, include an overview of what went well and what needs to be improved. You can include the report as an email attachment or offer to make a copy available if they need more information.
When to Conduct Lessons Learned
If someone asked me when to conduct lessons learned, I’d say, “Early and often.”
I know project managers who make lessons learned part of the wrap-up meeting, but I think it’s valuable at all stages of a project. My teams have interim lessons learned reviews at the end of each milestone, with the goal of recognizing what is working and what isn’t, so that we can adjust right away and improve our work and the overall project.
Challenges With Project Lessons Learned
All teams should be recording lessons learned, both positive and negative, as the project unfolds, but too many of them either don’t do it because there is no defined process for doing so or they don’t act on what they learn. Unless you document them and have a system in place to make use of them, it can be hard (if not impossible) to keep track of lessons learned.
There Is No Defined “Lessons Learned” Process in Place
Without a defined process in place, don’t be surprised if the people on your team don’t capture lessons learned. They will solve the problem or feel good about the success, but it ends there and no one benefits from their new understanding.
I’ve already presented my lessons learned documentation process. You can adopt it for your own teams or come up with your approach as long as it includes the collection, publication, storage, and future use of all data. There are also some excellent (and free) lessons learned templates that you can use for inspiration or modify for your own use.
They Capture Lessons Learned But Don’t Use Them
This is another common problem. As soon as a team member encounters success or failure, they capture the details that are turned into lessons learned at the end of the project. The project manager creates a document that is filed neatly away with the other project data and never sees the light of day. No one learns from these good or bad experiences and nothing changes.
At my company, it is a requirement that project managers start each new project by consulting a lessons learned folder on the company intranet. It contains subfolders categorized by project type, and each one lists reports with titles that identify their contents.
How to Apply Lessons Learned
According to the Project Management Institute, applying lessons learned is a methodology consisting of three stages:
- Analyzing: All lessons learned must be analyzed and organized for future application of results. This step, which identifies the underlying reason or condition that causes something to happen, provides a better understanding of how to repeat successes and deter a similar failure.
- Storing: Lessons learned need to be stored in a project repository for future use. The input form should include fields like category (e.g., software development, marketing), the lesson learned, action taken, and root cause. The repository at my agency can be searched by keyword, which makes it a lot easier to access all relevant lessons for your project.
- Retrieving: Before attending risk planning sessions for a new project, the manager retrieves all relevant lessons learned documents and uses them to identify possible risks and develop mitigation strategies.
With a lessons learned process in place, you can treat each project as a learning experience and share all knowledge and insights with other managers in your company. As you apply the lessons, they become part of the operational strategy and initiate changes that everyone will thank you for.
Rose Keefe is an author and technical writer who has over ten years’ experience in supporting project managers in the manufacturing and construction sectors. One of her primary responsibilities was developing product manuals that supported efficient use of industrial equipment. She continues to write on the subject of time management and commercial productivity for trade websites and publications.