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).
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-
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.
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:
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.
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.
Documentation of lessons learnt should include:
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.
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.
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.
According to the Project Management Institute, applying lessons learned is a methodology consisting of three stages:
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.