Knowledge Management Guide

Lessons Learned systems

If lessons are being learned from many projects, for example from retrospects and after action reviews, then these lessons need to be collected and stored somewhere where they can be compared, reconciled and the actions assigned. They need to be recorded in a consistent format and stored in a central system. This is often done in some sort of lessons learned database.

Lessons learned databases can be set up for a single project, to store and track the lessons from within the project, or for the entire organisation, to store and track lessons from many projects. Lessons learned databases are common components of a company-wide knowledge management system, and many examples of such databases can be found on the World Wide Web. Unfortunately, they can often suffer from bad structure and/or unhelpful content. If you intend to put together a lessons learned database, the advice below will help you produce something that can help deliver sustainable business performance improvement. Also bear in mind that discipline and patience is required to fill in a database properly, which can be a barrier An effective lessons learned database should be structured according to the needs of the 'knowledge user'.

People who access lessons from the database should be able to find what they are looking for very easily. If they don't find relevant and useful knowledge within a few minutes, they will leave and never come back. Think about the needs and interests of the knowledge user, how the knowledge will be reused, and how you should structure the database to give users easy access to what they need. A common mistake is to structure the database according to how the knowledge was supplied. The lessons might be grouped by project, for example, with all the lessons from a single project being grouped together (sometimes even grouped together in a single document). However, this is of little use to the person who is looking for the lessons. They don't necessarily know the history of previous projects, or what has been learned on which projects; they are more likely to want to find all the lessons to do with a specific activity. They may be looking for lessons about procuring steel pipe, or for all the lessons to do with safety while working at height, or for all the lessons to do with partnering a particular national authority; in other words, lessons to do with the particular issue that they face.

The lessons therefore need to be grouped into a structure, index or taxonomy based on work activity or work process. If there's an existing structure of process ownership, then the taxonomy in the lessons database should follow this. If there's no existing taxonomy, then you have to get together with some of the functional experts in your organisation and build one. Make the taxonomy simple; don't make it more than two or three layers deep.

Typical data entry fields might include text fields for describing the lesson, and a series of additional fields for metadata. The text fields include: " context " description of the event " root cause " lessons identified " suggested action. When lessons are identified through a retrospect or after action review, you will find that the structure shown above follows the discussion that will have happened during lesson identification. The five questions of the after action review correspond completely to these five text fields. The advantage of having a template such as this one for submitting lessons is that it will prompt the person who is entering the data to think hard about what advice they want to give to the knowledge user, and about how they should categorise the lesson so that it can be found easily. After that, data entry is largely a question of selecting options and filling in boxes (even though there is no guarantee that this will ensure quality data input).

In transferring knowledge, as in so many other applications, a picture is worth a thousand words. A lessons learned database that transfers lessons only in text misses a huge opportunity. The originator of the lessons should be able to attach photographs, diagrams, audio recordings or video files, whatever he or she needs in order to demonstrate the lesson. For example, in offshore operations nowadays the drilling crew will frequently keep a digital camera handy, and photograph equipment before and after it is used. Whether operations go well or badly, the photographic record can often be very valuable in transferring knowledge to other teams. In a construction setting, it may be very useful to have photographs taken during construction, or it might be useful to be able to attach engineering drawings to the lessons database. In a consulting organisation, it may be very useful to attach PowerPoint slidesets from successful pitches to clients. Databases of safety lessons in particular should be set up to take photographs, as photographs of accidents and near misses can be extremely powerful ways of alerting others about danger and risk.

One of the biggest hurdles in any knowledge management system is getting people to look for knowledge, advice and lessons. No matter how well structured and searchable the lessons learned database may be, this will not help if people don't go to the database in the first place. However it may be possible to set up a 'push database', which will forward lessons to interested parties, rather than requiring them to go and search. SharePoint, for example, allows individuals to subscribe to be notified of new items, and this functionality allows lessons to be immediately forwarded to people with an interest in a particular topic.

The most important person to push the lesson to is whoever is accountable for taking action as a result, whether this is a process owner accountable for updating of process, or somebody accountable for fixing a problem. It should be relatively straightforward to set up the database so that it sends a notification to this accountable person, by email or via an RSS feed. The process owner should certainly be notified about any lessons related to his or her specific process, whether they have any actions to take or not. In addition, it goes without saying that the database should be searchable.

Searches should be possible on many fields, as well as through free text. Ideally the free text search should be semi-intelligent, and should compensate for different spellings and descriptions of the same thing. Also people can search for pending lessons for which they are accountable, to remind themselves of actions they need to take. Or the lesson learning coordinator can search to find out how many lessons are pending, how many are completed, and how many are awaiting validation. The lessons database then becomes a source of tracking metrics, to track the usage of the learning system.