May 3, 2012

Lessons Learned Database hopper

I like to think of a lessons learneddatabase as a hopper that fills up, empties, fills up, empties, fills up, empties and so on.  This is counter to a view that I find very often which is that a lessons learned database fills up, fills up, fills up, fills up and you use a search engine to find things in it.

Why do I prefer the first description?
For me a lessons learned database is part of a lessons learned process which consists of steps such as;

·         We plan to do something

·         We do something and gain experience

·         We identify learning

·         We decide what to do about that learning and assign an action to someone to carry out that activity

·         The experience is now fully embedded in our process, training material, standards etc

·         We can archive the description of the experience as it is now embedded in our process, training material, standards etc

Why do I prefer this approach; my experience of line management, design, operations, maintenance and even during knowledge management consultancy is that people are very, very busy and unless you make it easy for them to do something they will default either to the way they have always done it (or how they did it in their last company, if they are new to your company) or will ask someone next to them at that moment.  If they have to go to another place (screen, physical library etc) to make use of the experience of the company, they may say they are too busy and not bother.  If however that experience is already built into the documents and processes they are already using, by default they will use the latest experience of the company.  Hence the number of lessons in the lesson learned database goes up and down as things are learned and then embedded in the processes, training material and standards of the organisation.

Why might a company not take the hopper approach to lessons learned?  Well one possible answer is that it is relatively easy to purchase a lessons learned database and mandate that people have to submit their lessons to the database or people have to review the database for lessons that might apply to their activity.  Nice, clean, simple instructions.  The problem is that the database will grow and grow and grow, until perhaps you might not even be able to find that one piece of experience that would make all the difference to what you are about to work on.  The search engine returns so many ‘lessons’ on turbines or hydrodynamics or funding applications or finite element analysis or EU importation regulations or customer segmentation etc that it is of no use to you.

With a hopper approach, you would only have ‘lessons’ that haven’t yet been embedded in the process, training material or standards of the organisation.

No comments:

Post a Comment