I agree that closing a project without evaluating the lessons learned is a significant loss of opportunity. Documenting lessons learned is only valuable if the insights gained are accessible and embedded into future workflows. Finding the best format or platform to document and share lessons learned depends on the organization that you are working in, but there are some practices that can be applied across the board. Using a standardized format helps to ensure consistency across projects. This template should contain: what went well or repeatable best practices, what didn't do well or risks and process failures, how those risks were handled or mitigation strategies that were used, and recommendations for future projects. All of this information should be stored in a searchable, organization-wide knowledge management system. From my own personal experience, SharePoint works incredibly well when both working on a project and when looking back at lessons learned in the future. Tagging entries into the system by product type, regulatory pathway, etc. can help to improve retrievability. Another technique that can be beneficial is conducting cross-functional close out meetings where QA, manufacturing, and marketing meet to help generate deeper insights that may not be present in status reports. Recording these insights in the system can help ensure that all perspectives of the project are retained. In regulated environments like medical device development, lessons learned can reduce recurring delays if structured properly and tied back to the design control process. The goal isn't just to record lessons learned, but to build a living library that drives smarter and faster future development. There are certainly more techniques that can be used! Can you think of any other ones that may be useful?

In my experience, the best ways to document and share "lessons learned" or other important announcements is through a tool like Microsoft Sharepoint. Sharepoint is a very useful tool that many organizations use to store useful documentation and have it accessible to employees. The project itself, any isssues, and lessons learned can be documented in a Word document or PDF and then saved to the Sharepoint, then referenced in the future using a document number, title, or being pulled and talked about directly. Either way, Sharepoint is a fantastic tool that can be used for storing and making any document accessible. In addition to this, email is a good way to communicate things or send reminders on a large scale. Relevant employees, like a project management team, can be added to a group and when the previously mentioned "lessons learned" become applicable or a similar project begins and it is important to keep them in mind, the respective document can be shared to the email group. This will send an email with the document to every applicable employee, where its importance can be specified and emphasize. I think both tools like Sharepoint and email are great ways to document and share relevant documentation like "lessons learned" on a larger scale. 

The best methods to store information about lessons learned at the end of the project is through a method by which all team members can contribute to their experiences. This can be in the form of a slideshow presentation that can be formed by one person, however, each team member can contribute to beforehand. This slideshow can be presented in a meeting to go over everyone's thoughts or comments about their own experiences, as well as challenges that the team shared as a whole. This can be done for each project, and a folder can be created where these presentations are saved. Then, with each new project, the team can go over previous obstacles and make note to avoid them. It is important to not only document lessons learned, but also learn from them. 

Capturing lessons learned by using a slideshow presentation or using software like sharepoint is a good idea, but making these efforts to capture the project lessons without working off of them could defeat the purpose of doing so in the first place. These stored lessons should be applied to the project management process directly when reviewing designs and evaluating risk. Ideally, a company should develop a database that contains a majority of the lessons learned on past projects. Maybe something organized by project phase with summaries of lessons learned, with a redirect to sharepoint or slideshows to further explain how to mitigate issues and improve upon the past. Additionally, some companies might find success of short meetings which can allow a project team to learn from what was compiled from previous projects. Active participation in the material will help make sure that teams are encouraged to reflect and build off of their past projects. Visibility to a project team and its members is equally as important as the storage of these lesson learned files.

I think this is a great point. For bigger projects that have a larger impact or cover something new (new line of medical devices for the company or international product), it is very important to document risks and lessons learned so that future projects can take that into account. Something my workplace does is that we have a dashboard where project managers update their current project statuses with risks, milestones, and other information. Once that project is completed, it is saved in that dashboard. This dashboard is sent out and available to all project managers so they can look back at other relevant projects anytime and maybe even contact the projetc managers of those projects.

Lessons learned can also be used to include things discovered during experimentation that can be improved or modified to achieve better or different results. These can lead way to interesting ideas that can be a whole project to study itself. It can also include steps that can make production of a product more efficient or detailed, or even mistakes to avoid making. In other words, the end goal of keeping track of lessons learned should be to have a list of events that can improve the product or help those that make the product understand it more. It may also be used in reverse, where others try to replicate your steps, which will in turn verify the results previously collected.

Closing a project without capturing lessons learned is a missed opportunity, especially in highly regulated and complex fields like medical device development. To make the most of these insights, the key is to document them in a format that is both accessible and actionable for future teams.
One effective approach is to use a standardized Lessons Learned Register—a structured template that includes sections like the issue or success, root cause, resolution or recommendation, and impact. This can be stored in a centralized project management system (such as Microsoft Project, Confluence, or a shared document repository) where it's easy for future project managers and teams to search and filter by category, product type, or phase of development. It’s also helpful to include these discussions in a formal Project Close-Out Meeting and then log the outcomes into a shared knowledge base that becomes part of onboarding for new team members or the early planning stages of similar projects.

I agree not compiling lessons learned is a significant loss of opportunity. My coworkers and I have started a little 'what did I learn this month' lunch group where we sit and talk about new tricks we learned. This little group evolved into a chat channel on slack for the whole department to see. Now, every once and a while we add it to a document with tips and tricks we learned. None of these channels are exactly professional or organized, but they are helpful to skim through for new ideas or if you are having trouble.

I like the ideas about SharePoint and dashboards, but I wonder if the format matters less than when the lessons are captured. If teams wait until the final closeout, a lot of smaller but important insights get forgotten, so maybe short “micro-lessons learned” entries logged at each major milestone would be more effective. That way, documentation becomes part of the workflow instead of a one-time event at the end. I also think tying each lesson directly to a risk ID or design control element would make it easier to actually apply in future regulated projects. Ultimately, the best platform might be the one that integrates seamlessly into existing project management tools, so contributing feels natural rather than like extra paperwork.

Absolutely agree with many of the viewpoints here, meet about it, meet about it, meet about it! The team should have a final Lessons Learned meeting at the conclusion of a project, and the biggest issues highlighted. Everyone should bring their own input to the table--this is how my medical device manufacturing company handles it. However, to catch the smaller details, all team members should be encouraged to document lessons learned along the way in a word doc or similar file.

During project closing, it is indeed important to note the lessons learned to constantly improve processes and address mistakes. Usually, this would be part of the project closing report, where the details of the project are reflected upon, including any points where the project demanded more resources or strayed away from the set budget, whether or not the net profit reached the estimated, and if the project met deadlines. An easy way to document and share the lessons learned would be to categorize the major investments: time and resources, and the outcome, especially how it may have deviated at each major milestone. This could be easier to search and organize on a shared Excel sheet, with categories such as department spending. Another way to organize the lessons learned would be to keep incident reports as it pertains to patterns on specific equipment or processes to look back on for root cause analysis. This can be organized in a Word document and shared as a PDF. Finally, conducting interviews on the project with team leaders, asking specifically about what they would have done differently and common issues they ran into, would be helpful and give more detailed thoughts; this can simply be saved on the Word document as a transcript. That said, when is the earliest chance that companies should review this closing report, and what is the best practice in implementing the lessons learned?

The post highlights an important issue in medical device development. Capturing lessons learned only has value if those insights actively shape future decisions. In regulated environments, documentation drives action. For that reason, the most effective format may be one that integrates lessons directly into existing quality and design control systems rather than storing them in a separate archive.

One practical approach would be embedding lessons learned into formal phase-gate reviews. For example, a design review or transfer approval could include a requirement for referencing appropriate lessons from similar products or similar regulatory pathways․ If an instance of delayed verification due to poor acceptance criteria is experienced, protocol templates or review checklists should be updated․ In this way, reflection translates into procedural improvement.

Another method would involve categorizing lessons by development phase, such as concept, feasibility, verification, validation, and submission. When entering a new phase, the project lead could review documented insights from prior projects in that same stage. That structure creates a repeatable feedback loop instead of relying on memory or informal communication.

This is similar to how pilots study incident reports and near misses before flying to an unfamiliar airport․ In addition to building a historical record, the incidents are often used to update checklists, simulator training, and flight planning․ Medical device organizations could use lessons learned as inputs to operational checklists rather than as optional, post-hoc reading material․

Quantitative monitoring of issues, such as recurring regulatory non-compliances or repeated test failures, would improve learning by revealing areas where process improvements may be necessary․ How can organizations shift lessons learned from passive documentation to mandatory inputs in gate approval decisions?

The closing process group is generally responsible for concluding all activities to formally complete the project, phase, or contractual obligations. The lessons learned are also part of the organizational process assets. The earliest chance that companies should review the closing report is to do it immediately after the project has been completed. The lessons learned should be clear, detailed, and organized to note the major learnings, accomplishments, and recommendations. There are many online platforms and tools to keep these organized and saved. Many groups document what went wrong rather than also looking at what went well. There is a balance between success and failure. What project teams can use to document and share lessons learned can be a digital whiteboard because this allows for an interactive form of communication as an opportunity to learn together. They can also use spreadsheets to note the date, description of accomplishments, incidents, impact, and actions taken as a form of documentation to support organizational learning.

What many project teams fail to do is noting everything down. There are cases where the same projects have the same mistakes over and over again because it was not noted in the first place for the future teams to look at and to not repeat the same mistakes again. With the next project set in stone, during the initiation and planning phase, the project teams should begin implementing the lessons learned at that time. This gives them the time and opportunity to review the lessons learned before jumping right into the project without any prior knowledge or having the risk of repeating the same mistakes. Lessons learned should be mandatory and embedded into the project structure.

What would a project manager do if not all of their team members contributed to the lessons learned?

I believe the most effective way to capture and share lessons learned is through a common digital resource which every member of the team has access to. Examples include a shared digital project management tool or a common company database for project documentation and notes. When lessons are captured and easily accessible, subsequent teams have the ability to go back and identify successful strategies and the challenges experienced by earlier teams.

A second viable strategy is to hold a final meeting or debrief with the team at the conclusion of each project. This allows the team members to discuss their successes, as well as the challenges they experienced and things they would do differently the next time around. Documenting the discussion points and storing them in a common system ensures the knowledge is not lost when the project is complete.

Additionally, I believe that teams should utilize the lessons learned from prior projects. If an organization promotes reviewing the lessons learned from prior projects before beginning a new project, it will enable the team to avoid making the same mistakes, and allow them to grow and improve how they function as a team. Do you feel that organizations typically take the time to assess lessons learned from prior projects or do you feel that many organizations document lessons learned, but then fail to use the documented information for future reference?