Knowledge has an expiry date

Knowledge has a half-life, and therefore an expiry date.

This is the intriguing premise behind a new book by Sam Arbesman, called "the half life of facts". 

The book, described in the video below, focuses primarily on academic facts and on science, and finds a half-life of 44 years, for example, for medical knowledge about hepatitis.

Business knowledge has an even shorter half life.

Probably half the things you knew about your business ten years ago, are wrong now. And expired knowledge, like expired food, is dangerous. It can lead to wrong decisions, wrong judgments, and big errors.

The implication for Knowledge Management is important.

• As well as creating, discussing and storing new knowledge, we need to be able to remove and delete the old knowledge

• Our knowledge bases need a regular overhaul and spring clean, which is why it is better to house them as a wiki - continually updated - than as a folder full of files, many of which become obsolete

• Our lessons systems should be lessons management systems which pass lessons through to completion, and then archive them, rather than passive databases clogged up with lessons beyond their expiration date.

• Knowledge,once captured, needs to be owned and maintained, which means out with the old, as well as in with the new.

I posted a while ago about "knowledge management as gardening", and part of gardening is Pruning.

So be aware of the knowledge half-life, and beware of the knowledge which is too old to be safe.

2 dimensions of Knowledge Stewardship

---

One of the key tenets - probably the foundational tenet - of Knowledge Management is that Knowledge is an asset to an organisation, and must be treated as such.

It follows on, therefore, that someone must "own" or "steward" the knowledge - someone must look after it, and be accountable for ensuring that the value of that asset is realised. Every critical or strategic knowledge topic needs such stewardship.

There are two dimensions to this role of Knowledge Owner or Knowledge Steward.

• Firstly they need to build, plant or nurture the Knowledge-sharing networks and communities of practice who collectively will hold the knowledge, apply the knowledge, and create new knowledge.
• Secondly they need to ensure that the store of explicit knowledge assets exists, is well maintained, and is valuable to the community of practice.

By addressing these two dimensions, they ensure that knowledge is built and applied in both tacit and explicit form.

Knowledge Stewards can take one of three approaches to stewardship, based on the maturity of the knowledge topic, the degree of experience of the community of practice, and the local culture in their organisation.

1. The Knowledge Stewards can personally own the knowledge. They are the Knowers, they hold the expertise and write the guidance and the manuals, while the knowledge workers apply the knowledge.
2. The Knowledge Stewards can quality-control the knowledge and validate it, while the knowledge workers both apply the knowledge and submit new knowledge to the Knowledge Steward for approval and incorporation.
3. The Knowledge Stewards can build and manage the knowledge-creating and knowledge-validating system, while the knowledge is created, updated and validated by the members of the community of practice themselves.

The first model seems very old fashioned nowadays, and the third model seems much more attractive, and is becoming more common (see for example the use of Wikis to develop Army doctrine). However there may still be cases where the first model is appropriate, and the second case is still valid for mission-critical, safety-critical or strategic knowledge topics.

As always in Knowledge Management, you need to accept the principle (in this case, that each important knowledge topic needs stewardship) and then apply the principle in a way that suits your business context.

Three styles of Knowledge flow - centre-out, out and in, or multiflow

---

There are three common styles of knowledge flow that you can see in organisations. We can call them centre-out, out and in, and multiflow.

In our picture here, the red dots are the central group of experts, the white dots are the knowledge users or knowledge workers, and the white arrows are the flow of knowledge.

In the centre-out model, the knowledge is created by the experts in the centre, and "pushed out" to the knowledge workers, in the form of doctrine, work instructions and policies. The centre owns the knowledge - they are the Knowers - while the knowledge workers apply the knowledge - they are the Doers.

In the out-and-in model the knowledge is managed by the experts in the centre. Knowledge is gathered from the knowledge workers, synthesised and validated in the centre, and transferred back out to the workers. There are feedback loops such as lesson learning systems which mean that the central knowledge is always tested against reality and updated regularly. The centre stewards the knowledge and validates it, while the knowledge workers both apply and improve the knowledge.

In the multiflow model, the knowledge flows between expert and worker, worker and worker, worker and expert. Knowledge is created, updated and validated by all parts of the system, and is available realtime. The knowledge is managed and owned by the Community of Practice, while the centre manages and stewards, not so much the knowledge itself, but the knowledge-creating and knowledge-validating system.

The first model seems very old fashioned nowadays, and the third model seems much more attractive, and is becoming more common (see for example the use of Wikis to develop Army doctrine).

However in reality all three models may be needed simultaneously in any one organisation, to deal with different types or different levels of knowledge.

There may be mandatory knowledge, such as knowledge of company law, or knowledge of policies such as anti-money-laundering or anti-corruption policies, which has to be mandated and controlled from the centre.

There may be strategic knowledge, driven by company strategy, which can certainly be tested in the business, with clear (and welcome!) feedback, but which needs to be owned and coordinated centrally and strategically.

There may be operational and tactical knowledge which is owned by the Communities of Practice, and handled within wikis and blogs and discussion forums (and indeed the Army wikis mentioned above were specifically for tactical knowledge).

So it is not as simple as saying "model 1 is old fashioned and rigid and Bad, model 3 is free and liberated and modern and cool and Good".

It is, as is so often the case in Knowledge Management, a case of determining which model is most appropriate for which knowledge.

When knowledge "goes off"

---

Knowledge has a half-life. This is the intriguing premise behind a new book by Sam Arbesman, called "the half life of facts". 

The book, described in the video below, focuses primarily on academic facts and on science, and finds a half-life of 44 years, for example, for medical knowledge about hepatitis.

Business knowledge has an even shorter half life.

Probably half the things you knew about your business ten years ago, are wrong now. And old knowledge, like old food, is dangerous. It can lead to wrong decisions, wrong judgments, and big errors.

The implication for Knowledge Management is important.

As well as creating, discussing and storing new knowledge, we need to be able to remove and delete the old knowledge.

Our knowledge bases need a regular overhaul and spring clean, which is why it is better to house them as a wiki - continually updated - than as a folder full of files, many of which become obsolete.

Our lessons systems should be lessons management systems which pass lessons through to completion, and then archive them, rather than passive databases clogged up with lessons beyond their expiration date.

Knowledge,once captured, needs to be owned and maintained, which means out with the old, as well as in with the new.

I posted a while ago about "knowledge management as gardening", and part of gardening is Pruning.

So be aware of the knowledge half-life, and beware of the knowledge which is too old to be safe.

Three levels of Knowledge - Must, Should and Could

---

I am often asked "Does knowledge management have to be top-down, command and control? Should the company be telling people what to do and how to do it? Why can't knowledge just emerge, from the bottom up?

The answer, as usual, is that it is a question of Horses for Courses. There is some knowledge which can and should "bubble up from the bottom", and there is some knowledge that needs a top-down validation (but even in this case, this tends to be top-down validation of bottom-up contribution).

Let's look at the second case, as this is the one that people end to struggle with.

Here we are looking at knowledge that is mission critical, or related to safe operation. Knowledge like how to run a nuclear power plant, or an oil refinery, or how to fly a jumbo jet. we already know from incidents like the Longford Refinery disaster that in such situations the company is legally obliged to ensure that operators have access to the knowledge they need to do their jobs, and that "operator error" is no excuse if the knowledge is absent.

Any organisation will then put in place structures to make sure that people with mission-critical jobs have access to the best knowledge, compiled from the best sources, and will require validation that this is happening.

I recently presented about this, and mentioned the role of the "Practice Owner" - the person who acts as custodian or guardian of an area of knowledge. There were some immediate questions - "who gives this person the right to tell others what to do? What if they are wrong?". The answer is that the person speaks on behalf of the community of practice (and is often appointed by the community), and acts as a check and validator on the community process.

If the community members find a problem with company procedures then this is the person who checks that out, runs the management of change, and signs off (on behalf of the community and the company) on the new process.

People sometimes ask, why doesn't the community collectively sign off? The answer is, for company critical knowledge, you need checks and balances. Otherwise you can imagine the courtroom conversation

"What made you think that the procedure you provided Mr X, which resulted in the destruction of the laboratory, was safe?"
"Well your honour, it got 20 Likes in the company knowledge system"

When the company is responsible for providing correct knowledge, the company needs that validation process in place, which goes beyond star-ratings and Likes, and requires proper review and sign-off.

What you generally end up with, in high reliability organisations, is three levels of knowledge;

• There is the "Must Follow" knowledge, which is enshrined in the company standards, and which has been signed off by the Practice Owners (on behalf of the Community) as being the only safe or effective approach. Examples might be the operating procedures for the above-mentioned Nuclear plant, or the in-flight checklists for the Jumbo Jet (and which were missing, incomplete or inadequate at Longford Refinery). This is the top down knowledge.

• There is the "Should Follow" knowledge, which is represented by "Current Best Practice", and which the community collectively agrees that is the best way to do something, and which should be used as a default unless you have a good reason to do otherwise. These are the contents of the Community Wiki, or the community knowledge base, and there will be generally some form of validation procedure to determine that this really is the best knowledge available at the moment.

• Finally there is the "Could Follow" knowledge, that represents the good ideas, good examples, tips and hints, and templates. This is generally the content of the community forums and the community Yammer streams, and has the Likes and the star ratings. This is the bottom up knowledge, bubbling up from below and attracting rating and commentary as it goes, until it passes a validation step to become "Should Follow". 

The Practice Owner - an enabler, not a bottleneck

---

I was presenting at a client internal conference recently, together with Etienne Wenger. Etienne was presenting great material on Communities of Practice, while my presentation was on Knowledge Management Frameworks.

In one section of my talk, I introduced the concept of the Practice Owner, which I described on the accompanying slide as follows;

“Practice Owner” 

•  Accountable for “Owning and managing,” or "Acting as Steward" for, defined areas of critical knowledge for the organisation 
• Validates (or rejects) new knowledge 
• Writes or updates practices, or delegates this within the CoP
• Broadcasts new knowledge, or delegates this within the CoP 
• Often the same person as the CoP Leader

Those of you who follow this blog regularly will be aware of this role - I see it as one of the pivotal KM roles in an organisation. However this slide generated a lot of negative discussion. 

• "Will this role not be a bottleneck for learning" people asked.
• "If you put one person as arbiter for knowledge, will they not just decide what they want, and stifle discussion?"

This took me aback a little, as I have only ever encountered this role as a positive, enabling, facilitating and mediating role. Perhaps I had described it wrongly? This is where Etienne stepped in.

"The important thing about this role" he said "is its connection with the Community of Practice". He saw this role as a Stewardship role (and he liked the term Steward) as being answerable not only to the organisation, but also to the Community of Practice. By linking Practice Owner and Community Leader, the Practice Owner then speaks on behalf of the CoP, and co-ordinates CoP knowledge into a single place. The practice Owner mediates and facilitates the process of drawing together Community Knowledge into a Community Resource which the CoP can trust and rely upon.

To this extent, the Practice Owner is as much a servant of the community as they are a leader, and play a stewardship role both on behalf of the CoP and on behalf of the organisation. It is only when you divorce the Practice Owner from the CoP that troubles arise.

Roles in the Knowledge Management organisation

---

A fully mature KM organisation will contain several recognised KM positions in order to ensure and facilitator the creation, transfer and re-use of knowledge. Some of these are listed below. Sometimes several of these roles are combined into a single position.

Note that, in this list, I am assuming that the KM organisation is in place, so do not include any task force, or KM implementation team. I have not given names to these roles - each company seems to use a different set of names (some examples are given). Not all roles are required in every organisation - many are optional. Each company will need to do their own knowledge management organisational design - look at the list below as a series of options, not a template.

• There is one role, to monitor, champion and support Knowledge Management for the entire organisation. This can be referred to as the Chief Knowledge Officer, and this role is described here

• The CKO can lead a small team to help with the support activity. The role of that team is described here.

• There is often a senior management role to which the CKO reports, who provides steer, high level support and resource to Knowledge Management, This could  be known as the management sponsor for KM.

• This sponsor could be supported by a high level steering team. The role of this team is described here.

• There can be a similar role in each business division, to monitor, champion and support Knowledge Management within that division. The Samsung version of this role is described here - they call it a Knowledge manager role, other companies call it KM Champion. In Legal firms, this role is often taken by paralegals. Our view of this role is here. 

• In the US Army, there is a role within each operational  unit, which is less about championing KM, and more about acting as the conduit for lessons. This role is described here, and is called the Lessons Learned Integrator.

• In project-based organisations, that run major capital projects, there may be a KM-specific role within the project itself, to monitor, champion and support Project-related KM activities (learning Before, During and after).

The Communities of Practice, or Social networks also require roles, with a whole variety of names (here are 32 options). These include the following.

• The role that facilitates communication between community members on a day to day basis. This could be known as the community facilitator or moderator role.

• The role that takes ownership of the health and effectiveness of the community, and delivery of its purpose and aims. This could be known as the community leader or network leader. In smaller communities, the community leader is the same person as the facilitator.

• The management role which gives direction, steer and high level support to the community or network. This could be known as the community sponsor.

• A series of roles who support the leader, sometimes known as the community or network Core Team.

Often linked with the community are the roles associated with documented knowledge, with knowledge bases, or with areas of knowledge.

• The role who takes ownership for an area of technical knowledge, ensuring that it is well supported, well documented, that the training is in place, that the organisational capability is in place, and that knowledge on this topic is well managed. This role can be known as the practice owner, process owner, functional chief, subject matter expert, knowledge owner, technical authority, or many other names. This role is often combined with network leader, and is described here and here.

• The role of "go to" person for a topic, though without the weight of accountability described above. These are the subject matter experts in the organisation.

• People who are accountable for specific areas of online content - the content owners.

• People who are accountable for managing the entire content of knowledge bases - the cyberarians or librarians (see here).

There are other specialist roles which certain organisations may need, including the following.

• A role, or set of roles, for managing the Lesson Learned process.  This could be known as the Lessons team, or (in the case of the British Army), the Lessons exploitation centre. These roles ensure lessons are collected, validated, actioned, acted on, and closed out. They are accountable for, and report on, the effectiveness of lessons learning.

• A role for collecting observations and converting these into lessons. This is sometimes referred to as an Analyst role, and is often seen in military and government organisations.

• A field role, for collecting observations and lessons, through personal observation or through interviewing or facilitating meetings such as AARs. This role can be known as a Learning Engineer, a Learning Historian, an Operational Learning team, etc.
• A role for facilitating knowledge management meeting processes, such as Peer Assist, After Action Review, and Retrospect. 

Have I forgotten any? Are there additional KM roles in your organisation?

What do you do with your Best Experts?

---

What does your company do with the Best Experts?

In some organisations, the best experts - the most experienced and most knowledgeable staff - are put full-time on the top projects. The theory is that the highest priority project should have the best people working on it.

To me, that's a waste of knowledge. It would be like finding your best general, and putting them in a tank in the toughest battle, on the theory that "they have the most knowledge, let them fight the hardest fight".

As Knowledge Management professionals, we know that there are other ways to get knowledge into a project than by employing the people full-time, and we also know that the more knowledge a person holds, the more she or he is of value to ALL projects. There comes a time when an expert transitions from being a Doer, to being a Teacher; from being an individual who applies their knowledge to do a good job, to an individual who shares their knowledge, and develops the knowledge of others, so that everyone in the organisation can do a better job.

You see this model in many companies. In BP, the most experienced staff become Network Leaders, who have joint accountability for maintaining the knowledge base, and the knowledge assets, and for building the learning networks and communities of practice (they also consult to the most important projects, on a  part time basis). ConocoPhillips have a similar model. In SABMiller, experts from all operating hubs work within “Centers of excellence” who maintain company standards and Best Practice. In Shell, the role of global consultant is the pinnacle of the technical ladder, where the expert consults to many projects, and plays a key role in the Communities of Practice and in developing content for the Shell Wiki.

In each of these companies, the expert has a far greater impact on developing the capability of the organisation, than if they were full-time in an all-consuming project on the far side of the world.

If you Can, Do. If you Know, Teach.

Knowledge of product, knowledge of practice

---

Some companies make things, some do things. Different focus, different business, different approach to KM.

OK, so that is an oversimplification - most companies are a mix of Doing and Making; they have product departments where they Make things, and sales/marketing/support departments where they Do things. However there are still two types of KM approaches; the approach that focuses on Product, and the approach that focuses on Practice.

A typical practice-based organisation would be the Army. They don't make things, they do things, and their KM approach is all about the development and improvement of Practice. They develop their doctrines, they develop Communities of Practice, and they focus on continual practice improvement. We see the same in the oil sector. The focus is on Practice Improvement. Communities of Practice, Best Practices (or whatever you prefer to call them), Practice Owners - the entire focus is on knowledge of Practice, Practice Improvement, and Doing Things Better.

A typical product-based organisation would be an aircraft manufacturer or a car manufacturer. They exist to make things, and their KM approach is all about the development and improvement of Product. They develop product guidelines. In DaimlerChrysler, their Electronic Book of Knowledge was about motorcar components, and their tech Clubs were more Communities of Product than Communities of Practice. The experts are more likely to be experts on a product, than experts on a practice area. With the more complex products, were design knowledge is critical, KM can become Knowledge Based Engineering, with design rationale embedded into CAD files and other design products. The Air Force, in contrast to the Army, is focused primarily on Product learning - learning about the Plane itself, much of which learning is shared with the aircraft manufacturer. For a Product based organisation, the entire focus is on knowledge of Product, Product Improvement, and Making Better Things.

The danger in KM comes when you try to impose a solution where it does't apply. KM should be pragmatic, and consist of "horses for courses", rather than a one-size-fits-all approach. This is also true for divisions within large companies. While the sales division, or the new business division, or the projects division may need Communities of Practice, perhaps the division that makes the products needs Communities of Product, so that Knowledge of Product can be transferred across company boundaries. Perhaps the traditional tools of Learning Before, During and After need to look at Product knowledge as well as Practice knowledge, and look for improvements in Product as well as improvements in Practice.

The idea of Communities of Product is an interesting one, as these Communities may extend beyond the designers and Developers, to include the Sales force and the Service Engineers, who also need product Knowledge, and can supply learning about the Product in Sales, and the Product in Use.

Ultimately the Product Community can extend to the Users of the product  - the customers themselves. That's when it really gets interesting!

How do you structure your knowledge?

---

Sooner or later you are going to have to think how you structure your knowledge in your organisation.

This is for two reasons - for findability, and for ownership.

You structure your knowledge so that people can find what they need in a single place, and you structure your knowledge so that you can ensure that the key areas of knowledge are owned and maintained and connected to communities of practice.  Yes, you can also have ontologies, taxonomies, folksonomy, etc etc - you can index and tag your knowledge in many ways - and structure is valuable also; if for no other reason than to give people access to the things they never thought to search for.

The choice of your overarching primary structure - the highest level of your taxonomy, and the way in which you divide ownership -  depends on your organisation, and you have many options.

You can structure according to process, if you are a process-driven organisation or department. Knowledge is about process - how to do stuff - and is owned by process owners. Many of the oil companies, such as ConocoPhillips, use this structure.

You can structure according to equipment, if your role is to maintain and operate a piece of plant such as a nuclear power plant. Sellafield uses this structure for their configuration management knowledge.

You can structure around clients, or industry segments, if you are a sales organisation. Buckman labs use this structure for their Communities of Practice, as does Aon.

You can structure according to product or client offer, if you are a consulting or service organisation. we structure the knowledge in our Knoco knowledge base this way, as do the Big 5, as do oil sector service companies such as Schlumberger or Halliburton.

The key is to see which structure most fits your key knowledge, then ensure the knowledge base, the knowledge owners and the communities of practice are aligned with this.