The Value of Knowledge Management (3)

---

Why is it important to understand the business value of Knowledge Management?

The answer is a simple one - if you understand the value, you understand how much you can justify investing.

An illustration of this comes from the Drilling function of an oil company, where a drilling team were planning a campaign on a new field. They studied historical data from learning curves on nearby fields, and worked out that if they could eliminate the learning curve on their new campaign through knowledge management and access to prior knowledge, this would be worth $100 million in savings (which was just about equal to the cost challenge that senior management were setting).

They put together an excellent and comprehensive program of learning activities, and employed three learning engineers to capture and re-use lessons from operations. Almost inevitably, they began to face cost challenge. How could they justify these extra staff, they were asked, when the whole program was facing cost pressure? As the team leader reported

"We were criticized for team size. "Why do you need so many people"? It would have been very easy for our manager to say "you are going to have to conform to the rest of the world out there" but he didn't, and because he didn't, he forced us to think about what our needs were, and he allowed us to tailor and fit the organization to meet those needs"

He was able to justify the investment in learning engineers, because he understood the scale of the prize. He understood the value of learning and knowledge management. He knew that an investment of 3 extra people was justified if it would deliver a prize of $100 million.

So our advice to clients usually is to form a reliable and justified estimate, as early as you can in your Knowledge Management activity, of the scale of the prize. The prize will come through better decisions, improved process, accelerated or eliminated learning curves, and continually improved performance*. And if you understand the scale of that prize, you know how much you can invest to deliver it, and you are better placed to meet challenges to that investment.

* sometimes people imagine the prize from knowledge management to be an increase in personal productivity by speeding up employees' access to knowledge. This is not where the prize lies. The prize lies in giving people access to better knowledge, to make better decisions, and embedding this better knowledge in improved processes; not with giving people faster access to the same old knowledge.

The Value of Knowledge Management (2)

---

A client asked me to record the video below, as a response to a challenging question he had been asked - "How many more barrels of produced oil will Knowledge Management deliver?" This is a challenging quesiton, but very valid. It is aimed at the heart of the question of the value of knowledge management.

You don't introduce knowledge management because it's Good Thing, or because it's the latest fad, or because it will help people connect with one another - you introduce knowledge management because it makes sound business sense.

I try to address aspects of this argument in the video below.

The Value of Knowledge Management (1)

---

There are many approaches to demonstrating the value of Knowledge Management. One of the simplest, if you are a project-based organisation and if have the data, is to look at the Learning Curves of the organisation, as shown in the image below taken from our website (see full size image)

A learning curve represents the improved performance of a team or an organisation over a series of repeat activities or projects, due to the accumulation of knowledge. Simply put - the more times you do the activity, the more you learn, and the better you get. The only thing you have at the bottom of the curve that you did not have at the top, is Knowledge. Therefore the area between best performance and the learning curve (the yellow area in the picture above) is money spent through lack of knowledge.

If this was unnecessary lack of knowledge, then this money was wasted, and represents the value that Knowledge Management can create. This value will be greatest when the activity cost is high, and the number of iterations is large.

Knowledge Management will create value in three ways -

By enabling "Learning During" (through, for example, After Action Reviews) the team can steepen their learning curve, and so cut the yellow area. For example, a team we worked with, doing a task repeated seven times, managed to capture all the learning from the first iteration, cutting the time taken from 190 hours to 70 hours. Over the full cycle, this liberated about $1m worth of otherwise lost production.

By enabling "Learning Before" (through, for example, Peer Assists, or access to previous experience) the team can start the learning curve lower down. In an ideal situation, if all the learning already exists in other teams, then they can eliminate the learning curve entirely. For example, the Schiehallion well team in BP in the 90s managed to eliminate their learning curve by doing all the learning in advance, thus saving in the region of $83 million.

By enabling Learning After" (through for example Retrospects) the team can ensure that the knowledge is retained for future use, and can therefore eliminate the risk of the "Unlearning curve"; which is where a gap in activity is followed by a decrease in performance.

So if you work in an organisation with repeat, high cost activity, look at your historical performance data and look at shape of your learning curves. Typically a learning curve represents 10% to 15% of program costs, and these costs represent the target value for knowledge management activities. And that can be a LOT of money.

Serendipity and Communities of Practice

---

We have recently been working with an organisation, setting up communities of practice as part of a knowledge management approach. It's an organisation of fragmented parts, which have recently come together under a single umbrella, and they chose communities of practice as a means to exchange best practice around the organisation. We launched the communities, and set up a series of meetings (they don't have groupware in place yet) to begin to discuss candidate best practices that could be shared and replicated.


That's when serendipity took over. Serendipity as the daughter of connectivity.


In most of the communities, sharing began to happen organically as a result of the connectivity and relationships that had been established across the previously fragmented parts of the organisation (as you might expect!). As well as working on these candidate best practices, the community members began to tap into each other for help and advice. Knowledge has begun to flow around the communities, fuelled by Pull (asking for help), long before the best practices have been successfully Pushed from one part of the organisation to another.


The best practices will flow, but it was striking (though perhaps not surprising) how informal Pull has delivered three success stories already, while we still wait for the more formal Push to pay off.

Accountability in Knowledge Management (2)

---

To continue the discussion on Accountabilities for Knowledge Management - lets discuss, who is accountable for KM, and what accountabilities do they have?

In a mature Knowledge Management framework, we see three chains of accountability (see picture).



Ownership, organisation and maintenance of the company knowledge base is the accountability of the functional organisation (orange). Individuals within the functions have accountability for developing and deploying best practice, in order to sustain the capability of the organisation. The chief engineer, for example, is ultimately accountable for the engineering competence of the organisation, and therefore for the state of the company engineering knowledge base. He or she will delegate components of this to individual subject matter experts. In addition, he or she will delegate accountability for coordinating the communities of practice which cover engineering topics.

The line organisation (green) is accountable for the application of the knowledge in the work of the business, and for the creation of new knowledge. If the organisation has clear KM expectations for project or business activity (e.g. that every project should have a knowledge management plan, or that each project stage should be closed by a Retrospect) then the accountability for the line organisation is to meet these expectations. The accountability will probably lie with the project managers, though he or she may delegate some of the KM activity to a delegate (a project knowledge manager for example).

The KM support team (yellow) is responsible for ensuring that the KM system itself (the tools, the processes, the technologies) are fit for purpose, and are well understood.

Chickens and eggs in knowledge management?

---

Nadeja Loubeva had a recent post on her blog, likening Knowledge Management and Organisational Learning to "the chicken and the egg"

I like the analogy of the chicken and the egg, for a couple of reasons

Firstly, I agree that the organisational learning/knowledge management learning loop must be closed. It must be a loop. You can't just create eggs. Or just chickens. The two need to morph one into the other in a closed cycle.

Secondly, knowledge (often) goes through two stages. Like an egg and a chicken, it passes through tacit and explicit. In these two forms, it looks different, it needs to be treated differently, and it is "owned" by different people. The teams and projects apply the tacit knowledge (which can be considered to be "doing the organisational learning"), while the experts and functions maintain the explicit knowledge base. The transitions between the two forms need to be managed carefully - developing new explicit knowledge from operations, and applying new knowledge to operations.

So I appreciated Nadeja's analogy. As they say, a chicken is just an egg's way of making another chicken, and organsational learning is just KM's way of learning even more.

People, Process and Technology in Knowledge Management

---

The mantra of "people process and technology" is a pervasive one in Knowledge Management, which we were using in BP in the mid 90s, and which is still quoted today. However it is often quoted without explanation of what it means or what it refers to, which is why I have put this post together.

For me, these three items are the three main dimensions of the management system needed to sustain KM (or the three main enablers, if you prefer). They are also the main dimensions of any management system, as I explain in the video, but they are as applicable to Knowledge Management as they are to finance management, content management, or people management.

I have seen people add a fourth circle, which they call "Content" or "Information" or even "Knowledge". For me, this addition represents something different - namely the object of the management system, rather than the component dimensions. If I were to add any other circle, it might be something like "Governance", though again this is different, being higher than the other three.

Also in my experience, the People circle is best used to represent the structure of roles and accountabilities that is introduced as part of the management system. I explain more below, in the video.



see more knowledge management video here

Accountability in Knowledge Management (1)

---

Here's another quote from the Peter Senge video I mentioned yesterday. He implied that - never mind arguing about the definition of Knowledge, we can't even agree on the definition of Management. He proposed this definition

'Being a manager means taking accountability for the work of others'

Now, this is a definition of a manager, rather than a definition of management, and we could extend it to say

Management is a system of assigning accountabilities, and ensuring people deliver against these.

I wonder what would result if we took that idea, and applied it to Knowledge Management? I was interested to try this, because for me, accountability is key to management, and accountability is seldom a concept people apply to knowledge*

Perhaps if we follow this train of thought, we could conclude

Knowledge Management is a system of assigning accountabilities for Knowledge, and ensuring people deliver against these.

That's a very interesting definition, and I think it could take us to some powerful conclusions, which I would like to develop further in another blog post, when I have clarified my thinking a bit more.

* However I think they should! One of the recent breakthroughs we made at BP was assigning clear accoutabilities within KM. Read more in our Dec 07 Newsletter

Knowledge is ...

---

I watched a video yesterday of Peter Senge talking about Knowledge Management back in 2004, and his definition of knowledge was one that I resonate with.

He said "Knowledge is the ability to take effective action*". For me, this is clear, and also makes Knowledge clearly distinct from Information.

I would adjust this slightly - there is more to effective action than Knowledge; resources are important also, for example. You might argue that "Knowledge is the ability to make effective decisions". The implication of this second definition, is that it allows you to align Knowledge Management with Decision Support. At a recent KM planning** workshop, for example, the project leader asked that the KM plan be focused entirely in the upcoming decision to select the project concept. We then had a great discussion as a team about "what do we need to know, to make an effective decision on concept selection?" The knowledge needs inventory that emerged from this discussion was then used to plan the project learning actions.

Discussing these ideas a little further today, over dinner, I wondered if the following is also true

Knowledge is knowing how to do things
Wisdom is knowing what things to do


* This definition was also proposed by Hubert St Onge at the Ontario KM Summit in 2006, and I believe originates with Nonaka
** More on Knowledge Management planning

Never try to tell everything you know.

Never try to tell everything you know. It may take too short a time. - Norman Ford

Know-how management

Part of the confusion between Knowledge Management and Information Management is almost certainly the lack, in the English language, of any distinction between Know-How, and Know-What.

English is unusual in using the same word ("knowledge") for both of these forms of knowing. Other languages differentiate them - Savoir* and Connaitre in French, Kennen and Wissen in Germany, Kunne and Vite in Norwegian. My friend Adel tells me that Arabic clearly distinguishes between the two, in the Quran for example. And yet, he goes on to say, when Knowledge Management is translated into Arabic, the translation is always to "Know-What Management".

I think this misses the point. For me, knowledge management has always delivered its real value when applied to "Know-How" - to improving the competence of the organisation by giving people access to the knowledge they need to make the correct decisions. Managing "Know-What", on the other hand, gets very close to Information Management, or to Business Intelligence. Important, yes, but already covered by existing disciplines.

Caertainly whenever I use the term "Knowledge Management" I am referring to "Know-How Management;" management with the purpose of sustaining, building and deploying the know-how of the organisation. However as a direct result of a shortage of nouns in the English language, I am well aware that others use the same term to mean "Know-What Management" - the marshalling and presentation of facts and information.

It's no wonder the market is confused.

* I believe (and correct me if I am wrong) the French translate the phrase "Know-how" as "Savoir-faire", which in English idiom has connotations of being amazingly cool and capable. Which appeals to me.

Crisis knowledge management

How do you manage knowledge from really rare events? From the infrequent crises?

Often we rely on accessing knowledge and experience from others, but this method falls down when the events we need to learn about, happen very rarely, and the others are as much in the dark as we are. If the last time the event happened was, say, 20 years ago, it lies beyond the reliable limits of human memory. The human memory is unreliable over a long span; we post-rationalise, we partially recall, we invent memories, or we simply forget.

I started to think about this as a result of two events that happened recently at the school where my wife Cathy is Head Teacher. The first event was a medical emergency to one of the children, which required an ambulance to be called. The staff dealt with the situation extremely well, but this was a new challenge to most of them, and it was stressful for everyone concerned. So Cathy (as you might expect from a Knowledge Manager's wife) held a learning review, and developed an excellent "medical emergency" process which will go on file and be used if a similar emergency occurs future.

Then a few days later, came the snow. Days where the snow is so bad that schools have to be closed, are extremely rare in SOuth West England, and have not occurred for over 20 years. So when it came to making the decision to close the school, then finding the ways to inform the media, the radio, the parents and the staff, there was a real sense of "making it up as you go along". Once again, Knowledge Management 101 says - you need to review afterwards, look at what went well, look at what could have been improved, and draw up the ideal "snow day" process as a resource for the future.

It's not just schools. Events such as the Marchioness river disaster (to choose an unusual UK crisis event), where a pleasure boat on the Thames sank with massive loss of life, are real rarities, and without an easily accessable body of knowledge on "Thames pleasure boat disasters" to call on, the police will just be improvising.

When it comes to national crises such as the summer floods of 2007, I have another concern. I was strongly advising one of my clients, who was in charge of KM for one of the affected public utilities, that they desperately needed to hold a decent Retrospect, to improve their flood response process. She tried to get this to happen, but it proved politically impossible to hold an in-house review while the big government-funded public enquiries were happening. No doubt these enquiries were of value, but they were not focused (as the Retrospects would have been) in developing improved flood-response processes for this particular utility company.

The saying "those who do not learn from history are destined to repeat it" is especially true for rare events, where human memory is at its least reliable, and therefore where learning has to be particularly deliberate. If the event is predictable, do your scenario planning. If the event was unpredicted, then learn from it, document the ideal response, and store it somewhere where it will not get lost. Then next time it happens, people will have some guidance to work from.

---

snow-sledge management

Some pictures of my house and the surrounding fields after the snow we received last week - uncommonly heavy for this area, and the heaviest snowfall for over 20 years.

---

Push and Pull in Knowledge Management, video

Knowledge Management involves the transfer of knowledge from one person or team to another. How is this knowledge transfer best motivated? By motivating Push (supply) or by motivating Pull (re-use)?


In this video I argue that Pull is a far more effective motivator in the early stages of Knowledge Management.





see more knowledge management video here

An old idea in new clothes?

My friend and former colleague Vince Polley maintains a blog on Cyber-Law, and KM aspects of the legal world. He cites a webcast from the Berkman Center for Internet and Society, where Professor McAfee of HBS gives an hour-long talk on Web 2.0

Now Vince has been working with Knowledge Management since the late 90s, initially with the major international service company, Schlumberger, and he knows a thing or two about knowledge management. His comment to me, regarding this webcast, is that "Essentially, the “Enterprise 2.0” processes he’s so taken with are the fundamental knowledge-management processes we’ve been working with since the late 1990s: expertise locators, Communities of Practice, team reinforcement techniques, and the like......I was struck by his apparent sense that these are new and that companies are at the threshold of fundamentally different ways of operating".

I agree with Vince. There seems to be a lot of talk about "New KM", or "KM is dead, Web 2.0 is the future", yet when you strip away the hype, the issues are the same as those we have been working with for over a decade; How do you get people to want to collaborate, to want to share, to want to learn, and then how do you give them the structure within which that can happen? We have learned the lessons of the past, that technology is part of the answer but is not the whole answer. Lotus Notes did not deliver KM on its own; Intranets and Search Engines did not deliver KM on their own; Sharepoint will not deliver KM on its own; Web 2.0 will not deliver KM on its own. New clothes can certainly brighten up an old idea, but we must be wise enough not to mistake the clothes for the content.

To all of you who are looking at Knowledge Management, and are excited by the new possibilities and the new technologies, I would say - "Excitement is great, there are some exciting possibilities around, but don't forget to learn before you leap". What you read and what you hear is not all of it as new as it seems, and there are a lot of lessons from the past that you can incorporate, to ensure that your Knowledge Management efforts do not repeat old mistakes and reproduce old failures, but build on what has been shown to deliver long-term success.

---

KM in a downturn, again

Phil Ridout alerted me to this article on KM in downturns, entitled "Layoffs Send People and Knowledge Packing", where the author identifies the risk that layoffs can lead to loss of critical knowledge. He suggests that if some elements of knowledge management had been in place, that risk might not have been so great. I think he's right, or at least partly right, but for many companies it's too late for that already. The downturn is here, layoffs are happening, employee uncertainty and concern is huge, and if you try and introduce KM now, people will not be listening. If you haven't been operating a robust KM system already, you won't get one in place in time to cover the imminent knowledge loss.

Instead, you need to do four things immediately

1). A strategic review of your corporate know-how, to identify those knowledge topics where you cannot afford to risk any loss, and then let HR know that experts and experienced practitioners in these areas should be preferably retained

2) A mapping of those individuals at high risk of loss (through early retirement, or because HR has already committed to losing them) who map onto these critical knowledge topics

3) A sensitive and effective program of knowledge retention

4) Development of a knowledge asset on fair, transparent and effective layoff programs. Layoffs are a sad but inevitable consequence of downturn, and as I said in my blogpost on Jan 27, "knowledge of how to downsize well" is one of the most important areas of know-how that you need to acquire (and by "downsize well", I mean the things I said above - fair, fast, transparent, done with respect and humanity, and with minimum damage to those who remain as well as those who leave).

Visit our downloads page for a free white paper on Knowledge Retention

---

YouTube video - the importance of Focus

Here's my latest video - on focusing your KM efforts



More video from me and my colleagues at http://www.knoco.com/knowledge_management_video.htm

---

Silly Doorsqueak theory

A really interesting article from Saturday's Times, by Matthew Parris

http://www.timesonline.co.uk/tol/comment/columnists/matthew_parris/article5679226.ece

He bases his article on thoughts brought on by a squeaking door at Derby railway station, which has remained unfixed for months. He suggests that this sort of persistent low-level problem is seldom the subject of review, even though that fact that it persists is probably symptomatic of some major cultural or systematic flaws within the station-management organisation. He notes that official reviews tend to be either theoretical and highlevel, or a reaction to a major disaster (often accompanied by blame-seeking). He proposes that review of "a real, small, unsensational fault whose folly no one would dispute" such as a squeaky door that remains unoiled, is a powerful way to unravel the fundamental problems in an organisation.

Why is this important? Because if an organisation can fail to notice, or fail to fix, a squeaky door, then maybe something else has remained unnoticed or unfixed. Something with far bigger consequences.

It strikes me that this is exactly what Knowledge Management can help fix, and by this I don't mean those aspects of Knowledge Management related to creating databases, or even those aspects related to creating communities. I mean the nitty gritty of regular learning reviews, such as the After Action reviews of military or oil-drilling activities, or the Retrospects that are built into projects.

When I facilitate these learning reviews, the most valuable question is Why*? You start by asking - Why is the door squeaking? Then you keep asking Why (as per the Toyota 5 Whys http://software.isixsigma.com/library/content/c020610a.asp) until you get to the real root cause of why the squeaky door has been ignored for months. You can imagine the sort of conversation -

Why is the door squeaking?
- Because nobody oiled it

Why did nobody oil it?
- Because they did not feel it was their job

Why did they not feel it was their job?
- Because a) it was not in their job description, or b) they had no job description, and c) nobody does anything that is not in their job description, or (etc etc etc)

Why does nobody do things that aren't in their job description?
- Because (and, by now we might be getting into more fundamental issues such as positive and negative incentives, fear of transgression, lack of vision, lack of ownership; I dont know what they would be in the case of Derby Railway station)

Local actions can be taken to fix the squeak, but higher level actions will need to be taken to fix the problems that allowed the squeak to continue unfixed. If these actions lie at the level of the individual station, then learnings for other railway stations can be identified and shared, and actions taken across the railway system

But this leaves me with a question for AAR facilitators. What do you do with these higher level actions? Especially at team After Action review (AAR) level? In most of the AARs I have worked with, the actions remain with the team. Does anyone have experience of how to escalate the more systemic problems, in order that actions can be taken (probably at a much higher level in the organisation to fix them?


*Why, as in the third question of the AAR - why is there a difference between aspiration and reality

---

Using MediaWiki

For most of last week I was using MediWiki to structure the output from two recent Knowledge Retention exercises. These exercises, on behalf of an engineering client, contained some pretty technical knowledge, covering plant design, operations and maintenance, health and safety etc.

I have to say - I was impressed by MediaWiki! Its a relatively simple way to develop a relatively well-structured knowledge reference site (or "knowledge asset" as it is sometimes called). Thanks go to Peter Kemper of Shell, who talked me through some of the principles of the structure and organisation of the site.

Here's what I learned.

• Each individual wiki (i.e. each page in the site) should be a single discrete topic. Within that topic, I structured the knowledge as an FAQ with each question as a second-level headline, and the MediaWiki index therefore automatically created an index of questions.
• It really helps when text and pictures can be interwoven - photographs, video, diagrams.
• In this case, the answers to the questions needed to be attributed (personally I am a great fan of attributed quotes as an aid to transfer of knowledge). The quotes should be attributed at the top, rather than at the bottom, so as you read the answer, you know from the start who is speaking.
• Get all the formatting right before you begin. In my case, I cut and pasted from a word document, and it would have been helfpul to have had all the wiki markup in the word document, right from the start. Changing the formatting would then have been simpler (a matter of Find/Replace) rather than spending 2 hours, halfway through the process, redoing the formatting.
• There needed to be the facility to link documents into MediaWiki. In this case I had to load them separately to a SharePoint site and link them in. This worked fine, but before you start, make sure you have your document store identified and accessable.

I know wait with interest to see whether the wiki will grow, Even if it doesn't, it's still a fine and easily accessable knowledge asset.

---

My latest on YouTube - Connect and Collect in KM

Connect/Collect model in diagram form

More video from me and my colleagues at http://www.knoco.com/knowledge-management-video.htm

---

Communities - a term that's becoming increasingly fuzzy

Sometimes a word becomes so broadly used that it becomes a barrier to communication.

The word “Community” is something you hear a lot in the Knowledge Management world. I have heard it used to describe lots of very different groupings of people, from collaborating groups of half a dozen experts, to the 3000-strong technical communities of Shell, to the 150 million people who have registered with Facebook.

The function of these groups is extremely varied. Some are groups for exchanging and building knowledge, others are small innovation teams, others are people with absolutely nothing in common but the use of the same software tool. Their structures, their governance (if any) and the ways in which they deliver value can be like chalk and treacle (to choose something even less chalk-like than cheese).

I worry that the “Communities” word is becoming too broad to be useful, and a better way of categorizing these networks is needed (or else a need to describe them in a little more detail). From now on, I intend not to use the word "Community" on it's own, as others may hear it in a very different way to the way I speak it. I will be more specific, and talk of Communities of Practice, Communities of Purpose or Communities of Innovation.

Visit our company downloads page for free white papers on communities or practice

---