What is the Actual Cost to Your PMO for not Capturing and Sharing Project Lessons Learned?

This past week was the fifth anniversary of Hurricane Katrina’s devastation of New Orleans.  The commentary on “Meet the Press” stated that it was the largest “man-made” disaster in U.S. history; not the largest “natural disaster.”  Why?  Because at some point in the past, a large (failed) project was undertaken to reinforce New Orleans’ levee system.  This project was supposed to reinforce the levees so that they could withstand the flood waters of anticipated hurricanes and storms.  Unfortunately, the levee system failed during Katrina. 

A new levee system is now being installed by the Army Corps of Engineers.  There are many lessons learned resulting from the previous levees’ failure during Katrina, as well as many years’ data from previous storms and from computer simulations.  These lessons learned are currently being addressed by the design of the new levee system.

What is the actual cost for failure to capture and share project lessons learned?  Aside from the human cost of storms like Katrina, what is the actual “project” cost that is incurred by not capturing, documenting, sharing, and institutionalizing project lessons learned?  How can we get a manageable and actionable handle on the real contribution of project lessons learned on “saving” future project cost?

The answer to this question obviously depends on many factors:  the complexity of the project, the number of systems impacted, the number of dependencies of project info with other like systems, etc.  How can we get a handle on this type of information, and of what value would it be if we were to understand and apply it?

I once studied with a professor whose favorite expression was “Analysis is the Essence.” 

It did not really dawn on me what that statement meant until I encountered some business situations where bad decisions resulted in a failure to meet objectives such as “on time, on budget.”  In these cases, it seemed to me that the logical sequence of events should be “analysis” followed by “rational thought” followed by “decisions to proceed” followed by “actions.”

We all know that while it is easy to recommend to others courses of action, or specific rationale, or well-thought-out research findings, it is very difficult for others to actually follow-up, and to take the recommended courses of action. 

Why is that?  I believe that everyone has a tendency to believe that if they did not think of an idea themselves, then that idea is not of value to their ongoing, daily processes.  And they may also be biased, and emotionally involved in the decision, so that their “rationality” does not shine through.  As is often said, you can clearly lead a horse to water, but you can’t make him drink.  It takes motivation and capability.

People decide to take courses of action based upon recommendations from others based on the credibility that they attach to the advice-giver, and the usefulness of previous directions from that person.  Leaders become leaders because they continually disallow their own thinking in favor of the more qualified thinking of their peers and associates; they have learned over time that their own thinking provides merely one perspective of a scenario that really demands many viewpoints to assess, understand, and take action upon. 

So, how do you get people to embrace project lessons learned–first, as a logical step in the project management process, and second, as a rational, thought-based process to provide information for future decisions about project work?

In the course of assisting project teams and PMOs with developing project lessons learned, I have often encountered a resistance to take the time to develop and capture lessons learned, and to share this information with others.  Emotional entanglement–as well as a lack of motivation in the sense that no immediate reward will be forthcoming (and perhaps that negative consequences may ensue)–often dictates the action or inaction.  And I am sure, if you are actively engaged in project work in a PMO, that you have encountered the same.

So let me suggest another tactic.

There is a cost to be borne by the PMO for not capturing and sharing project lessons learned. 

To get a simple model for this cost, let’s assume a model that is often used to get across the point that introducing changes at various key points in a project introduces additional cost to accommodate those changes.

If a project has, for example, four distinct phases, and if a change is introduced during the first phase that costs $10, that same change may cost $100 if introduced during the second phase, $1000 if introduced during the third phase, and $10,000 if introduced during the fourth phase. 

Now, suppose that a project lesson learned is identified in phase four, and that project lesson learned could impact a change at that point, so that the original change in phase one would cost 0.001 times as much. 

Suppose two or three project lessons learned could be identified for every project.   Thinking in an integrative manner to identify where projects could have been improved at previous project phases can deliver real cost savings.  The point here that you should grasp is not whether the savings is 0.001 times the final cost of the change but that this perspective can yield significant savings to any project, no matter how complex or simple.   Train yourself as a project manager to think in these terms and you will always be able to find significant “opportunities” in lessons learned.

Hard dollar reductions are the result of project lessons learned.

What is the situation in your PMO?  Are project managers willing to share project lessons learned?  Does the organization have a process for documenting and sharing project lessons learned to future project teams? 

I would like your feedback on this subject.  Thank you.