14 barriers to lesson learning

Lesson learning, though a simple idea, faces many barriers to its successful deployment. Here are 14 of them.

I posted, back in 2009, a list of 100 ways in which you could wreck organisational lesson-learning. These were taken from my book, The Lessons-Learned Handbook, and represent the many ways in which the lessons supply chain can be broken or corrupted.

Here’s an alternative view.

From the paper “Harvesting Project Knowledge: A Review of Project Learning Methods and Success Factors” by Martin Schindler and Martin J. Eppler, we have a list of 14 barriers to effective lesson learning through project debriefs, drawn from an extensive literature review.

1. High time pressure towards the project’s end (completion pressure, new tasks already wait for the dissolving team).  
2. Insufficient willingness for learning from mistakes of the persons involved.  
3. Missing communication of the experiences by the involved people due to ‘‘wrong modesty’’ (with positive experiences) or the fear of negative sanctions (in case of mistakes). 
4. Lacking knowledge of debriefing methods. 
5. Underestimation of process complexity which a systematic derivation of experiences brings along. 
6. Lacking enforcement of the procedures in the project manuals.  
7. Missing integration of experience recording into project processes.  
8. Team members do not see a (personal) use of coding experience and assume to address knowledge carriers directly as more efficient.  
9. Difficulties in co-ordinating debriefings. 
10. Persons cannot be engaged for a systematic project conclusion, since they are already involved in new projects. 

In those cases where a lessons learned gathering takes place, the gained knowledge is often not edited for reuse, or not accepted as valuable knowledge by others. If debriefings are conducted, there is still a certain risk that the results (i.e. the insights compiled by a project team):

11. are not well documented and archived,  
12. are described too generically or are not visualized where necessary, which prevents reuse due to a lack of context (e.g. it is too difficult to understand or not specific enough for the new purposes),  
13. are archived in a way so that others have difficulties retrieving them,  
14. are not accepted, although they are well documented and easy to locate (the so-called ‘‘not invented here’’-syndrome).