Project Management Institute

Integrating lessons learned throughout the product development process


It is not unusual for organizations to collect lessons learned at the end of a project, file them away, and never look at them again. Many projects are similar in nature, such that project teams could benefit from the learnings that were “filed away,” but instead navigate down similar paths and make similar mistakes that could easily have been avoided by reviewing available information and incorporating process improvement suggestions earlier. This paper examines the gaps many companies experience in their lessons learned processes, the three types of lessons that are common in most organizations, and the unique approach that has been developed in our organization based on the needs of the teams and management of the company that drive our business goals.

“Everything has been said before, but since nobody listens we have to keep going back and beginning all over again.” ~Andre Gide, 1891


When you manage a project, you quickly become knowledgeable in the process or product and the risks and challenges with that project. As project managers become more seasoned, they take what they learn with them from previous projects and use this information when planning a subsequent project. They are determined not to let past mistake recur and often improve the next process based on their knowledge bank. We succeed, we fail, and we vow not to fail over the same problem twice. The problem is that we did fail and a negative outcome occurred. Although failure often brings about future changes and/or a lesson bound to not be repeated, what if that failure could have been avoided in the first place? What if that project manager could benefit from the past experiences of a colleague and knew what to expect and how to avoid a negative outcome? Project management organizations contain so much knowledge—how do we tap into that knowledge? How do we “download” everything from a seasoned project manager who has worked in the field for several years and share that with a brand new project manager? How do we onboard someone who was a project manager at a technology company and is making a job change to a different type of organization (manufacturing, for example)? This is exactly what our organization set out to do: 1) Determine how we could tap into the vast knowledge and experience of others in our organization, build it into our process, and improve the overall organization; B) Develop a process that embedded an integrated lessons learned process throughout the product development process rather than just doing a data dump at the end of a project and never looking at the information again; and C) Leverage technology to provide ease of capture and access to our Knowledge Base Lessons Learned.

The Phases of Our Lessons Learned Approach

As you might expect, our lessons learned project followed the standard phases of a typical project. The “findings” being discussed here span predominantly across these three phases:

1. Planning

  • Work with internal stakeholders to identify drivers and synergy options
  • Research external “best in class” organizations to benchmark their lessons learned processes
  • Develop lessons learned plan
  • Create the buzz and engagement throughout the organization (using change management principles)

2. Execution

  • Develop and define the process, including identifying projects that need to follow the process (all!)
  • Revise existing templates
  • Create a repository for lessons learned
  • Train all project managers; encourage adoption by showing benefits; ensure all supervisors are asking about them at one on one meetings as well as assigning mentors
  • Mandate use by requiring project managers to log usable lessons as risk mitigation at the onset of each project

3. Monitor and Control

  • Identify “lessons” that require follow-up, assign accountability and action owners
  • Tweak process/revise templates
  • Communicate openly, often, and verbally in project management forums regarding new issues and closure of process improvement opportunities that have been “closed”
  • Reinforce use of process

Learning and Planning

What Is the Problem?

We began this process by conducting a deep-dive into our current process. Our organization requires each project team to collect and log lessons learned at the close of every project. We reviewed a previously used system for logging lessons learned that had been abandoned 3 to 4 years ago. We conducted focus groups with experienced and non-experienced project managers in our organization to gather their feedback, experience, suggestions, and requirements for a more thorough, user-friendly lessons learned process.

Identifying the Gaps and Key Drivers

Throughout the learning and planning phase, we learned that most project managers inside and outside our company conduct thorough lessons learned meetings at the close/launch of the project—they document the problems and achievements and make recommendations for future success. However, these are typically filed and abandoned as they quickly move onto the next project. During our review of a previously used database, we learned that it was a “dump and abandon” situation as well—the information was documented but rarely accessed thereafter. There was very little follow-up from the information entered, many duplicates of same/similar problems, and no action plan or person assigned to determine a resolution to ongoing issues. It was not user friendly and required a project manager to review the entire repository rather than the option to search by key issues, similar projects, and so forth.

We also learned that most project managers talk to one another about experiences and to glean knowledge about specific challenges and they view certain individuals as “experts” in specific content areas. Although they are willing to try a new process, all agree that it should be easy-to-use, require minimal time, and offer valuable information. Overall, the culture of “launch and abandon” clearly became a key historical challenge that we set out to fix in our new process.

During this discovery phase, we also met with key management stakeholders who echoed the gaps in the current and previous processes yet encouraged the team by their commitment to improving the process, assigning accountability, and promoting team commitment to projects after launch of a product or program.

The team also spent time researching PMI, PMOs, white papers, and publications and other research sites (i.e., APQC, Roundtables, etc.) to learn the types of processes that best in class organizations use. We found that that they fell into two key buckets: Those that operate similar to ours: they collect the lessons in a unified team meeting, thoroughly document the problems, root cause, successes, and actions for future improvement related to the lessons. They then file them away on a team site, Sharepoint site or similar, and rarely reference the information. The other companies invest significant resources, time and money to create their own company-specific database and resourced to sustain usage. They create special groups within their organization to consolidate lessons learned, indentify process owners for each business purpose and begin to realize organizational as well as individual benefits from its lessons learned. A perfect example of embedding this process into their organization is the U.S. Army Center for Army Lessons Learned (CALL). They are accountable for the entire Army Lessons Learned Program and responsible for the Army’s formal lessons learned mission, which includes dissemination of observations, insights and lessons (OILs), which result in updates to the Army’s SOPs, tactics, techniques, and procedures (Tress, 2010).


Three Types of Lessons

During this exploratory phase, we determined that there are three types of lessons, lessons should be easy to identify and load, and all lessons must follow the WEAVE principal:

- Written

- Everyone (everyone involved , every one of the milestones)

- Actionable

- Verbalize

- Easy (easy to understand as well as to access and load lessons)

We identified and categorized all lessons leaned into three categories: Process Improvement Opportunities, Teaching Opportunities, and Experiences. We charted these three lessons and used these as a basis for communication, planning, and training the organization – easily remembered via the diagram below in Exhibit 1 and detailed further in Exhibit 2.

Chart of Lesson Types

Exhibit 1 – Chart of Lesson Types

Implementing the Lessons Learned Plan

Understanding that our resources (both money and people) are limited, we chose to pursue an approach based on key principals identified by APQC's 2009 Collaborative Research study, Cutting the Cost of Not Knowing: Lessons Learned Systems People Really Use (Tress, 2010, p 1):

  1. Provide process training
  2. Set expectations
  3. Recognize the opportunity for reuse
  4. Build lessons learned into performance review objectives (our outcome was not tied to objectives but rather key documents reviewed by management)
  5. Make access easy

The three types of lessons follow different paths, as shown here in Exhibit 2:

Paths for the various lesson types

Exhibit 2: Paths for the various lesson types

Defining the Process

Since our organization had already been following a process to collect lessons learned, it was clear we needed to build sustainable “hooks” into our overall project process and build a system that would allow teams to immediately enter lessons learned and easily search for lessons when embarking on a new project. We met with management and proposed a process that requires project managers to search the database when starting a new project, and establish a “mentor” for previous and similar projects. The result was fantastic! Our new process now includes management assignment of a mentor for each project, a management team to review all lessons entered into the database to assign ownership, monitor for final closure and communicate results; and a requirement for project managers to document lessons they learned in projects at key milestones rather than waiting for the post-mortem AND to identify lessons they will consider at the onset of new projects.

The development of the lessons learned database required minimal IT resources and was established as an MS SharePoint site, creating the flexibility to search the database from any types of key words, functional areas, project types, etc. (like Internet search engines). The team established an easy-to-use word document to document the lessons to enter into the database, several metadata fields for the SharePoint site, and tested the site with pilot teams. With a few tweaks, the process was finalized and ready for training and implementation.

The new process is shown visually below in Exhibit 3.

Graphic representation of Lessons Learned Process as Integrated throughout Project

Exhibit 3: Graphic representation of Lessons Learned Process as Integrated throughout Project

Documentation and Training

In preparation for full training and rollout, the team developed the templates and tools necessary to deploying the lessons learned process. These documents include the following:

  1. Customizable template for collecting all lessons
  2. Decision tree for deciding what path lesson needs to follow – see Exhibit 2 (above)
  3. Team examples for lessons learned decision tree – see Exhibit 4 (below)
  4. Template for lesson that needs to be loaded (standardized form) – see Exhibit 5 (below)
  5. Metadata questions that are to be answered when uploading form – see Exhibit 6 (below)
  6. Database that is searchable like the Internet – see Exhibit 7 (below)

EXPERIENCES “I won’t do that again!”


ACTION: Vocalize at department meeting and/or mentee

  • Installing change parts turned out to be more complicated than we originally anticipated
  • Get the specs right the first time to reduce re-work in the team
  • Affiliate kept wanting to add claims after testing – hold firm to the agreed upon claims grid and managing the affiliate expectations
  • Continue to have procurement push back on any new costs that the supplier did not originally communicate
  • A more thorough risk planning plan may have allowed for more effective project planning and I should have completed it sooner
  • Clearly identify roles and responsibilities

      TEACHING OPPORTUNITIES “I must share this information with others”


ACTION: Vocalize at department meeting/forum /mentee; load into the Lessons Learned (LL) database at project manager’s discretion

  • Good communication and direct access to xxx person (name confidential) made a big difference for method transfers
  • We learned that we needed a direct contact name for die lines at the supplier
  • If a product will potentially be sold in China, assess ingredient lists at onset of project rather than later
  • Here’s a great opportunity to improve your operating schedule/short cutting ideas…
  • Sharing the project schedule with the supplier/customer/etc., ensured alignment of activities planned at ABG and supplier/customer/etc., alignment of expectations.
  • Share your risks with the affiliate/customer, involve them in discussing risks and options
  • if we don’t have a second source for raw materials, and we have quality or shortage issues with our only source for those raw materials, it will negatively impact the project
  • If there is a price change in Thailand, update artwork (pricing is listed on artwork)

PROCESS IMPROVEMENT OPPORTUNITIES “This requires a change somewhere in our process”

ACTION: Vocalize at department meeting/forum/ mentee; load into the Lessons Learned repository; assign owner; make change to process or train as needed; communicate resolution

  • Specific sampling requirements should be defined before production begins to prevent potential production delays
  • Projects involve sending our own concentrated raw materials to a supplier for incorporation into another product, we should include a process engineer on the project to help ensure manufacturability
  • Implement an SOP for running shipping tests in the QA environment for all new supplier set-ups
  • We need a better process for including affiliate/marketing feedback on the profile during feasibility
  • We need a more timely process for releasing product after production is complete
  • Identify priorities for document processing and production based on customer input and provide customer feedback on impact changes on planning and execution.
  • We need to do a better batch size estimation based on forecast to improve efficiencies and inventory
  • We need a clear process and owner for all new branch plant setups.

Project Lessons Learned Examples - Exhibit 4


Standardized Lessons Learned Input Form

Exhibit 5 – Standardized Lessons Learned Input Form

Sample of Metadata questions that are answered as each lesson is loaded

Exhibit 6: Sample of Metadata questions that are answered as each lesson is loaded.

View of the repository including the search field

Exhibit 7: View of the repository including the search field

Analyzing the Results

Once a lesson requiring action is loaded, our management team reviews the lesson to determine the next steps. Someone is assigned to address the opportunity if there is not already a team working on it. Although we have only had the process in place for about six months at the time of the writing of this white paper, we have seen significant improvements in our lessons learned process adherence as well as prompt correction and communication of any issues that may be stumbling blocks for later teams. Our project managers are finding it easy to use and other departments are asking to join.

Final Words

A sustainable lessons learned process is achievable if it is fully integrated into the process and the culture of your organization.

“We learn…
10% of what we read
20% of what we hear
30% of what we see
50% of what we see and hear
70% of what we discuss
80% of what we experience
95% of what we teach others.”

William Glasser, 1925

Gide, A. (1891). In Quotes Cafe. Retrieved from

Glasser, W. (1925). In Think exist. Retrieved from

Tress, L. (2010). Encouraging participation in your organization’s lessons learned approach, 1. Retrieved from http://projectconnect/sites/contimp/PLR/Shared%20Documents/Lessons%20Learned/Encouraging%20Participation%20in%20Your%20Organization’s%20Lessons%20Learned%20Approach.pdf

Tress, L. (2010). Lessons learned systems people really use: Study overview. Retrieved from

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

©2011, Suzanne Symon and Melanie Jansen
Published as part of the 2011 PMI Global Congress Proceedings – Dallas, Texas



Related Content