Developing Project Lessons Learned as a Strategic Capability for Your Firm

Early in 2011, I predicted that we would see more Program Management Offices (PMOs) focusing on Project Lessons Learned as a primary rather than a secondary focus (as has been the case in the recent past).  My interactions with many PMOs have revealed that more organizations are seeking to close out projects in a more formal, systematic, and documented manner, and that Project Lessons Learned is an excellent framework to follow when closing-out projects.   There is no doubt that those organizations who successfully “convert” Project Lessons Learned into process improvements will gain a competitive advantage.

Here are some other factors that contribute to this trend:

1.  The need to include Risk Management in every aspect of Project Planning and Execution.  Risk can be included as a variable in the Project Lessons Learned framework, especially if applied in a Project Lessons Learned schedule that calls for a review at each of the Phase Gates of the project process.

2.  Web-based tools such as the Microsoft Project 2010 client and server or Basecamp allow Project Lessons Learned to be easily recorded so that they will be treated as just another piece of performance reporting information for a project.

Project managers who fully experience the project process—including the use of Project Lessons Learned—learn and acquire truth, knowledge, decision-making skills, and good judgment. 

There are three primary methods by which project managers may learn these valuable lessons:

First, “reflecting” is the preferred method because it results in the highest value to the project manager.  “Reflection” means focusing attention on or studying an event or outcome to understand its origin and root causes as they apply to new project situations.

Second, “imitating” other project managers’ documented, shared experiences is the easiest method by which project managers may improve their skills.  “Imitation” means to behave in a manner which mirrors the actions or behavior of others.

Third, “repeating” his or her own bad experiences and unplanned or poor outcomes may also result in the project manager developing his or her skills, although this method causes the most pain and, in most cases, creates the least value addition.

These concepts paraphrase Confucius’ fifth-century B.C. quotation concerning “wisdom” and “lessons learned.”  They relate concepts of “behavior,” “actions,” “outcomes,” “experiences,” “pain,” “ease,” “value addition” and “knowledge.” 

Why is it that project managers refuse to accept the reality that it is more painful to keep repeating the same mistakes in their projects, rather than to learn and benefit from the experiences of others? 

Lou Tice teaches us two principles of personal growth and development:

1.  People act in accordance with the “truth” as they perceive it to be.

2.  People move toward and become like that which they think about.

As Lou Tice suggested, project managers who act as if Project Lessons Learned can have no positive impact on their future success, act in accordance with their perceived “truth” that Project Lessons Learned aren’t valuable.  Similarly, many organizations have been reluctant to require their project managers to take the time required to reflect upon their completed projects and to document their Project Lessons Learned—despite the fact that most PMBOK practices suggest that project managers properly close-out projects with an after-action review and documentation of Project Lessons Learned. 

Today, however, I believe that this reality is finally beginning to change.  Many companies have begun to take Project Lessons Learned more seriously, and they are now  interested in closing-out projects with documentation preserving the “knowledge” created by the project, and the “experiences” of the project’s participants.

On the other hand, what do project managers want to do more than anything else when they successfully complete a project?  Those of us who have observed this behavior over time can tell you that overwhelmingly project managers want to get on to that next great assignment, that next great challenge, that next great project.  Rarely do they want to pause and reflect upon what they have just accomplished, or what the organization could gain if they documented and shared their project management experiences. 

So, what should be the driving force for properly documenting and sharing project lessons learned?

We all know that most organizations now recognize that there are certain Best Practices—in both their project management processes and in their business context—that they employ over and over again.  This is to be expected; when an organization experiences a successful outcome using a key Best Practice, the organization is likely to have successful outcomes in the future if it employs that same Best Practice again.  Often these Best Practices are specific to that organization’s culture, and they fit into the project process naturally in the course of executing projects.  Indeed, many organizations are now employing Best Practice intuitively.  Few companies, however, are adept at recognizing and employing their own Best Practices.     

Just like Best Practices have become—no pun intended—Best Practices within many companies, shouldn’t PMOs look upon Project Lessons Learned as having the same potential to lead to “success” in their project work? 

Here is a “process” and “framework” for looking at Project Lessons Learned that will allow the project lessons learned process to become a Best Practice in your PMO. 

What would constitute a “capability based system” for capturing and sharing Project Lessons Learned?

1.  There must be some process or mechanism for sorting out the FACTS in stories, experiences, and anecdotes, versus the ASSUMPTIONS and PERSPECTIVES contained therein.

2.  There must be a recognized “review” process to identify SIGNIFICANT EVENTS and CANDIDATES for Project Lessons Learned. 

3. There must be willingness on the part of project managers and project team members to speak directly, concisely, and with conviction about project events and lessons.  This involves a risk-taking attitude that only comes from developing an internal capability in the organization to acknowledge that Project Lessons Learned add lasting value.

4.  There must be a “review” process which addresses the following questions:

        –What were the Expected Results from the action or behavior of the project team?

        –What were the Actual Results from the action or behavior of the project team?

         –What is the gap between Actual and Expected?

         –What are the Lessons Learned to be captured, shared, and documented?

5.  There must be an internal knowledge-management system (such as, as mentioned above, Microsoft Project 2010 or Basecamp) devoted to storing Project Lessons Learned documentation so that project managers may easily retrieve and apply the lessons contained therein to new projects.

6.  There must be a single person who is the coordinator or caretaker of the Project Lessons Learned process and the knowledge-management system, so that he or she can analyze the documented lessons learned in order to identify any broader lessons learned that may be applied to the policies, processes, and procedures governing the organization’s project management processes.

Once you have mastered these basic elements and gain some experience in applying the process to a number of projects, you can begin to add some sensitivities. 

For example, you could relate Project Lessons Learned to the risks existing when you are developing a new technology concurrent with the project within which the new technology is being applied.  At the outset of such a technology-driven project, you can establish a plan to prove-out the technology as the project progresses.  A lesson learned could then be documented in terms of the risk of the new technology being proved-out successfully during the project.  Such a scheme could introduce concepts such as “controllable” and “uncontrollable” risk.  “Controllable risk” could be associated with those portions of the technology prove-out where there is a high probability of success.

Likewise, you could look at Project Lessons Learned at the end of each major phase of your project, and apply some “integrative thinking” principles.  This allows a reexamination of original “assumptions” for the project and sets the tone for good project planning for future project phases.

Does your organization have a capabilities-based strategy for making project lessons learned a Best Practice?

As a Principal Consultant with BOT International, we are interested in assisting PMOs and project groups with PMO Setup, Project and Portfolio Management (PPM), Governance and Project Closeout and Lessons Learned.  Call on me or email me if you would like more information about our consulting services.