Lessons Learned Too Late Are Not Lessons

July 5, 2011 Dennis D. McDonald

Recently I received a comment on an old blog post from 2006 titled Slide Presentation: “Expertise Management Systems”. In that post I had described the functional working of an expertise sharing system based on using social media and what we used to call “web 2.0” technologies. It just seemed to me to make logical sense to put the elements together given how challenging it usually is to collect and organize knowledge and information via documents and other media created “after the fact.”

Viewed from a point five years later many of the concepts discussed there have found or are finding their way into modern enterprise systems. Sometimes the underpinning technology is part of an enterprise architecture strategy (e.g., wide adoption of platforms like SharePoint or Jive). Sometimes the sharing of expertise arises outside the control of central IT when, for example, employees “vote with their mice” and independently start using tools like Google Docs and Facebook to support their need to collaborate.

Recently I received a question from Mnazir on my old 2006 post questioning its relationship to “lessons learned systems.” (This, together with “best practices,” is something I’ve discussed before; see the post Why “Best Practices” Won’t Fix Federal IT.)

This is what I wrote in my response to Mnazir:

“Lessons learned” is a venerable concept that in my experience usually refers to a post-project assessment of some kind that can hopefully teach others what to do — or not to do — in similar situations. It’s a great idea in theory. One problem is that, if you wait till after a project is completed to review and identify “lessons learned,” you may have already lost opportunities to share experiences with others via more direct social media and collaboration channels.Plus, if you wait till a project completes to document what you’ve learned you may find that your learning is already obsolete and that what users of a “lessons learned” system really want to know is not information about what an old project did but rather what the project participants are doing now as a follow on. My suggestion in such situations is that it may be much more cost effective to make real-time collaboration and networking more available and easier to support.

I’m not suggesting that we stop creating or recording documents and other media to describe the work we do. That’s not the point. The point is, if our goal is to “share expertise” let’s not get too tangled up with systems that are primarily historically focused. Instead, let’s make it easier for people to discover what other people are doing now so that the sharing of expertise and experience — and yes, “best practices” — occurs nearer to real time.