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

PurposeThe purpose of this document is to provide guidance to individuals tasked with documenting lessons learned.

In establishing these guidelines, we are at the same time providing a type of lesson learned language. 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. That challenge is, utilizing lessons learned to drive improvement.

While lessons learned are sometimes positive in nature, the focus of this document is to avoid problems that resulted in negative lessons. Positive Lessons will be addressed in a future write up.

What is a Lesson LearnedThe term lesson learned is used frequently but often misused. The misuse of the term can actually cause frustration and negative responses to lessons learned documentation sources. An end user may actually skip the step of looking at lessons learned because previous searches have wasted valuable time and produced irrelevant information.

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. It is with that in mind that a definition is established for the addition of lessons learned for the Global Lessons Learned site. 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, it is equally important to clarify that which a lesson learned is not.

Lessons Learned and Training Issues:

Lessons Learned are not typically found in:

1. Mistakes made by practitioners who are not following process, 2. Tasks which are not performed to IBM standard, or 3. Unfulfilled commitments.

How do you recognize these? If:

you find yourself restating existing, policy, or process or the event is associated with direction to a performer to “do a better job”, or a client deliverable was rejected because of a disagreement on specifications fulfillment,

Then, you may have identified a training issue and not a lesson learned.

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.

While training may be 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.

Lessons Learned and Known Business Risks:

Risk is an inherent part of IBM’s business. Some risks are considered normal business risk. There may be an inclination to cite these business risks as the root cause of a lesson learned. However, since these risks represent known challenges, the IBM team should have documented mitigating strategies already included as part of their risk management process, eliminating the need to reiterate them as lessons learned.

Example: IBM recognizes that the effort to prepare a solution estimate for a large outsourcing bid is always under a time constraint, is highly complex, and usually contains many unknowns. Since these are known and expected, these are considered by the Global Lessons Learned team as business risks and should be managed as such.

This is not to say that actions should not be taken on the above examples. However, they are not the main focus of the Global Lessons Learned initiative.

Identifying a Lesson Learned

So now that we have defined a lesson learned and described what it is not, let us look at how we identify lessons learned.

The beginning of a lesson is typically rooted in a problem that occurs. This problem may have been identified by a transition team member who discovered that a task did not go as originally planned, an account team member who was surprised by something unique to a customer environment or industry, or a review team who has provided an independent view and highlighted a problem in a report.

Early in the project, it is common to find problems rooted in the estimates prepared by the solution team. This should not be viewed as an indictment of the Solution Teams. The nature of the Solution Design phase is one in which due to business needs, we are forced to make decisions based on limited information. However, we can strive to eliminate repeated mistakes and that is the spirit in which we approach these lessons.

Some of these Solution Design lessons are commonly referred to as cost misses. They come in a variety of ways. Perhaps the solution design underestimated the amount of effort to perform a task. It may be possible that a part of the solution was simply not included. Did these have lessons learned in them? To know for sure, we must perform a root cause analysis (RCA).

RCAs should be done for all Lessons Learned. An RCA may be formal or informal. Formal RCAs take more time and investigative skill. It is most easily performed when the persons who were

Types of RCAs

Formal Root Cause: Use a Formal Root Cause process when required by your Business Units. Support material includes:

Training: Course Code: KL00305GReference Document: RCA Process

Informal Root Cause: Used when a Formal Root Cause is not required.

Reference Document: Root Cause – Quick Reference

involved in the event are available for interviews. Formal RCAs should be performed when the impact is most significant. Some business units establish guidelines for when Formal RCAs must be performed.

Informal RCAs may be used when a Formal RCA is not required. 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.

Once an RCA has been performed (formal or informal), review the issue to determine if it meets the definition of Lesson Learned. If it does, it is time to write the Lesson Learned.

Writing a Lesson Learned

The next step in the process is to document the lesson learned. To do this, go the Global Lesson Learned site to enter your lesson learned on-line. While this document is not intended to be a “user manual” for navigating the site, a few directional statements will be included. For detailed instructions on how to use the Global Lessons Learned site, refer the help screens within the website.

Once you have arrived at the Global Lesson Learned website, click on the “Contribute” tab to begin the process of entering a lesson learned. An IBM intranet ID will be required to enter a lesson learned to allow for future contact. Enter the information on the General Details tab and proceed to the Issue tab.

Documenting the Issue Since you have already completed an RCA, you should be able to articulate the problem. However, take time to think about the best way to communicate the key points. The issue statement should be clear and concise, but also complete.

Do not fall into the trap of simply stating a general category of problem. For example, if you are dealing with a steady state related lesson learned, you do not want to say:

“Joint Verification”

or

“Due Diligence”

Ask yourself how you would communicate this issue to an executive. Describe what was done wrong and why it was wrong. Do not try to hide key facts to protect an individual. Nor should you name an individual either as this will not become part of the lesson learned document. Consider the greater benefit gained by communicating the core issue. Without an understanding of the facts of an event, an effective solution cannot be developed. A factual issue statement will also allow the user to determine the applicability of the lesson to their work.

For example, 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, write:

“When planning for Joint Verification, IBM did not anticipate that the customer locationsto be included in the process included remote sites outside the contracting country.

Time and costs were not included for the travel.”

Documenting the Root Cause

As mentioned in the Identifying a Lesson Learned section, a Formal or Informal RCA must be performed. Regardless of which approach was taken, it is important to include a clear statement of the Root Cause.

When documenting the root cause, a contributor should try to separate the cause from results. This should be easier to do following the completion of an effective root cause. For example, in the case of our Joint Verification issue, you would not say:

Joint verification took to long to perform,

or

Joint Verification was required in more locations then anticipated.

These are results and not causes. Properly done, the RCA should uncover the true root cause. 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.

Estimates are based on one site.

Consider this:

A person may only read the Issue section to determine if your lesson learned has value.

Will they find value?

Documenting the Impact

When documenting the impact, think about the results. But it is not enough to say, the impact was that the process took longer. While that may be true, it is not sufficient for the reader to know how important this is. In our Joint Verification example, we know that Joint Verification took longer then expected. However, you must ask yourself, “what were the actual costs?” Did the event:

1. Increase customer dissatisfaction due to:a. Forcing them to adjust their schedules to accommodate unexpected reviews?b. Adding to customer costs by requiring them to provide unplanned resources at other

locations? 2. Increase the number of hours required by the IBM team, thereby increasing the financial costs?3. 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,

An additional 65 hours over a budget of 120 hours were expended by IBM team members, and

The customer in location ABC was upset with the schedule and complained to the IBM PE.

Remember: An impact should answer how one of the following areas was negatively affected:

1. Customer satisfaction 2. Project Timelines3. Planned resources4. Controlled scope5. IBM’s ability to meet contractual obligations 6. Risk profile7. IBM’s reputation8. Costs

Quiz

Problem: Cannot drive the car.

Which is more likely the root cause?

The wheel is damaged, orThe owner was talking on the cell phone while driving.

Documenting the Remediation

Remediation steps are those activities which can be performed if the event has occurred. It may also include advice on how to reduce the impact if the event should occur.

An example of a comprehensive recommendation for our Joint Verification problem is as follows:

Account Team (post contract signing):

1. Identify: List all outstanding areas that are to be reviewed as part of the Joint Verification project. Include any dependencies or client responsibilities.

2. Plan: Develop a project plan that covers all necessary tasks, milestones, and deliverables. Carefully consider the time estimates when multiple countries are included.

3. Perform: Execute the Joint Verification plan as identified in the project plan.

4. Document: Summarize the results of the Joint Verification process. Include all pertinent information. Examples include baselines, counts, calculations, assumptions (both internal and external), and other related information.

5. Costs: Review all the changes for cost case impacts. Supply revised costs to the Financial Analyst. Engage a pricer, if appropriate.

6. Customer Review: The PE should communicate the relevant results of the joint verification to the customer.

7. Contract: Incorporate the findings into the contract language (via PCR/amendment).

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.

Do not underestimate the importance of providing this information. Frequently, the submitter is often in the best position to answer the question of how this could have been prevented.

When considering this, ask yourself who could have prevented this event. This is not about blaming someone and the document should not include the individual’s name. This is about helping your fellow IBMers (and possibly you) avoid future problems. Adequate time spent reflecting on this will save IBM time and money. It could also help to boost future customer satisfaction.

One last example to reinforce this message with our Joint Verification example is as follows:

Contents for Remediation

Role to perform the activity Timing of the activityDependenciesNecessary communications (one team to another)End to end recommendation (not just for one team)Follow-up activities

Solution Team:

1. Identify: List all outstanding areas that are to be reviewed as part of the Joint Verification project. Include any dependencies or client responsibilities.

2. Plan: Develop a project plan that covers all necessary tasks, milestones, and deliverables. Carefully consider the time estimates when multiple countries are included.

3. Contract: Notify the contract negotiator of the timeframe necessary to perform the Joint Verification, based on the project plan (for example: 60 days, 90 days). Document any client responsibilities that should be included in the contract. Confirm that there is a change management process in place to address required changes based on discoveries.

4. Skills and Numbers: Identify qualified team members who have adequate expertise in the area they are asked to review. (e.g., required technical knowledge, language, and process expertise). Obtain agreement from their organizations to begin at the date required to support the plan.

“An ounce of prevention is worth a pound of cure”

Ben Franklin