Lessons Learned

Continuous improvement is a feature of most current quality systems. The idea being that humans learn from doing – learn from their mistakes and from their successes. Since the work under quality control is being performed by humans, the processes, procedures, and methods used to perform the work ought to benefit from the same learning process. Although humans do learn from doing that learning is usually proportional to the need for improvement. Learning to use oven mitts on pots and pans being moved on the stove was borne of the need to avoid the painful burns incurred when the cook tried to move a hot pot with her bare hands. When we’re rewarded for our mistakes we tend not to learn quickly. Let me give you an example of what I mean by rewarding mistakes. In a manufacturing environment production benchmarks may be set using a weak process or procedure and the worker is paid to meet those benchmarks. The processes and procedures tend not to be improved in that case because there is no pain involved in using the weak processes and procedures and no incentive to improve on them.

The lessons we learn from our work, including those learned from the work of a project have to be formally identified, acknowledged, analyzed, and improvements identified before we can improve our performance. This is especially true in the world of projects because the team moves on after project completion. The lessons may be painful and the compulsion to learn may be strong at the time but without a formal means of organizing the learning, the improvements that come about because of the ability of the team members to learn from their mistakes (or the mistakes of others) is lost. Lessons Learned sessions are designed to organize the learning that occurs naturally, capture the lesson, analyze it, and convert it into a plan for improvement. Lessons Learned go one step further than that. They recognize things that went well and organize them in the same fashion so that they become repeatable.

The first step in implementing Lessons Learned for the project is to schedule Lessons Learned sessions. Lessons Learned tend to be the most effective when they are conducted immediately after a painful failure. Obviously, attempting to schedule these sessions for the entire project team after each individual mistake would be impossible so there are 2 solutions available to the project manager: schedule team Lessons Learned at strategic points throughout the project, and instill a "Lessons Learned” culture in the project so that team members capture their lessons and share them with the rest of the team without your involvement.

There are a wide variety of strategic points available to you for implementing a Lessons Learned session. The approach, passing, or failing, of a Gate is an ideal time to hold a session. You can also hold sessions at intervals that coincide with the iterations of a project done using an iterative approach. You can hold sessions at your weekly project review meetings, if you can trim down the process so that it does not consume too much time. The benefits of Lessons Learned for projects can be divided into 2 categories: benefits that help the current project and benefits that will help future projects. Choose a Lessons Learned schedule that will provide both types of benefits and that will fit well with the project schedule. Don’t get carried away and schedule so many sessions that the team does not have enough time to deliver the project work.

The first step in the Lessons Learned session is to capture the event that went wrong or went right. The backbone of a good session is the way the information is captured and processed so choose a good template that captures all the relevant information about the lesson. There are 3 categories of information that the form should capture: the thing that went well or went wrong, why it went well or wrong, and things to do to avoid the mistake or repeat the success. The form should also be uniquely identified and there may be other, administrative, information you wish to capture.

The team must be educated in the reasons for doing Lessons Learned and what is expected from them. The project status review meeting you hold with the team is an ideal opportunity to educate them in the process and acquaint them with the template and how to fill it out. Try sending out a brief description of the benefits of Lessons Learned sessions and how they work in an e-mail before the meeting so the team will be ready to discuss Lessons Learned in your meeting. An important part of your communication will be how the information gathered from the Lessons Learned session will be used to improve project performance.

The team member must complete the portion of the Lessons Learned form that describes the event. Encourage them to complete this section of the form as accurately and concisely as possible. Specifics as to time, place, the task being performed, tools, processes, procedures, and techniques are helpful. Avoid using the form as a personal attack on a team member who may have made a mistake. The reporter should also provide as much knowledge as possible in the "Why it went well/wrong” category. Information captured in this area of your template will help others with their analysis and encourage better recommendations. The reporter should also complete the recommendations section if they have done analysis themselves.

Your job as project manager is to facilitate the Lessons Learned session. You should gather all the Lessons Learned, uniquely identify them and communicate them to the team in advance of the session. Collating the Lessons will be helpful when discussing them. It is normal to receive several Lessons Learned forms when an event happens that impacts multiple members of the team. Establish the meeting rules for the session. These rules should include avoidance of finger pointing and any other general meeting rules established for the project. Begin the discussion by reading the description of the event from the Lesson Learned form. You can do this yourself or have the author do it. The author should be in the room to answer any questions the team may have about the event. Read the "Why it went well/wrong” description if one has been provided and ask the team to verify the reason or offer an alternative reason if they reject it. Ask the team to brainstorm a reason if one was not provided. Record the reason when the team provides one or changes an existing one.

The team must analyze the event and the reason for the event in order to identify the actions that must be done in order to avoid the mistake or repeat the success. The team is likely to provide you with more than one action in many cases depending on their individual experience, skill, and prejudices. There is no reason a Lesson cannot spawn more than one action but look for actions that are incompatible and ask the team for consensus in that case. Recommendations should be verified to ensure they address the reason the event happened and are feasible. Capture the recommendations in the form when the team finalizes their brain storming. There may be cases when the team is stumped and cannot brain storm a recommendation that would be effective in addressing the reason for the event. You may want to discuss that Lesson with an SME (Subject Matter Expert) after the session to identify an effective recommendation or simply archive the Lesson with the other Lessons Learned for a future project, or future phase of the current project.

Having the team prioritize the recommendations is an additional step you may want to take to get maximum benefit from the process. You won’t always have sufficient budget or time to implement all the recommendations from the session so let the team guide you in determining where the project could get the best bang for the buck. You should also let the team know that the project might not have the budget or the time for even the highest priority recommendation.

Use interviews when a brain storming session with the team is not possible. This approach will be considerably more time consuming than the brain storming session so encourage the reporter to complete as much of the form as possible. Interview the reporter and verify the "Why it went well/wrong” information if it is provided. Elicit the information when it is not provided by asking the reporter open ended questions such as "Why do you think this happened”. This exercise is a bit like a Root Cause Analysis (RCA) session so keep asking why until you are satisfied that the root cause of the problem has been identified. The next step is to analyze the problem and determine recommendations to avoid it, or repeat it, next time. Don’t be put off if the reporter doesn’t have a recommendation ready for you, take the Lesson and consult with an SME or simply ignore the recommendation for the time being. The information you gather from the interview should be recorded on the Lesson Learned form.

The purpose of the exercise is to identify the action items which will be added to the plan, changed in the plan, or removed from the plan in order to implement the Lessons Learned recommendations. The recommendations won’t always result in changes to your project, especially where they apply to work done in the past which won’t be repeated on the project. You also won’t be able to implement all the recommendations that do apply to planned work in your project; budget and schedule constraints will usually limit these. This is where having recommendations prioritized by the team will help. Implement the high priority recommendations first and then lower priority recommendations as time and money allow. You will have to provide the prioritization based on your knowledge as project manager in the absence of team prioritization.

Implementing Lessons Learned recommendations is similar to taking corrective or preventive action. Depending upon the scope of the additions/deletions/changes to your project plan and your Change Management process, you may need to author a change request and seek approval for the changes from your CCB (Change Control Board). Close the communication loop after implementing the changes by communicating those changes to the stakeholders and identifying the recommendations that prompted the change.

Lessons Learned form an important part of your organization’s knowledge so make sure that they are available to future projects. The way to do this is to index the Lessons and archive them. You can categorize Lessons in a variety of ways: by project phase, by project function (e.g. programming, unit testing, system testing), by project group (systems analysts, programmers, QA testers), by process, etc. Choose the set of indices that best suit your project. Each Lesson may be captured under more than one category. To keep the material well organized, maintain a system that uniquely identifies each Lesson Learned so readers can easily spot ones that fall into more than one category. This type of approach can be easily supported by using folders in a file system, one per category or index, and filing a copy of the Lesson Learned in each applicable folder. The Lessons Learned should be categorized, filed, and made available to the organization regardless of what filing system you decide to use.

Perhaps no-one does Lessons Learned better than the airline industry. Mistakes in this business can not only be extremely costly in monetary terms, they can cost hundreds of lives. In December of 1972 a flight bound for Miami, Florida, USA crashed in the Florida Everglades killing 103 people and totally destroying the plane. The investigation by the National Transportation Safety Board (NTSB) uncovered a number of mistakes described as "pilot error" but the Lessons Learned from this disaster changed the way pilots manage their flight crews and led to the establishment of a new discipline. Learn more about Flight 401, the resulting learning, and how that learning can be applied to the project management profession by clicking on the following link: Flight 401