Minimise the change lag in Knowledge Management

Knowledge Management should not only be effective, but efficient, with minimal change lag.

There can be quite a lag between the learning of lessons, and the resulting changes to the organisation, and in that time lag - the change lag - there is potential for many inefficiencies and repeat mistakes.

Imagine a project starting up. The project makes decisions, for example on contracting strategy. In the case of contracting strategy, the decision is wrong, and a mistake is made.

A year later, the project conducts a lessons identification event, such as a Retrospect. One of the lessons is on Contracting. The lesson is documented, and put into the database.

A year later, the organisation conducts a regular review of practices and guidance documentation. The knowledge owner (or process owner) for Contracting reviews the lessons database, and finds the lesson. She updates the guidance documents based on the knowledge from the project.

From this point on, all future projects will follow the new guidance and will avoid repeating the same error.

Unfortunately it has taken 2 years for this change to be made.

There is a 2 year change lag, and during that change lag, the mistake may have been repeated many times.

You may think 2 years is unrepresentative, but take the BP Deepwater Horizon incident. This happened in April 2010, the lessons were documented 5 months later, and 26 actions were identified, with closure dates ranging from early 2012 to mid 2012. Now there are many reasons why those actions will take so long to implement (extreme regulatory oversight for example) but that's still a change lag of 2+ years.

Change lag is the enemy of knowledge management. How can we learn more quickly, but still retain effective change management?

• Firstly projects can learn more frequently. They do not need to wait until project-closure to capture lessons - lessons can be identified and documented on a far more frequent basis.
• Secondly, the lesson management system can automatically notify the relevant knowledge owner automatically as soon as the lesson is documented.
• Thirdly, the knowledge owner can be required to respond to a new lesson within a month, or a week.
• And finally, new knowledge can be rapidly shared through the community of practice, without waiting for the change cycle to be complete. Of course this knowledge is not yet validated, but projects can review the lesson and make better decisions as a result.

Maybe through all these means we can cut the change lag from years to months, or even to weeks. And in a rapidly changing business, this can be very important.