1. Project performance management system
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:
2. 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.
3. 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.
4. 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
http://performanceappraisalebooks.info/ : Over 200 ebooks, templates, forms for
performance appraisal.
