May 17, 2011 | Author: PM Hut | Filed under: Lessons Learned
Capturing Lessons Learned: Once Is Not Enough
By William R. Duncan
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.
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.
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).
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.
William R. Duncan is the principal of Project Management Partners of Lexington, MA USA. He currently chairs the Board of PMCert, the certification body of the American Society for Advancement of Project Management (asapm). He was the primary author of the original (1996) version of A Guide to the Project Management Body of Knowledge and was one of the founding members of the Global Alliance for Project Performance Standards (GAPPS) which has recently published a framework for performance-based competency standards for project managers.
© 2011 William R. Duncan - http://www.pmpartners.com/
No comments yet.