You are on page 1of 9

Lessons Learned

How to Write a Lesson Learned

Table of Contents PURPOSE 3 WHAT IS A LESSON LEARNED 3 IDENTIFYING A LESSON LEARNED 4 WRITING A LESSON LEARNED 5 Documenting the Issue 5 Documenting the Root Cause 6 Documenting the Impact 7 Documenting the Remediation 7 Documenting the Prevention Measures 8 .

or Unfulfilled commitments. That challenge is. How do you recognize these? If:    you find yourself restating existing. . or a client deliverable was rejected because of a disagreement on specifications fulfillment. Positive Lessons will be addressed in a future write up. The misuse of the term can actually cause frustration and negative responses to lessons learned documentation sources. 2. An end user may actually skip the step of looking at lessons learned because previous searches have wasted valuable time and produced irrelevant information. Lesson Learned Definition Begins with an event that occurred which had an unexpectedly positive or negative result on the sales or performance of a contract which may require a change to a process or behavior. 3. Then. Lessons Learned and Training Issues: Lessons Learned are not typically found in: 1. Establishing a clear definition of what constitutes a lesson learned is critical to providing a consistent resource that can be relied upon to meet the needs of the users.Purpose The purpose of this document is to provide guidance to individuals tasked with documenting lessons learned. It is with that in mind that a definition is established for the addition of lessons learned for the Global Lessons Learned site. or process or the event is associated with direction to a performer to “do a better job”. While lessons learned are sometimes positive in nature. The definition is as follows: Definition: A lesson learned begins with an event that occurred which had an unexpectedly positive or negative result on the sales or performance of a contract which may require a change to a process or behavior. However. In establishing these guidelines. we are at the same time providing a type of lesson learned language. Tasks which are not performed to IBM standard. it is equally important to clarify that which a lesson learned is not. utilizing lessons learned to drive improvement. What is a Lesson Learned The term lesson learned is used frequently but often misused. policy. the focus of this document is to avoid problems that resulted in negative lessons. This is done in order to create a structure upon which to build a method to address what has in the past been a significant challenge. Mistakes made by practitioners who are not following process. you may have identified a training issue and not a lesson learned.

Support material includes: Training: Course Code: KL00305G Reference Document: RCA Process Informal Root Cause: Used when a Formal Root Cause is not required. a simple reminder can be used. The Global Lessons Learned site is incorporating reminders for key tasks where process documents are insufficiently available or additional community awareness is warranted to prevent significant losses. The beginning of a lesson is typically rooted in a problem that occurs. they are not the main focus of the Global Lessons Learned initiative. This problem may have been identified by a transition team member who discovered that a task did not go as originally planned. This should not be viewed as an indictment of the Solution Teams. Reference Document: Root Cause – Quick Reference . the IBM team should have documented mitigating strategies already included as part of their risk management process. and usually contains many unknowns. Identifying a Lesson Learned So now that we have defined a lesson learned and described what it is not. Some risks are considered normal business risk. However. RCAs should be done for all Lessons Learned. since these risks represent known challenges. we can strive to eliminate repeated mistakes and that is the spirit in which we approach these lessons. or a review team who has provided an independent view and highlighted a problem in a report. However. let us look at how we identify lessons learned. Since these are known and expected. It may be possible that a part of the solution was simply not included.While training may be required. An RCA may be formal or informal. we must perform a root cause analysis (RCA). The nature of the Solution Design phase is one in which due to business needs. it is common to find problems rooted in the estimates prepared by the solution team. However. This is not to say that actions should not be taken on the above examples. They come in a variety of ways. eliminating the need to reiterate them as lessons learned. Formal RCAs take more time and investigative skill. an account team member who was surprised by something unique to a customer environment or industry. these are considered by the Global Lessons Learned team as business risks and should be managed as such. Did these have lessons learned in them? To know for sure. we are forced to make decisions based on limited information. Example: IBM recognizes that the effort to prepare a solution estimate for a large outsourcing bid is always under a time constraint. It is most easily performed when the persons who were Formal Root Cause: Use a Formal Root Cause process when required by your Business Units. There may be an inclination to cite these business risks as the root cause of a lesson learned. Types of RCAs Some of these Solution Design lessons are commonly referred to as cost misses. Lessons Learned and Known Business Risks: Risk is an inherent part of IBM’s business. Early in the project. Perhaps the solution design underestimated the amount of effort to perform a task. is highly complex.

If it does. Some business units establish guidelines for when Formal RCAs must be performed. For detailed instructions on how to use the Global Lessons Learned site. write: “When planning for Joint Verification. Nor should you name an individual either as this will not become part of the lesson learned document. To do this. Do not fall into the trap of simply stating a general category of problem. it is time to write the Lesson Learned. For example. Informal RCAs should still follow a structured process. A method to perform an Informal Root Cause is found in the Informal RCA process document available in the Global Lesson Learned site. Without an understanding of the facts of an event. Enter the information on the General Details tab and proceed to the Issue tab. you should be able to articulate the problem. if the problem is that the Joint Verification process was not adequate because the customer had remote locations that needed to be examined and IBM did not plan on travel for the remote locations to perform the Joint Verification. click on the “Contribute” tab to begin the process of entering a lesson learned.” . take time to think about the best way to communicate the key points. but also complete. if you are dealing with a steady state related lesson learned. Consider the greater benefit gained by communicating the core issue. Once you have arrived at the Global Lesson Learned website. Documenting the Issue Since you have already completed an RCA. For example. refer the help screens within the website. While this document is not intended to be a “user manual” for navigating the site. IBM did not anticipate that the customer locations to be included in the process included remote sites outside the contracting country. go the Global Lesson Learned site to enter your lesson learned on-line. review the issue to determine if it meets the definition of Lesson Learned. The issue statement should be clear and concise. Writing a Lesson Learned The next step in the process is to document the lesson learned. Informal RCAs may be used when a Formal RCA is not required. an effective solution cannot be developed. a few directional statements will be included. A factual issue statement will also allow the user to determine the applicability of the lesson to their work. However. Formal RCAs should be performed when the impact is most significant. Do not try to hide key facts to protect an individual.involved in the event are available for interviews. An IBM intranet ID will be required to enter a lesson learned to allow for future contact. Describe what was done wrong and why it was wrong. Time and costs were not included for the travel. Once an RCA has been performed (formal or informal). you do not want to say: “Joint Verification” or “Due Diligence” Ask yourself how you would communicate this issue to an executive.

. it is important to include a clear statement of the Root Cause. When documenting the root cause. you would not say: Joint verification took to long to perform. a contributor should try to separate the cause from results. The final statement of root cause would appear more like the following: IBM does not prepare a scope for the Joint Verification project during engagement. Therefore. there is no consideration for the number of locations which must be visited. the RCA should uncover the true root cause. These are results and not causes. For example. Properly done. Estimates are based on one site. Regardless of which approach was taken. or Joint Verification was required in more locations then anticipated. in the case of our Joint Verification issue. a Formal or Informal RCA must be performed.Consider this: A person may only read the Issue section to determine if your lesson learned has value. Will they find value? Documenting the Root Cause As mentioned in the Identifying a Lesson Learned section. This should be easier to do following the completion of an effective root cause.

“what were the actual costs?” Did the event: 1. Customer satisfaction Project Timelines Planned resources Controlled scope IBM’s ability to meet contractual obligations Risk profile IBM’s reputation . 3. 3. it is not sufficient for the reader to know how important this is. Forcing them to adjust their schedules to accommodate unexpected reviews? b. Which is more likely the root cause? The wheel is damaged. 4. While that may be true. But it is not enough to say. Remember: An impact should answer how one of the following areas was negatively affected: 1. Adding to customer costs by requiring them to provide unplanned resources at other locations? Increase the number of hours required by the IBM team. Increase customer dissatisfaction due to: a. 6. 7. In our Joint Verification example.Quiz Problem: Cannot drive the car. Documenting the Impact When documenting the impact. and The customer in location ABC was upset with the schedule and complained to the IBM PE. However. we know that Joint Verification took longer then expected. 2. the impact was that the process took longer. think about the results. 2. or The owner was talking on the cell phone while driving. 5. An additional 65 hours over a budget of 120 hours were expended by IBM team members. you must ask yourself. thereby increasing the financial costs? Add travel costs for IBMers? The impact of our Joint Verification problem could be represented in the following way:    The contractual milestone for completion of Joint Verification within 90 days of contract signing was missed by three weeks.

3. and other related information. Adequate time spent reflecting on this will save IBM time and money. assumptions (both internal and external). and deliverables. Supply revised costs to the Financial Analyst. the submitter is often in the best position to answer the question of how this could have been prevented. It could also help to boost future customer satisfaction. calculations. When considering this. counts. ask yourself who could have prevented this event. Documenting the Prevention Measures Prevention Measures are those steps which could be taken before an event occurs which would allow the team to avoid the event. Examples include baselines. Perform: Execute the Joint Verification plan as identified in the project plan. 7. Carefully consider the time estimates when multiple countries are included. Identify: List all outstanding areas that are to be reviewed as part of the Joint Verification project. Include any dependencies or client responsibilities. 6. Contract: Incorporate the findings into the contract language (via PCR/amendment). Frequently. Costs Documenting the Remediation Remediation steps are those activities which can be performed if the event has occurred. if appropriate. Document: Summarize the results of the Joint Verification process. Plan: Develop a project plan that covers all necessary tasks. One last example to reinforce this message with our Joint Verification example is as follows: . Do not underestimate the importance of providing this information. This is not about blaming someone and the document should not include the individual’s name. It may also include advice on how to reduce the impact if the event should occur. Include all pertinent information. This is about helping your fellow IBMers (and possibly you) avoid future problems. Costs: Review all the changes for cost case impacts. Contents for Remediation Role to perform the activity Timing of the activity Dependencies Necessary communications (one team to another) End to end recommendation (not just for one team) Follow-up activities 2. 5. Customer Review: The PE should communicate the relevant results of the joint verification to the customer. 4.8. An example of a comprehensive recommendation for our Joint Verification problem is as follows: Account Team (post contract signing): 1. milestones. Engage a pricer.

Identify: List all outstanding areas that are to be reviewed as part of the Joint Verification project.g. required technical knowledge. Document any client responsibilities that should be included in the contract. (e. 3. . Confirm that there is a change management process in place to address required changes based on discoveries.Solution Team: 1. and deliverables. and process expertise). 90 days). based on the project plan (for example: 60 days. “An ounce of prevention is worth a pound of cure” Ben Franklin Contract: Notify the contract negotiator of the timeframe necessary to perform the Joint Verification. Plan: Develop a project plan that covers all necessary tasks. Skills and Numbers: Identify qualified team members who have adequate expertise in the area they are asked to review. language. Obtain agreement from their organizations to begin at the date required to support the plan. Carefully consider the time estimates when multiple countries are included. 4.. 2. Include any dependencies or client responsibilities. milestones.