Lessons Learned in PM: Documentation and Process

"Lessons Learned" can be in almost any aspect of a project. For example, in Project Management, Lessons Learned can include how mistakes were documented, how processes were modified, and any other associated improvements. In getting better, we are making improvements or boosting efficiency, and Lessons Learned can be in any of these areas.

For most of my professional life, and in my own project work, what I witnessed countless times was project closes, and all team members exhale, focus on the next deadline, and the project's Lessons Learned seem to disappear. In the context of PMI research, the construct of "Lessons Learned" and why most organizations skip it, simply states that organizations that do not do a Lessons Learned construct waste on average 28% of their time repeating the same mistakes.

In my own journey to complete my PMP certification and the PMP training workshops, including formal PMP certification training and truly understanding what is PMP certification, it became apparent to me that the knowledge capture, or documentation of knowledge, was systematic, and was one of the factors that separated the performing teams from the teams that were stuck in the firefighting mode. Lessons learned, or knowledge documentation and retrieval processes, were a core component of my professional training.

Lessons learned in project management can be defined as documentation of all the experiences, knowledge, and information pertaining to a project. These not only include mistakes, but successes, near misses, and even innovative solutions or discoveries that fundamentally changed how work should be performed in the future.

Consider Lessons Learned as the memorial and celebration of your project. You are capturing the things that went wrong and the things that went right. This allows for a holistic approach that most generic post-mortems are unable to achieve.

The benefits of project management are utilized, the more the unit becomes effective, especially when the phenomena are captured and applied systematically. I have seen how teams analyze and reduce project timelines by 15 to 20 per cent after reflecting on lessons learned before starting a new initiative.

Organizations usually find themselves at one of the three levels of maturity when it comes to lessons learned in documenting PMs.

Level 1: Basic Process

At Level 1, lessons learned occur on an infrequent basis. There may be one person who, at the end of the project, tries to organize a round-up meeting. Is there any documentation? Perhaps a few notes in one person's email. There is no process, no templates, no repository, and no future teams that can benefit from this information.

Most small companies start here. This is fine when you are running a project or two each year. However, if you are overseeing several projects, each with the same repeating elements, Level 1 becomes a big problem fairly quickly.

Level 2: Systematic Repository

At Level 2, organizations have established processes and templates. They have also built a centralized repository where lessons are stored in a systematic manner. The project management plan has milestones defined that are specific to lesson capturing, and these occur throughout the project, not just at the conclusion.

This is where real organizational learning begins. Teams are able to retrace past lessons and recognize patterns, thus avoiding mistakes that others have already solved.

Level 3: Metrics-Driven Approach

By the time organizations reach Level 3, lessons learned become a matter of business strategy. Executives' dashboards provide visibility of trends at the project portfolio level. Teams are able to measure ROI on the improvements stemming from lessons learned. This is where an understanding of KPIs becomes critical, and KPI in project management enable teams to quantify the true value of capturing knowledge.

Within a two-year time span, I have watched Level 3 organizations drop project failure rates by 40% — and that's the impact of treating lessons learned with the same level of importance as budget and schedule management.

This is the framework I apply to each project, and it is a blend of PMI standards and my practice. The first step is to chart lessons learned.

Step One: Gather Insights

This begins with a structured survey of all the participants and not at the closing of the project when memories have faded. Insights need to be captured at project milestones.

Key Questions in Surveys:

• What went above and beyond the call of duty?
• What did we not achieve?
• Which processes worked effectively?
• Where did we fail to communicate?
• What will you do differently next time?

Schedule a meeting with an outside facilitator to guide this discussion. The facilitator can't be the project manager. You need someone impartial who can encourage candid comments and minimize defensiveness.

Step Two: Jot Down the Lessons Learned

Just like useful conversations can be forgotten, so can good insights, if not documented. Build a report with the following structure:

• An executive summary for the leadership team
• Findings, along with sufficient detail, broken down by each phase of the project
• Root cause analysis for the major problems
• Actionable recommendations along with the responsible parties
• Relevant data and additional examples

Your documentation should address the following: "What do I need to know if I ever have to do this again within the next year?" Everything else is noise.

Step Three: Analyze Lessons Learned

Unprocessed data is devoid of meaning. Look for areas of improvement across your various projects. Were the goals unclear, leading to scope creep? Were the selection criteria for projects not good enough, highlighting gaps in project selection methods and creating technical problems?

I create a simple priority matrix plotting impact versus effort. Improvements that are high-impact, and low-effort are tackled right away. High-impact, high-effort initiatives are turned into strategic priorities.

Step 4: Save what you have learned

Your repository should be both searchable and accessible. I have used everything from SharePoint to other knowledge management platforms. The tool isn't as important as how you organize it.

Here is an example of effective organization.

• Type of project or industry
• Which phase does the lesson occur in
• Functional area (technical, coordination, resources)
• Searchable keywords

Store each lesson in various categories. It should be easy to find relevant insight under a keyword, "vendor management," even if the original project was labelled "procurement."

Step 5: Apply and retrieve lessons

This step determines if your entire process succeeds or fails. Most projects have an initiation checklist; make it compulsory to review lessons from previous projects. Good lesson learned reports should take you 2-3 hours to review similar previous projects when planning a new project.

There is a project cycle management. Knowing this cycle will help you know when to draw lessons from your repository. Don't do it only once; check it before each of the major phase transitions.

Challenge 1: Nobody Participates

Team members see lessons learned as extra, unbeneficial work. They are burnt out and want to move on

Solution: Integrate this into project closure requirements. Absence of lessons learned means 'the project' cannot be closed. Also, success stories where lessons learned saved the time or money of another team are worth sharing. Make it clear what the value is.

Challenge 2: Generic Useless Documentation

I have seen countless lessons learned reports that state "communication could be better" or "planning needs improvement." These vague statements do not help anyone.

Solution: State clear, specific examples and recommendations. Rather than "improve communication, say "establish daily 15-minute standup meetings using the format from Project X, which decreased email volume by 60%."

Challenge 3: Knowledge Never Gets Applied

The repository exists, but nobody uses it. Lessons are captured but forgotten.

Solution: Build repository search requirements into your PMP certification training and your project kickoff templates. Make it mandatory. During project planning, require teams to state which lessons from the past they looked at and how those lessons changed their approach.

Starting off, no costly programs are needed. For the time being, a simple and well-structured SharePoint library is sufficient for your team. As you grow, you may want to look into specialized knowledge management software that provides:

• More advanced search options
• Better user-recommended search results
• Compatibility with your project management software
• Analytic reports on user activity and potential knowledge gaps
• Better version control and audit trails

Important Templates:

Companies that thrive on lessons learned share a few key traits. They treat it as a continuous process, not a one-off activity. They resource it. They measure it.

I researched how construction companies manage safety lessons learned. Every safety incident, no matter how trivial, gets recorded and analyzed within two days. The findings are instantly integrated into daily toolbox talks for all active projects. This timely practice safeguards from recurrence of the same safety hazards.

Agile development teams conduct blitz summaries every two weeks. They don't wait until the project is completed. This creates a company-wide culture where continuous improvement is a normal part of the company culture.

How do you measure the success of a project manager's lessons learned? Use the following metrics:

Application Rate: The percentage of new projects that reference lessons learned from previous projects.

Time Savings: The amount of time spent planning and problem-solving.

Error Reduction: The number of repeated mistakes.

ROI: The total value delivered versus the total costs of the program.

Knowing PMP formulas would help executives see the benefits of these metrics, and concepts reinforced through a project management professional course make it easier to translate lessons learned into measurable financial and operational outcomes.

Begin with one project. Conduct a lessons learned session this week. Make a detailed document and share it with teams that are doing the same thing. Then measure the impact.

Once you have shown the value of a small project, you can increase the size of your project. Standardize templates. Train people to facilitate. Build your repository. Set a minimum usage requirement.

Project leadership involves advocating for improvement, even if the team may not want to learn. The improvement of your organization's project success rate may be more due to your determination to learn than to any tools or methodologies.

Today's learning is tomorrow's competitive advantage.

Make it useful.