Lessons Learned

How to Write a Lesson Learned

Table of Contents

PURPOSE

WHAT IS A LESSON LEARNED

IDENTIFYING A LESSON LEARNED

WRITING A LESSON LEARNED

Documenting the Issue

Documenting the Root Cause

Documenting the Impact

Documenting the Remediation

Documenting the Prevention Measures

Purpose
The 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 Learned

The 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.

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.

Lessons Learned and Training Issues:

Lessons Learned are not typically found in:
1.
2.
3.

Mistakes made by practitioners who are not following process,

Tasks which are not performed to IBM standard, or
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.

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 IBMs 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.
Types of RCAs
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

Formal Root Cause: Use a Formal Root Cause process

when required by your Business Units. Support material
includes:
Training: Course Code: KL00305G
Reference 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 locations
to be included in the process included remote sites outside the contracting country.
Time and costs were not included for the travel.

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, 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.

Quiz
Problem: Cannot drive the car.
Which is more likely the root cause?
The wheel is damaged, or
The owner was talking on the cell phone
while driving.

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.

2.
3.

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?
Increase the number of hours required by the IBM team, 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,
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.
2.
3.
4.
5.
6.
7.

Customer satisfaction
Project Timelines
Planned resources
Controlled scope
IBMs ability to meet contractual obligations
Risk profile
IBMs reputation

8.

Costs

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.

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.

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 individuals 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:

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.

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, 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.