Experience Management continued

---

In this blog post, I talked about Experience Management, and how this could be aligned with content management to form part of knowledge management.

I published a simple flowchart to illustrate this, and received a few comments from people suggesting that the flowchart could usefully be extended.

Here's the extended version. I have included the elements outlined in red, which represent the feedback loops. It is these feedback loops that deliver the continuous performance improvement that KM seeks to drive.

• Firstly, action leads to performance. Better knowledge results in better decisions, better actions and better performance.
• Secondly, reflection and analysis of that performance is needed, before an organisation, a team or an individual can crystallise their experience from that performance. I am sure you are aware of the distinction between the person with 20 years experience, and the person with one year's experience repeated 20 times. The difference is that the former reflects, analyses and learns, while the latter repeats their mistakes.
• The loop from performance, through reflection and analysis, identification of experience, improved knowledge, better decisions etc is the feedback loop that drives continuous improvement.
• Allied to this, of course, is the collection of performance data. Without the data collection, there would be no record of performance improvement, and no knowledge of which experience delivers the greatest value.
• Then I have put in a short arrow from Experience to Information, representing the codification step that sometimes takes place. Not all experience needs to be, nor can be, codified into information, but some of it can.

Although this flow chart lacks the simplicity of the previous version, it is useful to show the feedback loops, because those are the engines that drive performance through learning from experience, and which accelerate the learning curve.

Apologies for silence

I am working with some excellent people in China for the next 3 weeks but while here I will have no access to Blogger Twitter Facebook or googleplus . So apologies for silence; normal service will be resumed on return .

Posted from my smartphone

How Connect evolves to Collect - the RTFM moment

---

Far and away the best way to start Knowledge Management in a company is through connecting people, and through knowledge pull.

This is faster, more efficient, easier, and delivers better results that the common alternative of starting with knowledge push through collection of documented knowledge.  With pull-based connection, and individual with a need for knowledge can ask a community of practice, and receive an answer very quickly, without the need to populate a massive knowledge base first. Communities of practice are very generous with their time, and have no problems with answering a question, however simple and basic.

However there is one point at which a community of practice begins to lose patience, and that is when the question gets asked again. And again. And again. And again. I was reminded of this today, when yet another thread appeared in linked-in asking whether we should rename KM, and if so, what should we call it? This is a question that seems to be asked every second month, and you can get tired of answering it.

You see the same effect in communities in the workplace. People are happy to answer a basic question once. They get tired of answering it 50 times. So what they commonly do at this point, is being to codify some of their answers. They begin to move, of their own accord, from tacit pull, to explicit push.

The first thing they tend to do is write an FAQ, to answer the frequently asked questions in an efficient manner. This often comes about a year into the life of the community, when the frequently asked questions have been identified (by their frequency of asking), and the answers have been kicked around and pretty well worked-up, and it becomes more efficient to answer them once and for all, rather than repeating the answers afresh every time.

I call this point the RTFM moment (for "Read The Flipping Manual.") This is the point where a community can  move from Connection to Collection. However they do it of their own accord, and they do it for efficiency reasons, in areas where Collection actually works better than Collection. They see the value of it for themselves; you don't have to persuade them.

There is a lot to be said for letting a Community reach their own RTFM moment, rather than requiring them to Collect from the start; for letting this step evolve, rather than imposing it.

The "I am...." test for Communities of Practice

---

There is a fairly simple test for knowing whether
 a community of practice, is likely to be successful; that's the self-identification test - the "I am ..." test.

Membership of a community of practice is driven by passion, and the members are practitioners. Members of a community of practice feel an identification with the community, and an identification with, and loyalty to, other community members. For example, I am a member of several knowledge management communities of practice, because I am a knowledge management professional. At BP, I was a member of the Geologists community of practice, because I was a geologist. Project Management communities are for project managers, Corrosion and Inspection communities are for maintenance inspectors, Copier Repair communities are for people who are copier repair technicians.

I am a knowledge management professional, I am a geologist,I am a copier repair technician - that's the "I am ..." test for a community of practice. A community of practice for topic X will work, if there is a group of people who say "I am an X professional" - if they self-identify with the topic.

Here's a negative example.

A while ago we worked with a company that wanted to introduce a community of practice to cover the topic of annual returns. This was a chore than needed to be done once a year, and people were not very good at it. "We ant you to help us launch this community" they said. "We don't think it will work", we said.  "We still want to try it" said the client, and the client is always right, so we launched the community of practice.

It failed. After a brief period of life, it just died away.

That's because none of the members would say "I am an annual returns professional". They were engineering team leaders, they were professionals in their own topic, but annual returns was a chore that they did not identify with. Instead, what they needed was a simple how-to guide - a checklist and an FAQ - that would walk them through the annual chore. Not a community of practice, but a knowledge asset.

So if you are contemplating whether a community of practice is the right solution for your company, remember the "I am ..." test.

Correcting mistakes (Confucius quote)

---

"A man who has committed a mistake and doesn't correct it is committing another mistake."

Confucius

(and even more so, the organisation that has committed a mistake)

Every experience is an opportunity for learning

---

“Every experience in life offers an opportunity for learning. The smartest people are those who can transform the smallest event or situation into breakthroughs in thinking and action.” ---Gary Ryan Blair

"I don't know, I'll create" vs "I don't know, I'll ask"

---

What do you do if you don't know what to do?

Do you ask for help and advice, or do you make it up as you go along - invent something, be creative?


Answer my poll on the right, and lets see which is the more popular approach.

That's the core tension in KM - creation or re-use. Creation in the wrong place is called re-inventing the wheel. Re-use in the wrong place is called flogging a dead horse.

Part of our job as KM professionals is to drive the following behaviour.

• If you don't know what to do, then firstly find out whether a solution already exists that meets your needs, and if it does, then follow it. 
• It there is a solution than nearly meets your needs, adapt and improve it, then share your improved version.
• If there is no solution, then be creative. Create a solution. Then share your solution.

We perceive what we expect to perceive - dramatic demonstration

---

I have already posted about some of the illusions that we need to be aware of in KM.

Here's a graphic demonstration of another illusion - that what we perceive, may not be there at all, and that when data are messy, we can make them fit what we expect to see. Or hear. So "shared knowledge" can be completely false, but can reinforced because people expect it to be true, and so experience it. Sort of like the emperor's new clothes.

Simon is explaining this in the context of the Big bang, but it holds in many other contexts.

The curse of prior knowledge

---

Here's a really interesting article, written from a museum point of view, but very applicable to KM, called
Prior Knowledge and New Experience

The author, Jeremy Rochelle, is looking at how people absorb new knowledge from museum installations, and makes the point that all learners have prior knowledge already, which may be at odds with the new information. As he says

Prior knowledge can be at odds with the presented material, and consequently, learners will distort presented material. Neglect of prior knowledge can result in the audience learning something opposed to the educator's intentions, no matter how well those intentions are executed in an exhibit, book, or lecture.

People will look at new knowledge, compare it with their prior knowledge, and try to make it fit. If the prior knowledge is wrong or incomplete, the fit may be poor, and the fitting process may be painful. It's often easier to ignore the new knowledge if it conflicts with your prior knowledge. Learners are more likely to construct an interpretation that agrees with prior knowledge, and consequently disagrees with the viewpoint of the teacher. But on the other hand, learning requires prior knowledge, to give you a conceptual basis for fitting in the new knowledge, and everyday prio knowledge provides a huge store of useful metaphors and ideas. Prior knowledge is both a problem, and an enabler.

The author gives us some pointers to how to incorporate new knowledge into prior knowledge

• Study success, not just failure, and identify how prior knowledge enables success.
• Use methods that allow observations of students constructing integrated wholes, not just shifting valences on a bipolar scale.
• Be wary of viewing prior knowledge as an enemy fortresses that is wrong, alternative, or theoretical in character, and instead see prior knowledge as a disorganized collection of building blocks.
• Expect learning to occur through gradual refinement and restructuring of small component capabilities in a large, distributed system, with increasing coordination.

In addition to this, he mentuions the importance of social discourse and discussing - allowing people to talk through the new knowledge and its implications. What can be rejected by an individual, can be discussed and incorporated by a community. As the author points out

New knowledge does not replace prior knowledge, rather new knowledge re-uses prior knowledge. Re-use is made possible by a process in which prior knowledge is refined, and placed in a more encompassing structure. The more encompassing structure comes in part from the social discourse norms that prevail within a community of practice.

Knowledge Management or Experience Management?

---

One of our clients has contracted us to provide them with guidance into "Experience Management".


The term "Experience Management is not a commonly defined term, so I was very interested to understand what they meant by the term (and they weren't talking about managing customer experience, which is a different field). It seems they have already investigated Knowledge Management, and have been provided with Knowledge Management solutions that deal with content management and the management of information. However even with this service, they realise that there is still something missing, namely learning from experience, sharing of experience, and the application of experience to decision making. This is the "Experience Management" they want to introduce.

I think they are wisely navigating their way through the confusion around Knowledge Management; the confusion between knowledge and information, and between Knowledge Management and content management.

On the one hand, according to Einstein, Knowledge is experience; everything else is information.

On the other hand, there is a common model known as the DIKW model, which builds up through data and information, to knowledge, and then on to Wisdom. I don't particularly like the model, and it has many prominent detractors, but it also has a strong following.

So is knowledge based only on experience, or is it based only on information?

Davenport and Prusak define knowledge as "a fluid mix of framed experience, values, contextual information, expert insight and grounded intuition that provides an environment and framework for evaluating and incorporating new experiences and information". They see both experience and information as inputs to knowledge. In BP, a recent definition of knowledge was the application of experience to information.

Maybe we can draw a diagram such as the one above, where the Data/Information/Knowledge continuum (let's forget about Wisdom, that is something completely different), is parallelled by an Experience/Knowledge continuum.

This particular client believes they have support for the content and information side, but they still support for the Experience side.

What does Experience Management look like?

To be honest, it looks a lot like Knowledge Management, with the content management side removed.

• It contains methodologies for Learning from Experience, such as AARs, Lessons Learned systems
•  It contains methodologies for seeking and accessing experience, including Peer Assist, Knowledge handover, and KM planning
• It contains mechanisms for shared experience, including Communities of Practice, collaboration, connection and questioning
• It contains mechanisms for retention of experience when staff leave.

It looks pretty familiar, but has a clear focus on experience, on tacit, and on knowledge pull.

KM overview from Susan Camarena

---

Reproduced from here, with permission, a very nice overview of KM from Susan Camarena, CKO at the Federal Transit Authority

I reproduce it on this blog, as it's clear, succint, and very helpful.

Thanks, Susan

Knowledge Management- an Overview

What is Knowledge Management?
• The systematic means of capturing, organizing, retrieving, sharing and generating organizational knowledge.
• The focus is on the PEOPLE who do our work…
o and the PROCESSES by which we do that work.
• It is not about technology!
o technology is a (very helpful) tool- but only a tool.

Why Knowledge Management?
• Simple goal- stop “Reinventing the Wheel”
o Allows us to “Know Who” and “Know How”

How do we implement KM?
• We already are doing it!
o Everyone has their own KM program! Like:
 Saving numbers of the “right” person to call on an old, wrinkled and well used piece of paper.
 Reusing a memo that was approved as your template for the next memo to ensure it gets through.”
 Getting a movie recommendation- you trust their opinion and ensure you don’t waste your time!
• However, an ad-hoc approach is not efficient
o You don’t learn from what I (and others) know!!!

Tools in the KM Tool Kit- Examples
• Templates
• After Action Reviews
• Communities of Practice
• SOPs
• Websites
• Databases (well organized, user-friendly)
And more…

Determining the Knowledge Landscape: KM and our….
• Culture
• Business Processes
• Decision Making and Strategic Planning

the laughter of wisdom (quote)

---

"Back of every mistaken venture and defeat is the laughter of wisdom,
if you listen. Every blunder behind us is giving a cheer for us."

Carl Sandburg

(Thanks to Vince Polley for pointing me to this one)

The KM culture - embedded

---

I came across a video yesterday, collected in a Chemicals plant in the US, which seemed to me to be a good illustration of an embedded culture of knowledge seeking and knowledge sharing. The plant engineer was being interviewed by my old friend Brad Meyer, and he was asking about knowledge-seeking behaviours. She told him

"Most of my sharing has been within our company's wholly-owned facilties, and the trust there is 'a given'. I know that if I pick up the phone or email someone in another facility, I just know they will help me to the best of their ability. It's just a given - it's the way we operate"

She then goes on to describe a recent example

"A month ago I was working on scoping a project to add a singificnt amount of automation to a couple of our boilers, and with the project team I had written out a certain scope - certain things we wanted our boiler operators to be able to handle from the control room. So I sent out a note to my contacts in the other plants, and I asked for input. It was almost like an informal Peer Asist, and I got back some great input.

Getting inout from similar facilities within the US, within the world, Malaysia, Belgium - it was a very worthwhile exercise and it will make a signifcan improvement in this partiular project"

I like the way she described this open asking, and open sharing, as "a given - it's the way we operate."

That's a truly embedded culture; asking and sharing and resuse are "just the way we work around here".

KM - going beyond the old boy network

---

There comes a time in any growing company, when Knowledge Management starts to need to be treated seriously.

In a small company, everyone knows everyone, and knowledge can be shared easily, between friends. The whole company is one single social network, and all knowledge sharing is informal, and based on relationships.

But companies grow, new people come in, new companies are acquired, and there comes a time when the existing personal networks are no longer sufficient for KM. By now these are "old boy networks" (see definition) , and the new people can be excluded and cut off from these informal sources of knowledge.

We see this a lot when we are running our KM assessments.

• "How do you find knowledge you need?" we ask.
• "I just ask," they say. "Its easy, I just give the right person a call".
• "And how do you know the right person?"
• "We all know each other, we have worked together for a long time".
• "And how do new people know who to call? Or your colleagues in company X, which you have just merged with? How do they find the right people?"
• .................long silence..............

Now the problem with this situation, is that the people who are making the decisions about KM are already part of the old-boy network. As far as they are concerned, there is no problem with knowledge-seeking or knowledge sharing - everybody they know already does it. They don't see the problems that the new staff, the young staff or the merged staff, are encountering when they try to find knowledge.

So what's to be done?

• Step one is to map out the problem. Run a detailed diagnostic assessment. Maybe do some social network analysis.
• Step two is to put some simple structure into the knowledge sharing and seeking. Instead of relying on a-hoc informality between friends, introduce after action reviews, peer assists, knowledge-sharing round-tables.
• Step three is to get some supporting technology; in the first instance a yellow-pages system, then a simple Q&A forum.

When the company has outgrown the old-boys network, that's where a simple KM framework can step in and keep the knowledge flowing.

KM culture change - how do you know its working?

---

This is a follow-up to my post on the danger of maturity models.

There has been quite a lot of debate over this previous post, much of it on other websites or blogs, so I would like to give a bit more of the thinking behind it.

And part of the thinking is, how do you measure or demonstrate progress in KM  implementation?

Here's a couple of assumptions, which of course are open to challenge.

Firstly, my assumption is that Knowledge Management (like Risk Management, Safety Management etc) is more about culture change than it is about tools and techniques. If a team *really believes* in the operational value of knowledge, they will find their own way to work with it, using paper and pen and phone conversations if necessary. And if a team *really does not believe* in the operational value of knowledge, then the best toolkit in the world will not help them.

Secondly, my assumption is that this culture change is not a gradual change, it's a step change. It requires a different set of priorities, and a different way of working. It's more of a revolution than an evolution.

If these two assumptions are true, then the best way to introduce KM to a company is not through a gradual overall change, but through a piloting strategy. In a piloting strategy you take a small part of the company through the culture change first, in order to
a) demonstrate to the rest of them that a KM culture is possible
b) create an "attractor" for the rest of the company
c) test out the KM framework in case any tweaks are needeed

Back in the last 90s we worked with Colonel Ed Guthrie of the US Army, who's view of KM was similar. He likened the culture change to crossing a river, and his model was based on how you might get a brigade across the river. You start with firing a thin thread over the river, use it to pull across a rope, use the rope to pull across a pontoon bridge, and march the rest of the army over the bridge. The early KM pilots are the "thin threads". The far bank of the river is the changed KM culture; with KM embedded and applied. the nearside of the river is "pre-KM culture".

Now imagine you were using a maturity model to map the change. The nearside of the river is pre-KM - you might measure it as level 1 or 2 out of 5 for most of the KM elements such as behaviours, processes, use of tools, leadership etc. The pilot team would rank 5 out of 5. They are using the tools and processes, showing the behaviours, with their leaders fully involved.

You could therefore give an average maturity rating to the whole organisation, I suppose, which might imply that everyone was somewhere in the middle of the river.  However a single model for the company would be misleading. The KM maturity does not rise progressively from 1 to 2 to 3 to 4 to 5; it makes a step change, but only in the small areas of the company who have been part of the pilot. Then over time, you change other areas, and more and more areas, until the whole company has made the cultural transition.

If my assumptions are correct, then the only way to demonstrate progress in KM, is to show some areas where the culture change has been achieved. You don't want to show progress from a maturity rating of 2 to a rating of 2.5, you want to show KM actually working, in one small area of the company; a single division, or a single community of practice, or a single project team.

In other words, you know that the KM culture change is working, because there are some groups where the change has taken place. It's not that the whole culture is gradually changing, it's that you can point to some examples who have bridged the culture gap, and who are now "standing on the far side of the river"


The other advantage of this piloting over a gradual maturation, is that it delivers some quick wins to management.  When the CEO comes by and says "how are we progressing with KM," it's much better to be able to say "we've been working with X division and Y community and we've got some really good success stories to tell you. Next month we are going to be workling with Z project as well" - rather than saying "We are at level 2, and hope to be at level 3 by the autumn".
Don't measure maturity - measure transition.

KM and coffee machines

---

I don't know if I am getting grumpy in my old age, but I seem to be on a run of blog posts which challenge popular models, approaches or analogues in Knowledge Manager. Today's challenge is to the analogy of the coffee machine.

Gerald, I am sorry, I am going to pick on you as an example of this analogy, but it is a pretty widespread analogy. The coffee machine is seen as somewhere we make connections, meet people, and share knowledge.

Intrigued by this, I have loitered around some coffee machines to see if this is true.

Firstly, very few of the conversations I overheard had anything to do with knowledge. Most of them were purely social, covering the weather, holidays, "How are you, fine thanks" and other social interplay, most of it of little value other than reinforcing social bonds (Yes, I know that has value).

Secondly, the bulk of material posted on the notice boards by the coffee machine were also purely social. Postcards, thank-you cards, items for sale, notices of forthcoming concerts or lectures, etc.

Once upon a time, when computers were used mostly for word-processes, I did use a coffee-area noticeboard to broadcast new lessons, as we had no other way of getting new knowledge into people's attention-space. But I have never seen it done since.

A coffee machine is therefore a good metaphor for any social media that you are introducing purely to form social bonds. And I know that there is a school of thought that says "all we need to do is form social bonds, and knowledge will flow". But for me, for our view of knowledge management, its a poor analogy. The exchange and re-use of knowledge is far too important an issue to leave to chance encounters at a virtual coffee machine.

As I said in this post on the water cooler metaphor, just imagine managing your finances the same way - "I need money for my project - I will go to the coffee machine and hope I bump into someone who can give me some money".  If you need knowledge for your project, it would be equally crazy to say "I will go to the coffee machine and hope I bump into someone who can give me some knowledge".

Knowledge management is too important to leave to serendipity. It needs to be a deliberate and managed approach to providing people with the knowledge they need, when they need it.

If you want  coffee, go to the coffee machine. If you want knowledge, you need something far more focused.

Collaboration systems design principles from IDEO

---

This post describes the IDEO online system (the Tube) and how it has been built to enable collaboration round the enterprise. The design principles in particular are very good, and copied below.

Design Principles: IDEO's Knowledge Sharing Team synthesized their findings into five design principles that guided the creation of the Tube, and scale and adapt to inform similar efforts within other organizations.

1) Build Pointers to People: rather than trying to take all of the knowledge out of people’s heads and store it in a giant database, focus primarily on helping people to identify who they are -- their passion, experience, and expertise -- and connect people based on that information.

2) Build Rewarding Systems: a system that requires altruism is unlikely to be successful. Similarly, systems that require users to participate (e.g. compliance-based design) rarely get anything more than participation at the lowest required level. Effective knowledge sharing systems must simultaneously meet the needs of the organization while motivating individual participation. The Tube encourages individual participation in a number of ways, from establishing a platform to allow employees to showcase their best work, to integrating the salary range process and project resourcing process into the system.

3) Demand Intuitive Interfaces: intuitive interfaces are absolutely essential for social software because they facilitate viral adoption. The system must present as few points of friction as possible from the process of becoming an active user. For example, early wiki systems required users to set up an account the first time they wanted to add content, learn special wiki languages to format pages, and build not only the content but also the navigation to support it. These points of frustration discourage users from making the transition from consumers to contributors.

4) Take the Road More Traveled: if a tool requires people to go out of their way to use it, adoption will always be a challenge, no matter how wonderfully designed. Wherever possible, strive to integrate tools into existing work processes -- bring the system to the user rather than the other way around. For example, the IDEO blogging system didn't take off until the team added a program that sends digest emails with new content from the blogs each employee has subscribed to.


5) Iterate Early and Often: building effective systems for organizations means designing tools and workflows that mirror the social systems they are meant to support. This happens through lots of iterative design, beginning with rough in situ prototypes (paper-based or hacked existing systems) and evolving into working systems that can be tested broadly throughout the organization. This process doesn’t end with "launch" either. Knowledge sharing systems should grow with the organization they support, and in turn they shape the organization by enabling new levels of collaboration. Thus these systems and the designers creating them should think of them as an ongoing, evolving dialog with the employees using them. At IDEO, the team pushes out revisions to the Tube (both bug fixes and new features) each Thursday. Much as Google keeps all of its software in “beta” for as long as possible, this reinforce the notion that the Tube is a working prototype and set the expectation for ongoing change, which enhances our user experience without confusing it. When individual passion meets collaborative tools that fit into the flow of one’s worklife, powerful innovations can result. IDEO's goal is to continue to build a platform for innovation that builds on the passions and cooperative foundations of our culture. As is a tradition at IDEO, the team will continue to share with the outside world what they learn along the way.

Customer not always right

---

"If I'd asked my customers what they wanted, they'd have said a faster horse"
Henry Ford

Knowledge - the only real security

---

The only real security that a man will have in this world is a reserve of knowledge,experience & ability

Henry Ford

The Ideas sausage machine, or the ideas conversation?

---

How do you generate ideas in your organisation?

Here are two approaches - the suggestion scheme, and the conversation approach. I prefer the conversation approach.

The standard suggestion process is the sausage machine. People are invited to volunteer ideas via a suggestions box or via an online portal. The ideas are gathered, evaluated by a team, sorted and sifted, and a percentage are implemented. There may be a monetary award to encourage participation.

The conversation approach is where ideas are actively sought in a project team, a department, or a community of practice.  This can be done as part of a post-project review, a community meeting, or through online discussion and collaboration. The ideas are discussed within the team or community, are improved theough discussion or combined with other ideas, until a good idea becomes great. If the team or community has the resources they implement the idea themselves. Otherwise they escalate the idea until they find someone to approve it.

I think there is merit in the ideas sausage machine when you want to get ideas from a very wide range of people; as a crowd-sourcing mechanism. But for creating ideas within a company, I prefer the conversation approach rather than the suggestion scheme, for the following reasons.

• The conversation approach is proactive, rather than reactive. You ask for the ideas, rather than waiting for them to emerge.
• In a conversation, feedback is instant. In a suggestion scheme, you may wait weeks or months for feedback.
• The best innovations come from a combination of ideas, which is possible in a conversation, where ideas can spark off each other and form something far better (see here for example). In the suggestion scheme, each idea lives in isolation as a single sausage. 
• The community or team can implement the idea, if it's small enough, or support it if it needs to be escalated.

Here's an example of an idea being implemented - a small idea, but a good one.

A team on an offshore oil rig was reviewing recent activity, as part of a regular review process. One of the things they reviewed was a recent near-accident. A member of a boat crew had been unloading a supply boat, and the materials needed were at the back of the boat, far from the unlading bay. He had to clamber over piles of pipes to reach the supplies, and a pipe had rolled against his leg, trapping (but luckily not breaking) his ankle. The team decided that it would be better if the boats were loaded in the same order as they were unloaded. "So how could we make sure that happens?" they asked. One guy had the bright idea of putting a webcam in the boat loading dock, so they could supervise the loading from the rig - many miles away. The team liked the idea, bought the webcam, and solved the problem. The idea was sought, supplied, discussed and implemented very quickly - no need to wait to be reviewed and approved, even if anyone had thought to submit it in the first place.

Black boxes and checklists

---

Lets look at two elements of the learning system in aircraft - the black box recorder, and the pre-flight checklist - as analogies for elements of Knowledge management.

The black box recorder is a raw data-capture tool, that captures data within flight.

The pre-flight checklist is a distillation of data from millions of successful flights and thousands of accidents, designed to give pilots the knowledge of successful flight procedures.

The pre-flight checklist is linked to, and is an outcome of, results from black box recorders. However there is a complex process between the two; of data review, root cause analysis, solution-finding and validation, derivation of new process, and distillation into a checklist. Very few black box recordings are ever reviewed - only those from extraordinary events, because it is the extraordinary eents that create the new knowledge.

It can be tempting to approach project knowledge capture through black-box-recorder-like techniques. Live meeting capture, for example. Or live capture of project decisions. Or ensuring all project records are filed and passed on. These approaches create a lot of data, but create little knowledge, and would be massively labour-intensive to interrogate. Expecting future projects to learn from this material is a bit like expecting pilots to learn directly from black box recorders.

So if you are applying these techniques, invest also in the processes of data review, root cause analysis, solution-finding and validation, derivation of new process, and distillation into guidance for future projects, whether this is a checklist or a wiki or a guidance document.

The danger of maturity models in KM (and the alternative)

---

I know that KM Maturity models are popular as a way of self-measuring progress, but personally I think they are inappropriate and can lead you into a wrong understanding of KM, and that there are much better alternatives.

Let me explain why!

The idea behind a KM maturity model is that you see where you currently lie on a series of spectrums which describe different elements of KM. You may be level 1 for leadership, level 2 for technologies, level 3 for whatever-it-might-be. Then over time, as you go through your KM implementation, you expect to creep incrementally up the scale; as if you were "growing up" and maturing as a KM company.

The problem is, KM is a change process, and it's a step change in culture. You cannot increment your way to a step change. You help the early adopters of KM to make the culture change and to adopt KM. These attract the first followers, who attract the second followers, but each one has to fully make the change to a KM culture and working KM approach, before they create enough value to attract the others. They make the change, show the value, and others follow.

So you cannot use an incremental scale, or a maturity model, for a step change. The step change is Quantum, not continuous.

Let's think about step change. The prime example is the penguins on an ice floe. They make a step change from one culture (on the floe; safe but hungry) to another (in the water; riskier but lots of food). They don't inch down the floe all together - you couldn't have a model that goes "penguins on floe, penguns feet in water, penguins waist deep, penguins neck-deep, penguind swimming". Instead the measure is "0 penguins in water, 1 penguin in water, 2 penguins"............up to all "all penguins in water". They are either in the water or not. It's a step change.

Look at the culture change  below. You could not apply a maturity level to the crowd. There is no maturity progression "crowd sitting still, crowd tapping feet, crowd fidgeting, crowd standing up and swaying, crowd dancing".  Instead the progression is "leader, first follower, second follower, third, fourth+fifth etc etc". They are either dancing, or they aren't. It's a step change.

For a step-change, the measure is not an incremental climb up an incremental scale, but the percentage that made the leap.





That's why a maturity measure is inappropriate, here's why it's dangerous.

It's dangerous because it leads you to think that you change the whole company all the time. In fact the best approach is to lead elements of the company to make the step change one by one (department by department, or community by community, or project by project).

It's dangerous because it leads you to think level 3 is better than level 2. Take leadership as an example - if level 2 is "disinterested" and level 3 is "lukewarm", then level 3 is not an advance over level 2, as both are inadequate for success. KM cannot survive with lukewarm leadership. KM needs clear leadership support and expectation. You need to work your way through the stakeholders one by one, moving each leader to the commitment threshold.

It's dangerous because it neglects the tipping point. Penguins diving off an ice floe, and dancers at a festival, reach a tipping point when the numbers are right, and the rest suddenly join in. An incremental maturity model does not predict this. You need to expect it, and plan for it, and resource for it. Demands on your services as KM coach and support may increase by a factor of 10 within a few days.

So what is better that a maturity model?

What is better, is a change model. You set the conditions for change, you define what the change will involve, then you implement Knowledge Management across the organisation; team by team, stakeholder by stakeholder, department by department or community by community. You map the change as the company transforms. Your metric is the percentage which have changed, not the degree of maturity of the change.

Knowledge Management - a term lost in translation

---

Knowledge Management is in a state of mild chaos at the moment. There is no established understanding of the term; instead there are conflicting fields vying for the label. Library science, web 2.0, engineering KM, storytelling, lesson-learning; on a good day, these can be seen as clusters within a distribution or characters within a crowd, while on a bad day they are fierce combatants in a turf war, with IT vendors on each side adding to the noise and smoke.
Why the confusion?
Largely, I would suggest , because of a strange deficiency in the English language.

In English, unlike in many other languages, we have only one verb for "Knowing" and only one noun for "Knowledge".Other languages have two words; one of which means "intimate knowledge, knowledge as capability, know-how", the other means "knowledge of facts, rote knowledge, know-what". Savoir and Connaitre in French, Kennen and Wissen in Germany, Kunne and Vite in Norwegian, and so on. Vestiges remain in dialect ("Do you ken?") but mostly the distinction between the two in English has gone.

With the two words, there is a world of difference. Someone might say  "I know Paris" ("Jeg er kjent med Paris"), someone else might say "I know the capital of France" ("Jeg vet hovedstaden i Frankrike"). The second person might be useful in a very easy pub quiz, but the first is the person you want as a guide to the best restaurants, hotels and sights.

It is the first type of knowledge that gives power ("savoir, c'est pouvoir") and creates an economy ("économie du savoir"). That is the Know-How knowledge, that deals with capabilities; that directs action and delivers business result. Knowledge Management focused on Know-How looks at improving the competence of the organisation by giving people access to the knowledge they need to make the correct decisions.

The second type of knowledge, the Know-What knowledge is close to Information, and managing "Know-What" gets very close to content management, to Information Management, or to Business Intelligence.
Unfortunately, although it is "Savoir" that gives Power, Knowledge Management is too often translated as Connaitre ("Gestion de Connaisance", Wissensmanagement, etc). My friend Adel tells me that Arabic clearly distinguishes between the two, in the Quran for example. And yet when Knowledge Management is translated into Arabic, the translation is always to "Know-What Management".

So we have two meanings hidden in the one word; and as an outworking, we have two views of Knowledge Management. In addition we have one meaning that carries connotations of power, economy and capability, and a discipline that all too often focuses on the other meaning.  One looks at know-how; knowledge as capability. The other looks at know-what; knowledge as facts. The differences between the two are lost in translation, as we struggle over how to manage one word, with two meanings.

If we could have KnowHow management and KnowWhat Management, Gestion de Savoir and Gestion de Connaisance, Kennenmanagement and Wissensmanagement, then the turf war would subside, with the Storytellers and the learners-from-experience working under one heading, and the content managers, librarians and SharePoint vendors working under the other.
My own life in Knowledge Management has always been in the service of the first word - Know-How, as that is where I see the value, but I really wish we had the two words and therefore the two disciplines! It would make life so much easier.

Chefs and recipe followers

---

People often use the analogy of chefs and recipe users within Knowledge Management, frequently arguing that chefs are liberated by knowledge, and recipe-followers are straight-jacketed by "best practice". Being a chef, in KM terms, is seen as "good". Being a recipe-follower, or a user of best practice, is seen as "bad" (and you will find many KM sites that use the term "best practice" as a boo-word).

True to form, I challenge this prevailing view.
There are places in KM for "chefs", and places for "recipe followers", and the KM practitioner need to know which approach to use when.

Firstly, for mature knowledge, especially with a high turnover of new staff, you primarily need people to follow recipes. You don't need to be a chef to make a white sauce, or to boil an egg. But even for basic stuff, the complete beginner may need a beginners guide to follow (see Delia Smith's recipe "How to boil an egg").  The newest people joining your company will need a recipe book for mature knowledge, just to get them started on the basic things. Following a recipe is a far more effective strategy than calling in a chef. And for some companies, the primary KM problem is educating the new people, because either of massive growth or of massive churn. The combination of rapid onboarding, rapid networking, and very good explicit guidance, needs to be part of the KM strategy  (for example in the Chinese car industry, where the average age of the engineers is 23, or in telecom businesses where the annual churn rate may approach 40%). So to bring these new people up to speed with mature knowledge, they need a recipe (as well as access to chefs when things go "off-recipe").

Secondly, creativity may be crucial, but so is productisation. A chef may have a brilliant idea, but the most successful industries are not always those with the best ideas, but the ones that bring those ideas rapidly to market. once the chef has the new recipe, the recipe followers can rapidly spread it through the marte and capture the market share. And there can be good business in following a recipe - McDonalds, Taco Bell, Pizza hut, to name but a few, make a global business out of it. For purely financial reasons, a share in McDonalds is probably a better bet than a share in Gordon Ramsay inc (though these might be outweighed by other reasons). A commercial business needs creative poeple to come up with the new ideas and new products, and then needs an army of people following them, to get these ideas to market.
Thirdly, for the most critical knowledge, even a chef follows a recipe. Think of an experienced airline pilot taking off from heathrow. He or she goes through the pre-flight checklist step by step, "following the recipe". If I were on a plane, and the pilot came on the intercom and said "Ladies and gentlemen, I am a highly knowledgeable pilot, I have decided not to bother with the preflight checklists today" then I would expect there to be an instant mad rush for the exits. Or a surgeon, with the pre-operational checklists described in Atul Gwande's book, which I covered in this blog post on checklists. As I say in the post, most jobs nowadays are incredibly complex. The human brain can only remember so much at one time, and suffers easily from overload. Most mistakes are made, not because we don’t know what to do, but because we forget (or skip) a crucial step, especially in emergency situations. We need to be reminded of what we know, and what we need to remember. Checklists (recipes) force us to stop and review, remind us of what needs to be done, take us through the critical steps, ensure we remember the right things, ensure we ask the right questions, and ensure we have the right conversations. And updates in checklists as a result of new knowledge, can remind us to do new things.

Fourthly, too many chefs spoil the broth. Every kitchen needs a chef, then they need some sous-chefs, then they need a whole stack of people to follow recipes and follow orders. SImilarly every organisation will contain a whole spectrum of knowledge workers, and on each stage of their knowledge journey, they need their knowledge delviered or developed in a differrent way. We all start off as recipe followers, some of us end up as chefs, but we are all knowledge workers and KM needs to address all our needs.

"The director's blog"

  

---

How do you start blogging in a company?

Let's assume

1) that you want to introduce Knowledge Management,
2) that you want to improve exchange and re-use of knowledge between peers in the organisation,
3) that you want to make a difference to business results, and
4) that you have chosen Blogging as a component in the toolbox (though personally I would put it way down the list of places to start, preferring always to start with Tacit Pull, not Explicit Push).

So how do you get blogging up and running?

Here's a good way, and a not so good way.

The good way is to take the already existing internal communication mechanisms within communities of practice, and replace some of these with blogs. Take the ways people currently try to share knowledge, and improve them. For example -

• Maybe your community of practice has a quarterly newsletter, with a dozen articles. Replace this with a weekly blog, in order to get the news out more quickly, and in order to for allow commentary on, and discussion of the key items (which was never possible in a hard copy newsletter).
• Your community of practice may routinely send out email alerts about new lessons, improve practices, and other things that the community members really need to know about. Replace these Email alerts with blog items, which can be searched, can spawn comment threads, and which to avoid the curse of "reply all".

In both cases, the blog is a better alternative to existing mechanisms of sharing knowledge between peers within a community of practice.
A not so good way to get started is to set up a director's blog. This is tempting ; you can ask your senior sponsor to take the lead in blogging and set an example for the organisation, and he or she will very often agree. However the problems are as follows;

• A director blogging is a bit like a director standing up behind the lectern and making a speech. It's heirarchical - it's seen as "me preaching to all of you".  Is not really very conducive to two-way discussion or dialogue. Most of the directors blogs that I have seen have been one-way, with little or no comments. And if you want to know more, there are pressures against picking up the phone and asking the director for more details.
• Very rarely is it knowledge. Most of the directors blogs that I have seen have been general musings, or thought pieces. They may sometimes be of interest to the audience, but they're not going to teach the audience anything that helps them do their job better. It won't make a difference to the way people work. It won't add immediate value.
• If you are a director, you care about style (with a few happy exceptions, of course). You want your post to be well crafted.  You may even get somebody else to write it for you.  It becomes formal, it becomes a publication, and not the start of an informal conversation. That's not the KM message you want to give.
• It's "something extra to read". Instead of providing a better alternative to existing mechanisms of sharing knowledge between peers, you have created something new to read which doesn't teach you anything that really helps you, but is just "yet another communication from management". And that's probably the last thing that anyone wants - yet another communication from management!  You have just turned your KM offering into a burden and not an aid. 

 Think carefully about how you promote blogging. Start by modelling the outcome that you want to see, which is sharing of useful knowledge that others will use to improve the way they work. Think about the WIIFM for the reader, and make sure the blog gives them something they can use immediately to make their life easier.

Beware the seductive but potentially damaging option of the director's blog.