Once is Not Enough
by William R. Duncan
Executive Summary
For those of you old enough to remember, Once Is Not Enough was a trashy 1970s
novel by Jacqueline Susann. What is this racy novel (well, it was racy for
its time) doing as the title of an article on project management? Two reasons:
• The innuendo was intended to grab your attention.
• The phrase aptly summarizes the theme of this article.
What then is the theme? That too many projects do a “lessons
learned” session only once: at the end of the project.
Once is not enough. Lessons learned should be captured:
• As part of the ongoing change management process.
• At the end of each project phase.
Why Capture Lessons Learned?
Let’s start this article the way we would start a project — by
documenting why we would want to capture lessons learned. The
rationale is driven by the nature of projects: projects are undertaken
to create a unique product, service, outcome, or result. Since
each project is unique, it is impossible to predict the exact
course of the project with precision. Each project can be expected
to face a unique set of challenges. But while the set of challenges
is unique, individual challenges recur.
By documenting the
causes of variances, and the thinking behind the corrective action,
we enhance our ability to respond to future project challenges.
We enhance
our ability to deliver every project on time, within budget,
according to spec, and with a satisfied customer.
• Top •
Generally Accepted or Generally Ignored?
If the benefits of capturing lessons learned are clear, why
do so many projects skip this step?
One obvious reason is that project size in any organization
is likely to conform to Pareto’s rule: 20% of the resources
will be expended on 80% of the projects. Although the definition
of small varies by organization, the fact remains that most projects
in most organizations will be relatively small. Smaller projects
tend to have tighter budgets, shorter schedules, and more shared
resources. All of these factors can make the logistics of capturing
lessons learned formidable.
Smaller projects also tend to be managed by less experienced
project managers or by part-time project managers. While these
folks may have the most to learn, their relative lack of experience
also means that they may be less able to analyze their projects,
less able to extract useful lessons.
A less obvious but no less significant reason is frustration.
Fundamentally, a “lesson learned” is a recommendation
for change, a suggestion that someone in the organization should
to do something differently. These suggestions usually fall into
one of three categories:
•
Management of the project portfolio: how the organization creates
and maintains its portfolio.
•
Management of the organizational environment: how the organization
supports projects and project management.
•
Management of the individual projects: how a single project is
run.
Many organizations lack a mechanism for dealing with lessons
learned in the first two categories — these suggestions
require action from above the project manager. For example, one
lesson that I see “learned” over and over is that
the project would have been successful if the promised resources
had been made available in a timely manner. When the same suggestions
and recommendations are documented on project after project,
the project managers get frustrated. Teams get demoralized. If
it gets bad enough, a project manager may — correctly — decide
that a formal review is counterproductive.
The solution to both of these problems is non-trivial — senior
management must be supportive of the process. To be supportive,
they must be active participants. To participate, they must see
value.
• Top •
Using the Lessons
If we ignore Dilbert and operate under the assumptions that
most senior managers are reasonably bright, why would this group
of bright people reject a practice that seems to offer such potential
for improvement? While it’s tempting to argue that our
managers are less than bright, I think the real answer is that
few organizations benefit from the time and effort expended on
capturing lessons learned!
One major cause of such waste is poorly designed access to the
results of the lessons learned sessions. Whether the files are
manual or automated, the primary key tends to be the name of
the project. So if I want to learn more about estimating, I may
need to scan numerous files in hopes of locating something useful.
Wouldn’t it be nice if all of the wisdom about estimating
was filed under “estimating”? My search would be
quicker, more efficient, and more useful. In short, I would be
more likely to use the lessons learned by others because I would
be able to find them.
An effective indexing scheme can also be helpful in garnering
management support. When the project portfolio management and
organizational environment challenges are grouped, change agents
can develop stronger arguments for action.
Another contributor is a lack of strong facilitation skills
within the project management community. Some organizations do
this well (one of my clients requires a facilitation skills course
for all of their project managers); most don’t. A lessons
learned session should be carefully planned and properly facilitated.
Just gathering the team into a room and saying “okay,
what did we learn on this project?” is more likely to result
in a few hours of finger-pointing and recrimination rather than
a constructive analysis of what happened on this project. A well-facilitated
session can also increase the likelihood of senior management
participation by making more effective use of their time
A Rose by Any Other Name
One last point before we get to why you should have more than
one lessons learned session: is “lessons learned” the
right thing to call it?
Well, that is the most widely used term. It is also
a major improvement over post
mortem with its implications of death and dying (who wants
to talk about a dead project?). I also think that it is better
than post implementation review because
that term requires that we do one only at the end of the project.
Lessons Learned, however, does have some weaknesses.
It harks back to the days of elementary school education when
someone
else was responsible for teaching us our lessons. I also think
that it focuses too much on “what was learned” and
not enough on “what will we do with this information.”
For these reasons, I’ve begun to use some terminology
that I believe originated with the US Army. I attended a session
where an Army project manager referred to the conduct of an “After
Action Review” or AAR that was conducted to generate “recommended
improvements.” This terminology is not only more accurate
than the others, but it has the added advantage of separating
the technique (AAR) from the output (recommended improvements).
• Top •
When Should You Do an After Action Review?
There is a major problem when AARs are done only at the end
of the project — the last phase of the project will be
freshest in the team’s memory and will therefore tend to
receive the most attention. And most team members will move on
to the early phases of other projects where the recommended
improvements from their most recent AAR may be less than relevant. We have
a distinctly negative feedback loop.
Instead, we recommend that AARs be done no less frequently than
once per phase:
•
Mistakes made in the early phases can be corrected in the later
phases.
•
Insights developed in the earlier phases will be available
to the later phases.
•
Action on portfolio issues and environmental issues can be expedited.
Finally, you may note that I said AARs should be done “no
less frequently than once per phase.” How could they be
done more often? On smaller or shorter projects, they wouldn’t
be. But on larger projects it may be appropriate to run one after
every major milestone. On every project, it is also appropriate
to try to design your project management processes so that organizational
learning is part of the fabric of your project.
If you make AARs
an integral part of your change control process, you should
see a steady increase in positive results from your projects.
©
2002 William R. Duncan
• Top •
William R. Duncan is a principal of Project Management Partners,
a project management consulting and training firm headquartered
in Lexington, MA USA. He is the former Director of Standards
for the Project Management Institute (USA) and is currently
Director of Standards for the American Society for the Advancement
of Project Management (asapm).
Mr. Duncan has nearly thirty years of management and consulting
experience including five years with a major international consulting
firm. He was the primary author of the 1994 and 1996 versions
of A Guide to the Project Management Body of Knowledge. In addition,
his “process model” of project management was used
to organize ISO 10006, Guidelines for quality in project
management and underlies the Australian Project Manager Competence Standards.
Website: http://www.pmpartners.com
|
