KM FAQ

KM Models

KM Processes

* After Action Review
* Retrospect
* Retention Interview
* Learning History
* Peer Assist
* Site Visit
* Knowledge Exchange
* Knowledge Handover
* Business Driven Action Learning
* Lessons Learned
* Knowledge Assets

KM Roles and structures


* Communities of Practice
* Knowledge Managers
* Knowledge Owners
* Knowledge Librarian
* KM implementation team
* KM support team

KM Technologies


* Community software
* Wikis
* Blogs
* Lessons Learned systems
* Knowledge Bases

KM Governance


* Knowledge Management plans
* KM assessment
* KM standards
* KM metrics
* KM performance management

Lessons Learned

The lessons learned process is a key part of KM - where new knowledge and new learnings are identified through activity and review, and incorporated into future work practices. It seems a simple concept, yet many of our clients are unhappy with their Lessons Learned process. Maybe they have a lessons database, but no lessons are coming in. Or they have a lessons database, and it's full of rubbish. Or they have a lessons database full of good quality lessons, and yet nothing ever seems to change, and the same 'mistakes' are made over and over in the business. So why does Lessons Learned seem so difficult to get right?

Nick Milton talks about lessons learned

The answer, it seems, is linked to another of our observations - organisations in which KM "sticks" and consistently delivers business value tend to be characterised by the ability to execute with discipline and rigour.

We are beginning to come to the view that a lesson is not an end in itself. A lesson is a temporary step along the way to a process, or to a process improvement. Therefore a lessons database is a holding-place which feeds a library of best practice - something that forms a temporary home in a workflow, rather than a permanent repository.

Think about a lesson coming out of a Retrospect. What have you learned? Generally you have either learned how to do something for the first time, or you have learned a better way to do something (or of course, if the project was a disaster, you have learned a new way NOT to do something). So the lesson points to one of two actions

  1. Document the way of doing something - ie write a process or procedure, or
  2. Document the better way of doing something, i.e. write a process or procedure improvement, which can then be evaluated and implemented.

This second point - process improvement - is implicit in the third question of the AAR - "why was there a difference between what we expected, and what actually happened". The team followed the process, there was a difference from expectations, and therefore changes need to be made to the process. If there are no differences, then the process works perfectly, and we need to make no changes. You can generalise this by concluding that "Learning has to lead to change". If there is no change, there has been no learning. A lessons learned system needs to feed through into process change, as shown in the figure below. If this cycle is going to work, then we need, as part of our KM system, the following things.

  1. Activity review needs to identify not just lessons, but actions (and the actions have to be executed - see point 5). We see this in the learning system at BP Alaska, where each lesson is accompanied by an action, and by the identification of the document (manual, procedure, guidelines) which needs to be updated. There also needs to be quality control of this step.
  2. The lessons database needs to contain a workflow, ideally automated, where new learnings and process improvement suggestions and actions are automatically forwarded to the relevant process owner. This is built into the system we are helping design at Pan American Energy. The process owner can also validate the lessons, and make sure they are real learnings, not one person's opinion.
  3. There needs to be ownership for each key process, and these process owners need to be held accountable for reviewing all lessons and updating the processes that they own. This is built into the system used by the UK Ministry of Defence Procurement, and process owners who don't update their process are given a "nudge" by a high ranking officer. This ensures follow-through on learning.
  4. Once the process or procedure is updated, the lesson can be removed from the active lessons database and archived as part of the "paper trail" that tracks why changes were made. The active lessons database then only contains pending lessons, which aren't yet incorporated into practices and guidelines, while "closed" lessons are archived.
  5. Action tracking can be incorporated in the workflow, to ensure that the process improvement suggestions that arise from lessons are reviewed, and are closed out.

People seeking knowledge now need to look in only two places for knowledge - the corporate guidelines, procedures and best practices, and the pending lessons. There's no need to wade through hundreds of past lessons, because all the good ideas are already incorporated into the guidelines. Excellence in following through to turn lessons into actionable process improvement is therefore a defining characteristic of learning organisations, and in these organisations we seldom if ever hear the claim "Lessons Learned doesn't work".

See how Knoco can help with your Lessons Learned approach

Knoco newsletter on Lessons Learned

Knoco White paper on Lessons Learned

Blog posts on Lessons Learned

Nick's lessons learned book

A template lessons log is available from our download page

Download our services brochure

Knowledge Management video

Free Knowledge Management Newsletters

Free Knowledge Management tools

Free Knowledge Management white papers

Free Knowledge Management reference guides

Knowledge management models
Contact us

Last updated Aug 2012. Contents Copyright Knoco Ltd.

boyfriend