Learning lessons on lessons learned
Chair, Students of Project Management Specific Interest Group
It has been said that “lessons learned” is one of the most important and “value added” aspects of the project management lifecycle. However, it has been reported that it is often the most ignored part of finishing a project. Various reasons have been offered for this phenomenon. This case study will show results of a follow-up survey on project managers’ use of lessons learned and will walk through the prescribed steps of a lessons learned meeting. After which the discussion will be opened up to the floor of participants for suggestions on how to improve the process so that it would be difficult not to complete this part of the project plan.
After observing multiple post-reviews of projects, Busby (1999) recommended the following strategies to those who have to chair a “lessons learned” meeting on a completed project:
- Encourage deep diagnosis. Use cause-effect diagrams if they are likely to help.
- Encourage attention to history. Ask whether similar things have occurred historically.
- Encourage the examination of the bigger system beyond the immediate confines of the project.
- Discourage glib categorization. There is little that cannot be put down to “communications problems” in complex projects, but categorizing something this way is only a starting point to the diagnosis, not a finishing point.
- Plan remedies properly by examining side effects and thinking through the implementation.
- Invite key outsiders to post-project reviews to assist in dissemination.
Accordingly, Busby suggested the way that the projects were closed out in the “lessons learned” meeting were shallow in content and concept, and needed more analysis and planning in order to be of more benefit to the individuals of the project team, the stakeholders, and organization as a whole.
Kotnour (1999) went further by saying that the project management discipline should embody a framework of learning. The learning framework will help the project manager accomplish three goals:
- Deliver a successful project
- Deliver a series of successful projects
- Build capabilities
Kotnour (1999) clearly identified that major problems in the project are the main issue in a “lessons learned” meeting and that typically the process occurs at the end or closing of the project. What is equally interesting is that there is almost an even split between using metrics in regard to defining success and anecdotal data.
Rose (2007), in reviewing Post-Project Reviews to Gain Effective Lessons Learned by Terry Williams (2007), pointed out the following:
Some results may be more of a surprise. Leaning networks and communities of practice were considered important by 89% of respondents, but only 12% were doing it. Lessons learned databases were considered important by 87%, but only 22% were doing it. The main reason for inaction was lack of employee time. This is rather like the old and not-so-funny joke about taking longer to cut trees because you “don’t have time” to sharpen the saw. The research revealed other reasons for inaction: lack of management support, and lack of incentive, resources, and clear guidelines. (p. 100)
In order for lessons learned to be of value to any organization, it is clear that:
- They should be conducted regardless of time constraints
- There is a need for some standardization approaching lessons learned
- There needs to be careful consideration on zeroing in on the cause and effect aspect of issues that arise during the project management lifecycle.
Also, in the case of learning, this author is proposing that the framework can be as generic or as specific as needed in order to learn from the histories of projects, and that regardless of the scope or complexity of the project, a lessons learned meeting should be conducted to add to the organization’s body of knowledge in order to improve their project management execution.
The Case Study
It has been said that lessons learned is one of the most important and “value added” aspects of the project management lifecycle. However, it has been reported that it is often the most ignored part of finishing a project. Various reasons have been offered for this phenomenon. This case study will show results of a follow up survey on project managers’ use of lessons learned and will walk through the prescribed steps of a lessons learned meeting.
Outline Of “Lesson Learned” Case Study Session
- Networking: Exchange business cards
- Each table working in a group
- Problem statement
- “What are the main reasons that projects are not using lessons learned to mature their project management methodology?”
- PMBOK® Guide directions/statements
- Other findings
- Report findings
- Address the reasons for not using “lessons learned”; continue working in groups
- Project unique
- Project “burnout”
- Blame game
- Not part of the culture, “never done”
- Address the reasons for using “lessons learned”; continue working in groups
- Common areas in projects that can be addressed
- Can assist when approaching a new project
- Can assist with avoiding risk in a new project
- Report findings from groups
- Tools and techniques; continue working in groups
- Examine lessons learned templates
- How to avoid the “blame game”
- When should lessons learned be recorded?
- During the project
- After the project
- Both during and after the project
- How to introduce it into organization’s culture
- Sell to management
- Sell to project team
- Wrap-up and group conclusions
Busby, J. S. (1999). An assessment of post-project reviews. Project Management Journal, 30(3), 23-29.
Kotnour, T. (1999, June). A learning framework for project management. Project Management Journal, 30(2), 32-38.
Rose, K. H. (2007). Cover to cover. [Review of the book Post-Project Reviews to Gain Effective Lessons Learned] Project Management Journal, 38(2), 100.
© 2008, Dr. Loran W. Walker
Originally published as a part of 2008 PMI Global Congress Proceedings — Denver, Colorado