What the new ISO 9001really says about KM

I have mentioned here and here the inclusion of Knowledge within the 2015 revision of ISO 9001. The new version of this international quality standard has been published, and we can see the final wording of the Knowledge clause.

The inclusion of Knowledge Management within ISO 9001, 2015 edition marks a huge change within the world of KM. For the first time one of the global business standards makes an explicit mention of Knowledge as a resource, and specifies expectations for the management of that resource.

We can now see the final version of the standard, and the final wording of the relevant clauses.

The new clause (in the English Language version of the European standard) reads as follows:

 Clause 7.1.6. Knowledge 

• Determine the knowledge necessary for the operation of its processes and to achieve conformity of products and services. 

• This knowledge shall be maintained and made available to the extent necessary. 

• When addressing changing needs and trends, the organization shall consider its current knowledge and determine how to acquire or access any necessary additional knowledge and required updates. 

• NOTE 1: Organizational knowledge is knowledge specific to the organization; it is generally gained by experience. It is information that is used and shared to achieve the organization's objectives. 

• NOTE 2: Organisational knowledge can be based on: a) Internal Sources (e.g., intellectual property, knowledge gained from experience, lessons learned from failures and successful projects, capturing and sharing undocumented knowledge and experience; the results of improvements in processes, products and services); b) External Sources (e.g., standards, academia, conferences, gathering knowledge from customers or external providers). 

 The new standard offers the following commentary, which gives a little more guidance on the sort of things that an auditor might be looking for:

In 7.1.6 the international standard addresses the need to determine and manage the knowledge maintained by the organization, to ensure the operation of its processes and that it can acheive conformity of products and services. Requirements regarding organizational knowledge were introduced for the purposes of:

a) safeguarding the organization from the loss of knowledge, e.g. - through staff turnover - failure to capture and share information
b) encouraging the organization to acquire knowledge, e.g. - learning from experience - mentoring - benchmarking". 

We can see from the text above and in the previous section, that many of the common elements of Knowledge Management are implied or specifically mentioned. These include:

• an appropriate system for learning from experience, including the use of lesson learning; 
• an appropriate approach to knowledge retention and reducing the risk of loss of knowledge, including mentoring, tacit knowledge capture, and knowledge sharing; 
• some form of KM audit, benchmarking and/or KM strategy, sufficient to identify the critical knowledge needed to deliver quality products and services, and the main knowledge gaps which need to be filled; 
• a framework (roles, processes and supporting technology) for maintaining knowledge and making it available to the extent necessary.

You can find more commentary on the implications of ISO 9001 for Knowledge Management in our most recent newsletter, available for free here.

The curious case of the forgetting curve

The learning curve is a common phenomenon we see in Knowledge Management. As an organisation acquires more knowledge, their performance increases as they "climb the learning curve".  However without care and attention, the curve can reverse, and become a forgetting curve. Here is a case history where that happened.

I have blogged before about our Bird Island exercise, probably the longest running KM experiment in the world, and about how it demonstrates in a very clear way that Knowledge management can drive performance.

It is like a lab experiment in KM, with very clear learning points.

We had an interesting twist to the game a couple of weeks ago, where we had two people in the class who had done the game before, about 6 months ago. Now you might expect that this previous experience and knowledge would give them an edge.  They ought to remember some of the key design principles from the game, and they should therefore be well ahead of the other teams based on this knowledge.

So I put these two people with experience into the same team, to see if this would happen.

Well, it happened to an extent. The two people remembered some bits and pieces, and these included some high level design principles, and a few tips and hints. However much of the other detail required to succeed had been forgotten over the intervening 6 months. They built a tower slightly taller than the other teams, but one third the height of their performance 6 months previously.

As one of them said in the debrief "a little knowledge is a dangerous thing".

The graph above shows their performance 6 months previously, where the 5 bars on the left represent how they gained knowledge through their previous Bird Island experience. The red line is the learning curve they went through in the game.

The greay bar on the right shows their performance 6 months later, built with the help of a hazy memory and "little knowledge" from the previous exercise.and therefore how much had been lost in the interim. The green line is therefore their forgetting curve.


This result reinforces recognition of the frailty of human memory as a long term knowledge store, and therefore the need to support that memory through some sort of capturing and recording. Even 6 months is too long to leave knowledge in memory alone. We need to be capturing it as we go, even as an aide memoire, otherwise we lose it.

Or even worse, we retain a little knowledge, and find that it is just enough to be dangerous.

How KM governance evolves as KM becomes embedded

One of the KM elements we looked at as part of our 2014 global KM survey was KM Governance. 

We asked the respondents to identify which of 12 KM governance elements they applied as part of their KM program.  we also asked them to assess the level of maturity of their KM program.  Among other things, this allows us to see how KM governance evolves as a KM program becomes more mature.

The 12 incentives were as follows (listed roughly in order of application).

• Knowledge Management Strategy
• Defined Approach to KM (eg Knowledge Management Framework)
• Senior KM champion
• KM reference materials
• KM training
• KM Vision
• KM Champions within divisions and organisational units
• KM Success Stories
• KM metrics
• KM Policy or equivalent
• KM Business Case
• Incentive system

The maturity levels were as follows:

• We are investigating KM but have not yet started 
• We are in the early stages of introducing KM 
• We are well in progress with KM 
• KM is embedded in the way we work

The figure above shows how the use of these elements varies as KM maturity increases.

Firstly every element increases in use from the "early" stage to the "well in progress" stage. The increase is greatest for the KM Success stories (unsurprising, as you need to be in progress in order to deliver success), and least for the KM business case. Although business cases are uncommon, they tend to be developed early.

It is more instructive to see the change in governance elements from the "well in progress" stage of active KM implementation, to the "fully embedded" stage.  You can see some of the changes from the graph above, but to make it easier to see, the graph below shows the percentage change in each governance element between "well in progress" and "fully embedded".  These are analysed, with some suggested explanations, below

The following governance elements increase considerably as KM becomes embedded

• KM reference materials and training, needed to support the knowledge workers
• KM success stories and metrics, needed to keep the focus on KM
• KM strategy, KM policy and KM Framework, needed to define the way in which KM is expected to be applied

The following governance elements neither significantly increase nor decrease in application as KM becomes embedded (both of these are replaced, to an extent, by the Strategy, Framework and Policy)

• Senior champion
• KM vision

The following governance elements decrease as KM becomes embedded

• Separate KM incentive system, as this should now be subsumed into normal business incentives
• Separate KM champions, as there will now be defined KM roles in the business
• A KM Business case. Once KM is embedded, the time for a business case is past. 

How to give knowledge shelf-life

The best knowledge is always the freshest, but sometimes we need to preserve knowledge for longer term use. How can we do this, without losing the freshness?

Canning Tomatoes by thebittenword.com on Flickr

Every cook knows that it's best to cook with fresh tomatoes. There is nothing sweeter that a fresh tomato, still warm from the sunshine, picked fresh from the vine.

However a fresh tomato does not stay fresh very long, and if we want to cook with tomatoes long into the winter, we need to find a way to preserve them for the longer term.  Hence the effort invested by many a gardener/cook standing over a hot stove, canning produce for the winter.

Canned tomatoes do not have the same quality as fesh, but we can use them in january when the snow is on the ground and the tomato vines are part of the compost heap.

The key, however, is to preserve them properly. Poorly canned tomatoes can be a source of botulism and food poisoning.

Knowledge is like tomatoes.

The best knowledge is also the freshest. Tacit knowledge - knowledge held in the head - has context, it has depth, it has vibrancy. It lives in practice, grows with practice, and is transferred through conversation in communities of practice.

However if it is not kept alive in continued practice, this knowledge loses its freshness

Imagine a task where there is a gap in practice - where we do the task once, then several months pass before we do it again. During this time, the human memory starts to leak. It starts to reinvent the past, and forget details. It's fallibility becomes apparent, and the three Gorilla Illusions start to work their destructive spell. The tacit knowledge loses its freshness and may go bad.

We need to preserve this knowledge for the future, which is where explicit knowledge comes in - knowledge which has been documented and stored in order to give it some shelf-life.

Explicit knowledge is always a second-best to tacit knowledge.  It does not have the same quality, the same freshness, as tacit knowledge.  However it has shelf-life and it has longevity. Its reliability in the longer term offsets many of its impediments, and the checklists, the wikis, the knowledge assets become our primary source (or at the very least, back up the tacit knowledge and fill in the gaps)

Our challenge then, as knowledge managers, is to recognise where knowledge must be tacit and where it must be explicit; and where it has to be explicit, to capture it with the maximum of context, the maximum of depth, and the maximum of life.

Like the gardener standing over the hot stove, preserving knowledge for the future is an investment in time and effort, and must be done properly if the knowledge is to be usuable again in the future.

The knowledge interchange system

Knowledge is derived from activity, and re-used in activity. However the path between the two is not linear, and needs some form of "knowledge interchange system".

image by stockarch - stockarch.com

Knowledge is generated in operational work, which very often takes the form of projects. In projects, people from many disciplines come together to deliver an objective or to create a product.

Knowledge is re-used in projets.

However in its journey from project to project, knowledge is handled and managed using a different dimension. This can be

• the dimension of Practice - where knowledge is discussed in communities of practice, complied into practice guidance, and stewarded by a practice owner (subject matter expert); 
• the dimension of Product - where knowledge is discussed in product focused communities, complied into product guidance, and stewarded by a product lifecycle manager, or product line engineer;
• the dimension of Customer - where knowledge is discussed in customer-based communities, and stewarded by a key account manager.

Whichever of these three dimensions best fits your your corporate context, knowledge needs to be taken from the project dimension, managed in the practice/product/customer dimension, then returned to the projects.

An example

Let's look at lesson learning in a practice based organisation - a construction company.

• Let's imagine Project A has generated some excellent learnings about contract management, safety, and site survey
• Let's imagine Project B has generated some excellent learnings about mobilisation, safety, and piling
• Let's imagine Project C has generated some excellent learnings about piling, steelwork construction and contract management.

If we leave the lessons in the project reports, effectively filing the knowledge in a project dimension, then future project wishing to find lessons about mobilisation, or piling, or contract management, need to read each project report to see if there are relevant lessons.  That's not difficult if there are only 3 projects and only 6 topics, but once it gets to 300 projects and 60 topics, filing the knowledge by project is untenable.

Instead, the lessons management system should tag each lesson by topic, so it becomes easy to find piling lessons, safety lessons, steelwork lessons and so on.

In addition, the lessons management system should route those lessons (eg by email) to the relevant communities of practice and to the relevant practice owners, so they can be notified of new knowledge in their area of practice, and update practice guidance accordingly. 

So the practice owner for contract management (head of Contracts, for example) is notified that Project A and Project C have new lessons. The practice owner for safety (head of Safety, for example) is notified that Project A and Project B have new lessons. And so on.

Then once the practice guidance is updated, the future projects know where to go to learn how best to manage a contract, or how best to construct steelwork.

This is the interchange system

This system is like a railway interchange, shifting knowledge from a Project track to a Topic track.  Without a system such as this, it can be very difficult to route knowledge to its correct destimation, so it can be reused in future. 

Wikis - to edit, or not to edit?

There are two main approaches to Wikis as a Knowledge Management component - providing page editors who act as validators or gatekeepers, or allowing free editing.

Wiki wiki mart by Andjam79 on Flickr

In the first case, the contents of the wiki page can be edited by only a few people, while others can suggest edits, or comment on existing content, by using the comments facility.  

In the second case, everyone has editing rights, and the assumption is that if enough people edit, the wiki is self-correcting and that errors and opinions will not last in the long term.

The second model is often quoted as the Wikipedia model, although even Wikipedia is not so simple to edit. Although everyone can make minor edits, the protocol is to discuss major edits in the article discussion/talk page prior to publishing, and even on Wikipedia there are locked pages that only approved people can edit.

How to decide which model to take

Before we look at each model, we need to consider that knowledge in an organisation generally has three levels of validity.


1. Mandatory, or “Must Do” knowledge. This is the level of company standards, and everybody reading this particular guidance document realises that they need to follow exactly what’s written. If there is a major problem, they need to get in touch with the process owner and discuss it with them, but that the default should be to follow this documentation exactly.

 2. Advisory, or “Should Do” knowledge. This is the level of best practices, and everybody reading this particular process documentation realises that this is current best way to approach this particular process, based on existing company knowledge. However there is always a drive to improve on best practice, and if somebody can find an even better way, then that’s great. So Advisory process is advised, but not compulsory. However if people ignore advisory knowledge and things go wrong, some awkward questions may be asked.

 3. Suggested, or “Could Do”. This is the level of good ideas or good practices that others in the organisation have used, which the reader should feel free to reuse or re-adapt to his or her own context. These good ideas can still save the reader a lot of time and effort, but there is no real requirement to copy them.

Level three is the chit-chat level of knowledge, in social media, discussion forums or meetings, where ideas and opinions are kicked around and solidified over time. There is a validation step to move from level 3 to level 2 (validation by SMEs or a Community of Practice), and another validation step (validation by the company) to move from level 2 to level 1. 

Where wikis come into the picture

The question is - what knowledge do you want to host on your Wiki? Level 3, or level 2?

The KM4Dev community use their wiki mainly as level 3 - as they say

"This wiki is both a working area for the Knowledge Management for Development (KM4Dev) community and a way for us to make our joint work accessible to a wider audience"

Wikis in places like Shell, Pfizer and Conoco use the wiki for level 2. Level 1 knowledge is held in the discussion forums and lessons management systems, and the wiki page editor promotes content to the wiki once it is considered "valid". They make reference to level 1 knowledge by linking to official procedure documents and standards.

Wikipedia, without making this explicit, is primarily for level 2 knowledge. The article discussion/talk pages are where the level 3 interchange happens, and the promotion of major edits to the main page is by "editorial consensus".

Conclusion

If you are using your wiki for level 3 knowledge, then allow everyone to edit.

If you are using your wiki for level 2, then a) introduce a validation step, and b) decide where your level 3 conversations will take place. 

Quantified success story #93 - lives saved through Knowledge Managament

The video below is a KM success story from the Customer Service wing of KM

Ths story is told by Linda Yeardly of eGain customer support software. It describes how rapid access to high quality knowledge allowed a new member of a Gas Utility customer service team to make a call that probably saved many lives.