Project performance management systemContinuous improvement is a feature of most current quality systems. The idea being thathumans learn from doing - learn from their mistakes and from their successes. Since thework under quality control is being performed by humans, the processes, procedures, andmethods 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 forimprovement. Learning to use oven mitts on pots and pans being moved on the stove wasborne of the need to avoid the painful burns incurred when the cook tried to move a hotpot with her bare hands. When were rewarded for our mistakes we tend not to learnquickly. Let me give you an example of what I mean by rewarding mistakes. In amanufacturing environment production benchmarks may be set using a weak process orprocedure and the worker is paid to meet those benchmarks. The processes andprocedures tend not to be improved in that case because there is no pain involved in usingthe 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 projecthave to be formally identified, acknowledged, analyzed, and improvements identifiedbefore we can improve our performance. This is especially true in the world of projectsbecause the team moves on after project completion. The lessons may be painful and thecompulsion to learn may be strong at the time but without a formal means of organizingthe learning, the improvements that come about because of the ability of the teammembers to learn from their mistakes (or the mistakes of others) is lost. Lessons Learnedsessions 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 stepfurther than that. They recognize things that went well and organize them in the samefashion so that they become repeatable.The first step in implementing Lessons Learned for the project is to schedule LessonsLearned sessions. Lessons Learned tend to be the most effective when they are conductedimmediately after a painful failure. Obviously, attempting to schedule these sessions forthe entire project team after each individual mistake would be impossible so there are 2solutions available to the project manager: schedule team Lessons Learned at strategicpoints throughout the project, and instill a "Lessons Learned" culture in the project sothat team members capture their lessons and share them with the rest of the team withoutyour involvement.There are a wide variety of strategic points available to you for implementing a LessonsLearned session. The approach, passing, or failing, of a Gate is an ideal time to hold asession. You can also hold sessions at intervals that coincide with the iterations of aproject done using an iterative approach. You can hold sessions at your weekly projectreview meetings, if you can trim down the process so that it does not consume too muchtime. 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 aLessons Learned schedule that will provide both types of benefits and that will fit wellwith the project schedule. Dont get carried away and schedule so many sessions that theteam 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 orwent right. The backbone of a good session is the way the information is captured andprocessed so choose a good template that captures all the relevant information about thelesson. There are 3 categories of information that the form should capture: the thing thatwent well or went wrong, why it went well or wrong, and things to do to avoid themistake or repeat the success. The form should also be uniquely identified and there maybe other, administrative, information you wish to capture.The team must be educated in the reasons for doing Lessons Learned and what isexpected from them. The project status review meeting you hold with the team is an idealopportunity to educate them in the process and acquaint them with the template and howto fill it out. Try sending out a brief description of the benefits of Lessons Learnedsessions and how they work in an e-mail before the meeting so the team will be ready todiscuss Lessons Learned in your meeting. An important part of your communication willbe how the information gathered from the Lessons Learned session will be used toimprove project performance.The team member must complete the portion of the Lessons Learned form that describesthe event. Encourage them to complete this section of the form as accurately andconcisely as possible. Specifics as to time, place, the task being performed, tools,processes, procedures, and techniques are helpful. Avoid using the form as a personalattack on a team member who may have made a mistake. The reporter should alsoprovide 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 andencourage better recommendations. The reporter should also complete therecommendations section if they have done analysis themselves.Your job as project manager is to facilitate the Lessons Learned session. You shouldgather all the Lessons Learned, uniquely identify them and communicate them to theteam in advance of the session. Collating the Lessons will be helpful when discussingthem. It is normal to receive several Lessons Learned forms when an event happens thatimpacts multiple members of the team. Establish the meeting rules for the session. Theserules should include avoidance of finger pointing and any other general meeting rulesestablished for the project. Begin the discussion by reading the description of the eventfrom the Lesson Learned form. You can do this yourself or have the author do it. Theauthor 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 theteam to verify the reason or offer an alternative reason if they reject it. Ask the team tobrainstorm a reason if one was not provided. Record the reason when the team providesone or changes an existing one.
The team must analyze the event and the reason for the event in order to identify theactions that must be done in order to avoid the mistake or repeat the success. The team islikely to provide you with more than one action in many cases depending on theirindividual experience, skill, and prejudices. There is no reason a Lesson cannot spawnmore than one action but look for actions that are incompatible and ask the team forconsensus in that case. Recommendations should be verified to ensure they address thereason the event happened and are feasible. Capture the recommendations in the formwhen the team finalizes their brain storming. There may be cases when the team isstumped and cannot brain storm a recommendation that would be effective in addressingthe reason for the event. You may want to discuss that Lesson with an SME (SubjectMatter Expert) after the session to identify an effective recommendation or simplyarchive the Lesson with the other Lessons Learned for a future project, or future phase ofthe current project.Having the team prioritize the recommendations is an additional step you may want totake to get maximum benefit from the process. You wont always have sufficient budgetor time to implement all the recommendations from the session so let the team guide youin determining where the project could get the best bang for the buck. You should also letthe team know that the project might not have the budget or the time for even the highestpriority recommendation.Use interviews when a brain storming session with the team is not possible. Thisapproach will be considerably more time consuming than the brain storming session soencourage the reporter to complete as much of the form as possible. Interview thereporter and verify the "Why it went well/wrong" information if it is provided. Elicit theinformation 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 theproblem has been identified. The next step is to analyze the problem and determinerecommendations to avoid it, or repeat it, next time. Dont be put off if the reporterdoesnt have a recommendation ready for you, take the Lesson and consult with an SMEor simply ignore the recommendation for the time being. The information you gatherfrom 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 Learnedrecommendations. The recommendations wont always result in changes to your project,especially where they apply to work done in the past which wont be repeated on theproject. You also wont be able to implement all the recommendations that do apply toplanned work in your project; budget and schedule constraints will usually limit these.This is where having recommendations prioritized by the team will help. Implement thehigh priority recommendations first and then lower priority recommendations as time andmoney allow. You will have to provide the prioritization based on your knowledge asproject manager in the absence of team prioritization.
Implementing Lessons Learned recommendations is similar to taking corrective orpreventive action. Depending upon the scope of the additions/deletions/changes to yourproject plan and your Change Management process, you may need to author a changerequest and seek approval for the changes from your CCB (Change Control Board). Closethe communication loop after implementing the changes by communicating thosechanges to the stakeholders and identifying the recommendations that prompted thechange.Lessons Learned form an important part of your organizations knowledge so make surethat they are available to future projects. The way to do this is to index the Lessons andarchive them. You can categorize Lessons in a variety of ways: by project phase, byproject function (e.g. programming, unit testing, system testing), by project group(systems analysts, programmers, QA testers), by process, etc. Choose the set of indicesthat 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 eachLesson Learned so readers can easily spot ones that fall into more than one category. Thistype of approach can be easily supported by using folders in a file system, one percategory or index, and filing a copy of the Lesson Learned in each applicable folder. TheLessons Learned should be categorized, filed, and made available to the organizationregardless of what filing system you decide to use.Perhaps no-one does Lessons Learned better than the airline industry. Mistakes in thisbusiness can not only be extremely costly in monetary terms, they can cost hundreds oflives. In December of 1972 a flight bound for Miami, Florida, USA crashed in the FloridaEverglades killing 103 people and totally destroying the plane. The investigation by theNational Transportation Safety Board (NTSB) uncovered a number of mistakes describedas "pilot error" but the Lessons Learned from this disaster changed the way pilots managetheir flight crews and led to the establishment of a new discipline. Learn more aboutFlight 401, the resulting learning, and how that learning can be applied to the projectmanagement profession by clicking on the following link: Flight 401http://performanceappraisalebooks.info/ : Over 200 ebooks, templates, forms forperformance appraisal.