Common Lessons Learned Mistakes, Misconceptions and Things Left Unsaid

By Rick Edwards and Shawn P. Quigley

Why organizations fail to exploit their own lessons learned.

“There is only one thing more painful than learning from experience and that is not learning from experience”.   – Archibald MacLeish

Lessons Learned – Really?

Too many organizations understand Archibald’s point all-to-well.   Like a ritualistic sacrifice, project team members, project managers and executives review the project’s closing report containing a myriad of “Thou Shall Nots…”, chanting a mesmerizing slogan about learning from past mistakes – and then set fire to the whitebook and watch it burn, never to be discussed again.   “Don’t mention the war”, as they say.

“Those who fail to learn from history are doomed to repeat it”.  – Winston Churchill (among others)

What’s more amazing, is these same clerics that performed this ritualistic burning are shocked when those same mistakes are miraculously raised from the dead and become re-incarnate in the next project, reducing team performance, morale and sapping value.   What these organizations have failed to realize is that a new thinking is needed in order to change this reality.  Reinforcing the same methods, tools and mindsets that caused the mistakes, means you’ll make these same mistakes bigger, faster and more costly.

“We cannot solve our problems by using the same thinking we used to create them”. – Albert Einstein

Lessons Learned and Speed of Distribution

The cause for this lack of use of previous lessons learned is a question of timely access.   Many organizations suffer from not having the right lesson, taught to the right team, at the right time.   Digging deeper, we discover that flaws in the structure by which lessons learned are catalogued impact how well these lessons learned get to their needed use point.  Often, we catalogue these lessons by project (Which project did we see something like this before?).  We might catalogue by team (Who was working on the project when this happened before?).  Finally, we might catalogue it by technology (I’m not using that specific technology, so we won’t have that problem).

Timeliness is the other aspect we discover as we dig further into why lessons do not survive the close of a project.   Often project teams review the lessons learned of a few “benchmark” projects prior to each phase initiation, or worse yet, only at the beginning of the project’s initiation.    This gives ample time for the team to change its make-up, change its direction, or just plain forget (we are all human, you know).

How does your organization catalogue and review its lessons from projects gone by?