Lessons Learned

Introduction

Lessons learned is a project management documentation tool used across the lifecycle of a project to capture risk-causing events such as items which impacted the schedule, component failures, and oversights by the team or the project manager. Lessons learned can also document items which went well, especially those which were unexpectedly positive, such as a new system integration that improved lap times, valuable feedback from design judges, or a networking opportunity with a sponsor. They are experiences distilled from past activities that should be actively taken into account in future actions and behaviors.

Understanding how to properly use a lessons learned tool will improve knowledge transfer within a Formula team and reinforce project management practices, especially when a team is handed off to new leaders as students graduate and move on from the program. "Clan knowledge," information which is held by a group of people and shared as oral lessons, will never disappear, but translating that knowledge into documented information will reduce it.

Many Formula teams are successful in executing only parts of the lessons learned process, illustrating a need to document the process in order to improve outcomes.

Where and When?

Sources of Lessons Learned

Sources of lessons can come from many things, including:

1. Observed events by team leaders or teammates
2. Written or oral feedback from judges
3. Grades and markups on capstone projects
4. Alumni of the program
5. Third party sources, such as other teams or sponsors

It's important for a team member to recognize when information is valuable to be documented as a lesson learned versus in some other way, such as in design documentation or otherwise. From a project management perspective, lessons learned should focus on items which impact cost, schedule, or resources (facility, personnel, sponsorship, etc.).

When to document

Lessons learned are also sourced from various parts of the project management cycle. Many formula teams overlook this, and only generate lessons learned after returning from the competition. Lessons learned should be identified as soon as possible. One approach a team may take is to generate each lessons learned from every team meeting, every month, or every critical milestone. Lessons learned should be identified immediately, but documentation and closure of the lesson should be done on a regular, scheduled basis. This ensures time has been taken to collect data and solve the actual issue, if present, before documenting it.

When to revisit lessons learned

Lessons learned should be revisited frequently after documentation. At the beginning of the next phase of the project, at the start of the new year, prior to competition, or some other critical milestones are great times to read through the documentation and learn.

How?

Lessons learned are generated from a simple process:

Lessons Learned Process

Identify

Identify the issue, comment, recommendation, feedback with a clear title.

Document

Details of the event with as much information as possible. Include data, photos, emails, and other relevant information necessary to communicate the event.

Analyze

Evaluate documentation and identify a solution or way forward.

Store

In a repository or central location for the team to access later.

Receive

Follow up on the lesson at the beginning of relevant phases of the project. This is the step most frequently missed by student teams and by far the most important.

Lessons Learned Session

A lessons learned session focuses on identifying project success and project failures, and includes recommendations to improve future performance on projects. Project managers have an obligation to conduct lessons learned sessions for all projects with both their teammates and the external stakeholders such as the university, sponsors, and families who support the program, especially if the project yielded less than desirable results. The lessons learned session is a very important part of the lessons learned process. If the session is not successful, the organization suffers.

Facilitator

Lessons learned may be generated committee-style in a meeting or over email. It's not advisable to generate a lessons learned document alone. To obtain optimum results, the lessons learned sessions should be facilitated by someone other than the project manager. The project manager has the most intimate knowledge of overarching successes and failures and how the dots are connected, and may impose an unintended bias or leave out "obvious" context on the documentation. Their input is invaluable, but the documentation should be done by someone who needs more of the picture explicitly explained, therefore making it easier for a future reader to understand the relevant context. This session may benefit from the new leadership, rising team members, or a faculty advisor steering the session instead of the existing leaders.

Project Survey and Scope

The person who will be facilitating the lessons learned session should prepare in advance by taking feedback through a survey of the team. The project survey will help the participants to be better prepared to respond during the lessons learned session and will also give them the opportunity to provide input if they are unable to attend.

The project survey should be organized by category. The use of categories will ensure key information is not missed and will later help to focus the discussion. These categories can also inform a standardization of titles, making it easier for a team member in the future to identify which lessons learned are relevant to their research. Standard categories for each project should be defined and additional categories specific to a project can be added. Suggested categories include:

1. Project Management
2. Resources
3. Technical
4. Communication
5. Business Processes
6. Requirements
7. Design and Build
8. Testing
9. Implementation
10. External Areas

These categories can be subdivided into more detailed categories. For example, project management can be divided into the process groups: initiating, planning, executing, monitoring and controlling and closing. Planning can then be further divided into project schedule, risk analysis, etc. A simple approach is to begin with a few categories such as project management, resources, technical and external areas and then add more categories as needed. The project survey should also include specific questions for each category. These responses will be used by the lessons learned facilitator to guide the discussion during the lessons learned session. Three key questions should be included as part of the survey: 1) what went right, 2) what went wrong and 3) what needs to be improved.

A team may benefit by limiting the scope of the lessons learned meeting. Make clear in the planning for the meeting the scope of the lessons to be documented. For example, at a design deadline, only capture lessons learned relevant to the design phase of the project.

Suggestions for Project Survey prompts

1. Where did we deviate from the original project plan?
2. What guidance did we receive by an advisor or judge?
3. Were we surprised in a static event?
4. Were the project goals attained?
5. What went well? Provide examples of successes that happened during or because of the project.
6. What didn’t go well? Discuss unintended outcomes that happened during or because of the project.
7. What might have been better handled if done differently?
8. What recommendations would you give to others who might be involved in future projects of a similar type?
9. What was beyond your control?
10. What things surprised you on the project that were not planned?
11. What things did you anticipate happening that did not happen?
12. What mistakes did you successfully avoid making?
13. What could we automate or simplify that we do repetitively?
14. What skills did you need that were missing on this project?

Take the answers to these prompts, reformat them using the process above, and shape a lessons learned document.

Simplified lessons learned session

For a very simple lessons learned session, a variation of the Five Whys process can be applied. In a team session, ask the question "where did our results differ from our goals or plans?" (this could be both points at competition, delivery deadlines, recruitment results, or financial results from number of sponsors or amount of sponsorship). Using the Five Whys process, you then go through the deviation until you have identified the root cause. This can then be translated into lessons learned.

This is not a replacement for a full lessons learned session, but could be a good start for teams trying to generate more knowledge transfer.

Templates and Further Reading

1. https://www.smartsheet.com/content/lessons-learned-template
2. Download warning: https://www2a.cdc.gov/cdcup/library/templates/CDC_UP_Lessons_Learned_Log_Template.xls
3. https://www.girlsguidetopm.com/lessons-learned-in-project-management/
4. https://www.projectmanagementqualification.com/blog/2019/08/21/lessons-learned/