Knowledge definition

---

Singapore Tag
Originally uploaded by koalazymonkey

Following up on my earlier post on "What is Knowledge" - here is a definition from the Singapore Armed Forces.


Our definition of knowledge is "the capacity to take effective action in varied and uncertain situations"

This is only a slight variant of Senge's definition, which is close to my favourite definition. Its a great definition, because it takes us away from documents and content and facts and Information and Data, and takes us into the human realm of decisions and actions.

It also points towards the purpose of KM, which is to IMPROVE our capacity to take effective action in varied and uncertain situations.

What's the lesson? A cautionary tale.

---

Nice car door handle
Originally uploaded by matthew solle

Sometimes incidents happen through a very unusual combination of circumstances - so unusual, that sometimes you don't always know what the lesson was, or what action can be taken. However if you look at root cause, then you can learn.

Here's what happened to me yesterday. See what you can learn from it.

I had a day-long appointment in BP, and drove there from Bath (a 2 1/2 hour drive).

By the time I got to BP, all the visitor parking was full so I went into the multi storey car park.

BP require you to put your headlights on in the multistorey, so despite it being a sunny day, I did so.

The multistorey car park contains small bays, holding 2 or 3 cars, with the bays separated by concrete pillars. The car park was almost full, but I found a space on the 3rd level next to a huge SUV.

BP require you to reverse park, for safety reasons. When you reverse park, the concrete pillar is level with your door handle.

The only way I could fit into the bay and to allow the SUV owner access, was to park right next to the pillar (which was on the drivers side, against the door). So I parked snug to the pillar, climbed over to the passenger side, exited through the passenger door, locked the car with remote locking, and went into the office.

If you exit the driver door with the headlights still on, it warns you with a warning tone. If you exit the passenger door with the headlights still on, there is no warning tone! And in the bright sunlight, I failed to see that I had left my headlights on.

8 hours later, I returned to the car. The remote locking would not unlock the car (not surprising, as the battery was flat). So I would need to unlock the car manually.

I discovered that the car only has ONE manual keyhole.

This is on the drivers door.

The drivers door was snug against the pillar and could not be opened more than a couple of inches.

I could open it enough to reach in with one arm, and reach back to the rear door, but this would not open either, as the central locking is electrically activated. No other door had a keyhole, not even the boot (trunk). I could not open the bonnet (hood) either as that has to be opened from inside the car.

So I had to call the RAC, who arrived 2 hours later, and we eventually put a trolley jack under the car and pulled it sideways until the driver door could be opened.

So there is a weird combination of circumstances that cost me 2 1/2 hours of my time. Is there anything generic we can learn from this? Well, if you do a root cause analysis, there is one thing I failed to realise, and that's where the lesson may be for you.

Do you know how many doors on your car can be opened manually, with a key?

Do you really? Have you ever looked?

I didn't know. I know now! Only one!! And I will never again park in a situation where that door cannot be opened, because it results in an unacceptable risk - if the car battery or the key battery go flat, or there is some other failure of the remote locking mechanism, I will be severely stuck. Again.

So, dear reader, here's the action for you from this lesson.

Next time you go out to your car, before clicking the remote button, walk around and see how many keyholes your car has. Then, based on that knowledge, you can design an effective and risk free parking strategy.

A story of a closed learning loop

---

I blogged recently about the 3 steps of the learning loop

My friend Paul (pictured), when he was working at the charity Tearfund (which provides aid to disaster victims), provided me with a really excellent example of a closed learning loop. Here's the story as he told it

"One thing that is very good to do to demonstrate the success of Knowledge Management is the conscious and systematic application of Lessons Learned. Otherwise if it is not conscious, everyone assumes someone else will do it and it never happens. A very good example is the various Learning Afters we did on disaster response at Tearfund. We did 8Learning Afters from 8 disasters; sometimes from a single team, and sometimes across most of the organisation. What we found from those 8 Learning Afters is that we came up with over 300 Lessons Learned (or Specific Actionable Recommendations, as I called them).

300 is a big number! What can you do with these things? You cant do very much with 300 if you try to tackle them all head on. But what we did notice is that many of those lessons were coming up more than once. So somebody in the disaster response area - not myself; it was important that someone in the activity area did this - they took the day out, they went home with a stack of yellow post-it notes, and they sorted out all these lessons and quantified how many of these lessons came up more than once.

One of these lessons came up 6 times out of the 8. 3 others came up 4 or 5 times, and about 22 more lessons came up 3 times. All the rest that came up once or twice, we decided to put these aside for now, and the 25 to 30 lessons that came up 3 or more times out of 8, this chap took the time to embed them into the processes, guidelines and job descriptions, terms of reference, or whatever, so that next time theres a disaster, you just have to follow those latest guidelines and processes, knowing that, and in confidence that, somebody has taken the time to embed the learning. That has been very helpful for Tearfund".

Thats a simple learning loop, involving no more technology than face to face meetings and a wall covered in post-it notes. But it's a closed loop, and you can see the three steps.

• A learning step, using what Tearfund called "Learning After" meetings (what we call Retrospects) to derive Lessons Learned.
• A sorting, validation and action step, where action is taken to update the guidance documents
• A re-use step, where people follow the guidance in confidence that it reflects the latest learning.

That's a neat closed loop. Operational experience leading to learning, learning leading to change, change leading to more effective operations.

KM, road safety and Hollywood Actresses

---

THINK! Safety sign
Originally uploaded by Gene Hunt

As reported here

"Asian film icon and Hollywood actress Michelle Yeoh, together with the Asian
Development Bank (ADB), called for the prioritization of road safety in the
region during a transport forum at the ADB Headquarters in Mandaluyong City
Wednesday morning.

The Malaysian actress of “Tomorrow Never Dies,”
“Crouching Tiger, Hidden Dragon,” and “Memoirs of a Geisha” fame paid her first
visit to Manila to participate in the ADB Transport Forum “Changing Course:
Pathways to Sustainable Transport.”

She spoke in Wednesday’s morning session alongside ADB Vice-President for Knowledge Management and Sustainable Development Ursula Schaefer-Preuss".

The mixture of Hollywood and KM is unusual, but the mixture of KM and Road Safety is not so unusual. We were involved with BP in the early 2000s in conducting a Learning History on Road safety in Turkey, the learning from which was shared via a very active and committed community of practice, and reused in many parts of the world to reduce deaths from road accidents.

Delivering effective road safety initiatives is an excellent focus for KM initiatives. What would be even more powerful would be a broader sharing between the development sector and the private sector. I wonder what the ADB, and Michelle Yeoh, could glean from the BP success, for example?

Lessons learned definition

---

Day 1 "Learner"
Originally uploaded by Little Silver

There is a lot of fuzziness about the topic of learning and lessons, and I thought it was worth sharing a couple of definitions.

There is very valuable distinction to be made between lessons learned and lessons identified, a distinction which is made very clear in the lesson learning systems applied in the UK military sector.

The operational units of the UK Ministry of Defence define an identified lesson as learning which has the potential to add value and which needs to be communicated, and recognise that a lesson does not become learned until something changes as a result.

I think we could therefore work with the following definitions

A lesson identified is a recommendation, based on analysed experience (positive or negative), from which others can learn in order to improve their performance on a specific task or objective.

A lesson learned is a change in personal or organisational behaviour, as a result of learning from experience.

Ideally this will be a permanent, institutionalised change, but we know that lessons are not always permanent, and can be unlearned as well as learned, so I will leave the word ‘institutionalised’ out of the definition for the moment.

So if learning a lesson has to involve a change in behaviour, perhaps the change IS the lesson.

So you could say
"I always look over my shoulder before opening the car door - that's a lesson I learned from a cyclist friend".
"We always specify in the contract that our contractors have a demonstrable and effective knowledge management system - that's the lesson we learned from that repeat mistake in Malaysia".
"Since the holiday in Madrid, I always pack my medicines bag in my carry-on baggage. I've learned that lesson!"

Without the change, the lesson has not been learned. Therefore the change is the learned lesson.

The 3 steps of the lessons learned loop

---

There are three main steps in Learning a lesson – Identification, Action, and Institutionalisation.

Identification means the review of activity, to derive learning points. An individual or a team looks back on a project or an event, and recalls what happens. Activities or tasks are identified where there was a difference between what was planned or expected, and what actually happened. This can be a positive or negative difference – things may have gone better than expected, or worse than expected. The individual or the team, often with the help of a facilitator, discusses the root causes behind what happened, and what can be learned as a result. What are the identified lessons? What should be done in future activity to avoid the pitfall, or to repeat the success? At this stage we have new lessons in the form of "Lessons Identified" (not yet Lessons learned).


Action means taking action as a result of that learning, generally either to fix something immediately, or to update a process or practice or procedure. A “Lesson Identified” is not an end in itself, but is a temporary step along the way to making a change, and to improving something. Think about an identified lesson coming out of a Retrospect, or some other form of review. What have you learned? You have either learned a way to do something for the first time, or a better way to do something, or a new way NOT to do something, or that something needs to be fixed (such as replacing equipment, training staff, changing reporting lines, extending a contract etc). So the lesson points to one of several actions, such as documenting a process improvement (or a new process), or fixing something. If the lesson is validated and the action taken, then the outcome will be improved processes and practices.

Institutionalisation means embedding the improved practice in the working habits of the organisation. You need to ensure the new or improved process reaches the people who need it, and that they act on it and adopt it in their activity. This could include broadcasting the change in a newsletter or blog, ensuring people are subscribed to an automatic feed for process updates, incorporating the new process or doctrine in training, talking through the new process in briefings, and toolbox talks, and many other approaches.

Until the lesson finds its way back into action, we can't say that it is learned. And it wont find its way, unless these three steps are taken.

Opinions as art (quote)

---

Any clod can have the facts, but having opinions is an art.
- Charles McCabe

The forgetting curve

---

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

We had an interesting twist to the game a couple of weeks ago, where we had two people in the class who had done the game before, about 6 months ago (see also here, for a previous example). Now you might expect that this previous experience and knowledge would give them an edge, They would remember some of the key design principle from the game, you might expect, and they should therefore be well ahead of the other teams. So I put these two people with experience into the same team, to see if this would happen.

Well, it happened to an extent. The two people remembered some bits and pieces, and these included some highly level design principles, and a few tips and hints, However much of the other detail from the game had been lost over the previous 6 months. They built a tower slightly taller than the other teams, but one third the height of their performance 6 months previously. As one of them said in the debrief "a little knowledge is a dangerous thing".

The chart above shows their learning in the previous game, 6 months ago, with the blue and purple tower heights increasing as more knowledge was added. The red line is the learning curve they went through in the game. The grey bar represents their first tower, built with this hazy memory and "little knowledge" from the previous exercise. The green line is therefore the forgetting curve.

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

And when we come to use it again, we find we retain just enough to be dangerous.

Shell Knowledge Management ?

---

This is a really well-produced video from Shell about using what they term "knowledge management" for supporting and building their IT business applications. Its very impressive, and obviously a great success, but as you listen to it, it seems to be more about records, data and information management, than about KM. It is referred to, at one point, as an "IT Asset Management platform", which is probably a better term than "knowledge management system".

I know that Shell do some fantastic Knowledge Management on a whole variety of fronts - communities, wikis, collaboration, learning from experience - and it would be a shame to watch the video and think that this was the totality of Shell's KM approach. So, great video, great tool, but there's far more to KM at Shell than we see here.

Documenting the Why

---

Why on car
Originally uploaded by openpad

One of the pieces of knowledge which is seldom captures is Why things are done.

We often capture design data and information, we capture process and procedure, and we capture what has to be done, and by whom. But often we omit the Why.

An example comes from deepwater drilling back in the 90s, where one part of the organisation was learning from another part about a particular technique. The details of the technique were transferred, but not the reasoning behind it, and so the technique was applied in an inappropriate location, and didn't work. One of the partners involved with the well, however, picked up the technique and its rationale, and applied it successfully, at a saving of several million dollars compared to the previous technique.

If we capture the What of a technique, but not the Why, then

a) others can use it in the wrong situations
b) others can tinker with it, without understanding, and undermine the technique
c) when circumstances change, nobody knows how to adapt the technique
d) the technique can be applied long after it needs to be.

Its like the story of the cat in the monastery.

"When the spiritual teacher and his disciples began their evening meditation, a cat who lived in the monastery made such noise that it distracted them. One day the teacher ordered that the cat be tied up during the evening practice.

"Years later, when the teacher died, the cat continued to be tied up during the meditation session. And when the cat eventually died, another cat was brought to the monastery and tied up. Centuries later, learned descendants of the spiritual teacher wrote scholarly treatises about the religious significance of tying up a cat for meditation practice".

In this story, the practice has continued, because they lost the Why

So how do you capture the Why? I have seen this done using a document called Basis of Design. This captures the rationale behind a design of equipment or design of a process. It explains why the design is the way that it is.

Now many projects create a Basis of Design (BoD) document at the start of the project, as a preliminary document, but often the design itself evolves and is adapted to circumstance. The key to using BoD as a knowledge asset is to make sure that changes are reviewed, and the reasons for changes are captured.

In BP drilling, the Basis of Design was frequently used to capture decision making and the rationale behind well design, in case there were a gap in operations, and people had to come back later and start drilling again. In the past, what often happened was that knowledge would have been lost in the interim, but as one Alaskan drilling engineer said to me, "With a good Basis of Design, I could come up to this field and put a quality well program together in a week, and there hasn't been a rig drilling here for two years".

Success factors for large-organisation communities

---

A snippet from the Com-Prac Yahoo group, where Peter Stoyko laid out some conditions for large-org CoP success:


a) high tolerance for disagreement
b) well-supported professional/ learning networks
c) organizational knowledge centre
d) frequent face-to-face interaction
e) investment in employee development
f) realistic expectations
g) employee autonomy
h) discretionary time
i) common communities

Pouring weedkiller on the KM garden

---

Spring Garden
Originally uploaded by di_the_huntress

You don't want to be pouring weedkiller on your flower garden! Weedkiller has a job to do, but if used in the wrong place can kill the growth you have been trying to nurture.

The weedkiller that can spoil your KM garden is a common one - Internal Competition.

Companies often encourage internal competition as an incentive to drive performance in a company. They might set up "factory of the year" awards, to drive factory output, or they might reward the ten best salesmen with handsome bonuses.

However where parts of the company need to collaborate, share and reuse knowledge, then internal competition becomes the weedkiller on the garden. Why would one factory share knowledge with another, if they are in competition? Why would one sales executive help another, if that just meant that their bonus was more at risk? They wouldn't. They would hoard their knowledge for the competitive advantage it gives them. And the poor salesperson at the bottom of the pile - the one who needs to learn the most - finds nobody who will help them.

This actually happens. One organisation we worked with had a lesson database for sharing lessons between its production plants, while at the same time ran heavily incentivised annual competitions. They thought they had managed to link the two by having "numbers of shared lessons" as a metric in the competition, but what happened was that the plants would hoard up their lessons until a week before the competition, then release them in a flood. That way they satisfied the metric, but in such a way that the other plants had no time to review and apply the lessons, and so could not benefit from the knowledge sharing.

How would you get around this? Simple - instead of incentivising internal competition, you incentivise internal collaboration. Instead of incentivising one plant if it increases production, you incentivise all plants if all plants improve. Say you have 10 plants, which together produce 1 billion tonnes. Why not give ALL plant managers the target of reaching a total of 1.1 billion tonnes, with a handsome bonus if they achieve it? Why not give all the sales force the collective incentive of increasing sales by 10%? That would be a fantastic way of driving collaboration, because now it is in the interest of the strong performer to improve the results of the poor performer. The strong performers become mentors and coaches and guides.

The weedkiller of internal competition is replaced by the fertiliser of internal collaboration.

The ‘Once-only’ tolerance principle for mistakes.

---

Mistakes
Originally uploaded by plindberg

Anyone can make an honest mistake. Making mistakes is part of exploring, of innovating, and of pushing the boundaries. Nobody who ever made a breakthrough, never made a mistake.

Companies must tolerate honest mistakes if they are to encourage performance. People must be allowed to stick their necks out, and to go for the stretch goals, even if sometimes they fall short. However they should have fall-backs in place, and they should have done their rick management in advance. There is no merit in stupid mistakes.

However what companies should not tolerate is repeat mistakes. Tolerance of mistakes should operate on a once-only principle, provided Knowledge Management is in place. Once a mistake has been made, the company needs to learn from it, and never repeat it again. Repeat mistakes are evidence either that the KM system has flaws, or that people are not using it. And if we find out that there are no flaws in the system, then a repeat mistake shows that people are not using the system, are not “learning before doing”, are not doing the up-front due diligence to ensure they have all the knowledge they need, and are taking unnecessary risks.

And that should not be tolerated.

The safe zone

---

BE SAFE AND CONSIDERATE
Originally uploaded by Duchamp

Beginning Knowledge management - being the "first follower" for example - can feel risky. There is a degree of exposure in being open, in exploring mistakes and successes, in offering your know-how to others, and in asking help and advice from others. Especially if the culture is not supportive, the first follower can feel at risk.

Therefore, in the early stages, you may need to create "safe space" where people can explore KM processes with minimum risk. You may have to do the following;

• Careful facilitation of lessons capture, Retrospects and After Action Reviews, to ensure they are non-judgmental and focused on learning.


• Running your first Retrospects on successful projects


• Very careful facilitation of Peer Assists, to ensure they do not descend into attack-defend behaviours


• "Closed" communities of practice, restricted to the practitioners themselves and not accessible by their managers (again, with very careful facilitation lest the community becomes a moaning and bitching session)


• A close editorial eye on the wiki


• Clear upfront discussion, in all these instances, of the ground rules and of the behaviours we seek.

What I would not recommend is either of these -

• Anonymous posts in discussion forums (I have seen these
  degenerate into flame wars and prank postings)
  
• Anonymous lessons in the lessons database (if there
  is no provenance, people do not trust them)

In these two instances it becomes safe to behave badly. We want situations where it is safe to behave openly. And then once the behaviours are established, we can begin to relax the rules, and open up the safe zones for others to join in.

But right in the early stages, its important to feel safe enough to ask and share. As KM professionals, we need to create the Safe Zone.

Too much knowledge sharing devalues knowledge?

---

OK, this post has a provocative title, but I would like to make the case that a focus on knowledge sharing without a corresponding focus on knowledge seeking and re-use (note the qualification here) can have a detrimental effect on your KM efforts.

Let's think about knowledge sharing and knowledge seeking - knowledge push, and knowledge pull - knowledge supply, and knowledge demand.

Let's think in economic terms.

What happens when supply exceeds demand in a market? Prices fall, and value is destroyed. A commodity where supply far exceeds demand is a devalued commodity. Maybe supply will stimulate some demand, or maybe you just create an oversaturated market, and you end up dumping surplus stock.

What happens when demand exceeds supply? Prices rise, and value is created. A commodity where demand exceeds supply is a valued commodity. Almost always demand will create supply, and you will end up with a marketplace.

An oversupply of knowledge (full databases not being used, loads of stuff filed and not read, loads of blogs with no readers) devalues knowledge. Its seen as "a waste of time" to capture all this stuff. "Why bother? Nobody reads it". Knowledge sharing, without reuse, quickly becomes a low-value activity.

An overdemand for knowledge (lots of questions on community forums, lots of people searching for things, lots of expert opinions being sought, a few cracking blogs with eager readership) may cause frustration if the answer is NOT found, but certainly raises the value of the knowledge which is in there. What generally you find in this case is that initially the bulk of knowledge which is found is tacit (people find people to ask), but this level of demand will cause increasingly more knowledge to be documented. Once the expert has been asked the same question frequently enough, he/she starts an FAQ, and the supply of explicit knowledge starts to grow as well.

That's why I tend to react when people say "we must create a knowledge sharing culture". I would far rather create a culture of knowledge seeking and knowledge re-use, and use this demand to create supply and so raise the value of the knowledge itself.

Learning to Listen, Listening to Learn

---

When conducting a lessons capture session (what Nancy Dixon calls “sense-making”) it can be a good idea to bring along others who can immediately reuse the learning. This give the meeting a focus and purpose. You can ask “what would you advise Peter and Jenny to do on their project?

The problem comes when Peter and Jenny feel it is their role to solve the problems of the past. “Oh you shouldn’t have done it like that!” they say. “Why did you make that decision? I would have done this instead?” Commentary becomes critique, and the project team become defensive, and start to clam up.

The thing is, we hire people for their problem solving capability, but in situations like this, when they are guests and recipients in a sense-making session, problem solving has to be put to one side. The focus is listening and learning. I brief them first and say “your role is to listen for learning, to ask clarification questions, and to make sure you fully understand what they did, what they learned, and what you need to learn and do differently as a result. You are not there to judge or critique or audit, but to listen and learn”.

This need not be passive listening – they can ask as many clarification questions as they need – but it is a listening and learning role, and sometimes we need to help people learn how to listen, before they can listen how to learn.

Nancy Dixon on Lesson Learning

---

There’s a really interesting blog post here from Nancy Dixon on the complexity of Lessons Learned – thanks Nancy.

How many lessons?

---

Gold top 10 winner
Originally uploaded by sam_churchill

There seems to be a tendency to want to limit learning. I am reviewing a project at the moment, where the team decided to collect and discuss on their Top 10 lessons (actually 20, as they captured the Top 10 engineering lessons, and the Top 10 project management lessons). It puzzles me why they chose 10 lessons. This was a multi billion dollar project, and I bet they learned more than 10 things. So why restrict it to 10? Why not 12? What if there were 15 lessons - would we not record numbers 11 through 15?

Perhaps it was to avoid overloading the organisation? This may be a worthy aim, but no organisation I know of is overloaded by learning. Generally there is a dearth of good knowledge available, and people are very pleased to receive good helpful material. OK, I can understand restricting to 10 lessons if the lessons are turgid and boring and not very helpful, but that can’t be our aim, surely? I blogged recently about the project which generated 700 lessons, of which 400 were reused. What would have happened if they had restricted themselves to 10? 390 opportunities for learning and improvement would never have been re-used. 97.5% of the value would have been lost.

Perhaps it was to avoid overloading themselves. Perhaps they thought that documenting these lessons was not really worth doing and that it would a lot of effort, so lets high grade only the most important lessons. This may be a more likely scenario. But I think that's an unhelpful attitude. Why not identify all the valuable and reusable learning points, whether it's 9, 15, 19, 29? Why not document them all?

Why stop at 10?

Picasso quote

---

Picasso - Cubism 1937
Originally uploaded by oddsock

I am always doing that which I can not do, in order that I may learn how to do it.
- Pablo Picasso

see also "we only learn when we don't know what to do"

The push/pull gap in Knowledge Transfer

---

push pull
Originally uploaded by Robert S. Donovan

I have blogged before about push and pull in KM - push being the transfer of knowledge driven by supply (eg speculative publishing, or loading material to a database or wiki), and pull being the transfer of knowledge driven by demand (eg asking a question on a forum, or searching an Intranet).

The ideal KM system runs push and pull in parallel - both supply and demand as valid ways of transferring knowledge. However you often find systems which require push and pull to operate in series - ie knowledge is pushed halfway, and then needs to be pulled the rest of the way.

For example, the bog-standard lessons learned database.

People identify lessons, and post them to the database (push). The lessons then sit in the database until someone comes along and searches for them (pull). Both push and pull need to operate for transfer to happen - without one or the other, the system fails. And what generally happens is that (if the push part works), the lessons pile up in the database, gathering dust as it were, often never reaching the people who need to see them. This is the push pull gap.

But why not push the lessons all the way? Why can't your database have an RSS feature, or some other publish-and-subscribe, or be set to push the lessons to the people who need them? Why can the knowledge come looking for the user, rather than the user needing to go look for the knowledge? That way there is no gap.

In BP, the drillers had a lessons database that did just this. All lessons entered into the database were characterised, and automatically forwarded to teams working with similarly characterised contexts. I recall one engineer telling me about receiving a notification of a new lesson, a new piece of knowledge, and realising that a) it came from a team working in the same building, on the floor above him, and b) up to that point he had not realised this other team was working on that issue. He was able to take a short walk upstairs, and gathered some really useful knowledge. This was because the Push system pushed the knowledge all the way to his desktop, instead of relying on him to pull it part of the way.

Also you can't pull things, if you don't know they are there. You don't search for the things you don't know that you don't know. This is a situation where pull breaks down, and "pushing all the way" is the only answer.

KM - what tools are people looking for?

---

One of the things we offer on the Knoco website are a set of free reference papers and KM templates.

It is interesting to look at the frequency of requests for the various reference papers (blue) and templates (red), to see what people are interested in. And it seems like Knowledge Management Plans is a clear winner (we can discount the Communication Plan slightly, as this is not KM-specific) in terms of popularity, followed closely by KM Self Assessment. The Lessons Log template seems less popular only because it has only just been released. I suspect it will grow in popularity over time.

More surprising, perhaps, to see the traditional core KM tools of Peer Assist, Learning History and Retrospect at the bottom of the list, unless people feel they can access reference resources from elsewhere.

If you are interested in any of these tools and references, please visit our downloads page.

Facilitating internalisation

---

internalizing
Originally uploaded by eflon

Of all the steps in the SECI model proposed by Nonaka and Takeuchi (which we all know is not the only model in KM, but is still a good one), the most poorly documented step is internalisation.

We all know about Socialisation, the use of social structures such as Communities of Practice, and the use of social software.

We all know about Externalisation, and the use of dialogue-based techniques such as After Action Reviews and Retrospects to enable teams to externalise and capture deep Knowledge.

We all know about Combination, and how eternalised and/or captured knowledge can be combined into new forms, and organised and sorted and sifted using wikis (for example), and how processes such as Knowledge Exchange can combine knowledge from many sources.

But how much do we know about internalisation, especially the internalisation of captured and documented knowledge?

I often think we assume that people will just naturally do this for themselves, and read some lesson, or guideline, or set of tips and hints, and do all the internalisation naturally, without any help. And yet this is the part where KM approaches so often fail - the externalised and documented knowledge seldom gets passed forward into action.

Last week I wrote my post about the four facilitative roles in KM, it was easy to identify the roles that facilitate socialisation (the community facilitators, the contact brokers), the roles that facilitate externalisation (the facilitators of the After Action Reviews and Retrospects) and the roles that facilitate combination (the content owners, the process owners, the content managers.

But who facilitates internalisation?

This was brought back to me again recently in our famous Bird Island exercise, where instead of giving people the Knowledge Asset to read, we talk them through it, and emphasise the key points, and tell them what to consider, and what the impact will be to them. This is a key part of helping them internalise the knowledge. And yet do we ever do this at work?

In the Military sector, they do. They do it through exercises and training. Any update in doctrine - any new knowledge from the front line - is immediately incorporated into training and exercises. The trainers help the troops internalise the learning, often with post-training after action reviews.

In the oil sector, they sometimes do this. Through toolbox talks, pre-shift meetings and other briefings, new process knowledge and new safety knowledge is discussed and internalised before work starts. WHoever leads the talk, has a role to help people internalise.

But does this happen elsewhere? Does anyone else know of any examples of the facilitation of externalisation?

Copying knowledge beats innovation - proven?

---

Day 187
Originally uploaded by pasukaru76

There is a a fantastic article in the current issue of New Scientist magazine, entitled "You are what you copy", with the tag line "Forget free thinking, a talent for imitation is what really makes us smart".

This describes an experiment (actually an online tournament) to test out various social learning strategies. It tested variables such as the choice between copying and innovation, whether to copy the expert vs following the crowd, or whether to rely on what you know, and looked for agents who's chosen learning strategy gave them the greatest survival rate.

You can read the online summary for yourself, but here are some quotes from the magazine article.

"It seems a successful strategy rests primarily on the amount of social learning involved, with the most successful agents spending almost all their learning time observing rather than innovating"

"Avoiding spending too much time learning either socially or individually was
just as important. Between a tenth and a fifth of their life seemed to be the
optimal range. If they did more learning than that it seemed that life was just
passing them by."

"Successful strategies were also good at spacing out learning throughout the agents' lives. The winning strategy, Discount Machine, submitted by PhD students Daniel Cownden and Timothy Lillicrap from Queen's University in Ontario, Canada, stood out because it did just this. It seems packing all your learning into the early part of your life is not a great idea - we need to keep updating our knowledge as we go along".

"You don't need any clever copying rules. You can just copy anyone at random. Other individuals are doing the filtering for you. They will have tried out a number of behaviours and they will tend to perform the ones which are reaping the highest rewards."

"To become the winner of the tournament you .... have to weigh up the relative costs and benefits of sticking with the behaviour that you have, versus inventing a new behaviour, versus copying others. That requires assessing how quickly the environment is changing, as this gives you an idea of how quickly information will become outdated".

"In variable environments (the winner) placed a higher value on more recently
acquired information and discounted older information more readily".

"Another attribute of the most successful strategies is that they are parasitic. This is the essence of social learning - somebody has to do the hard graft to find out how to do things before other people can copy them, so it only pays to learn socially when there are some innovators around. Indeed, in contests where (the winning) agents were able to invade the entire population, they actually ended up with a lower average pay-off than they did in contests where the conditions allowed some agents with more innovative strategies to survive, so providing new behaviours to copy".

For the knowledge manager, this is really useful and interesting experimental input. Given the emphasis on innovation you often see, it is good to be reminded of the value of copying as an effective competitive strategy. Remember Intel's "copy exactly" program? Or BP's cloning concept? I remember one senior manager in BP saying "the problem with our people is that they are too innovative. They reinvent when they could copy". And I also remember a senior engineering guy telling me that his principle was "No Versions 1.0". They never wanted to be the guinea pig for new technology - innovation is risky, and sometimes the best strategy is to let others take the risks, and see how they pan out.

The need to adjust strategy depending on the variability of the environment is also interesting, suggesting that the variability of the knowledge context can affect the strategy needed to deal with it. Thats something I dealt with in this article.

The ideal learning percentage is an interesting statistic, also the fact that learning seems to be something that needs to happen constantly, rather than just at the start of your career.

The final learning point for me from all of this is that if we are looking at internal practices rather than competitive practices, then an organisation needs a knowledge management strategy that is strong on internal copying, leavened with a proportion of innovation. You need both - neither all copiers nor all innovators, but a blend of both (and the blend weighted towards the copiers). Also you need to ensure that the innovators capture or share enough knowledge that they can be copied!

Certainty is absurd

---

Voltaire
Originally uploaded by kevindooley

Doubt is not a pleasant condition, but certainty is absurd.
- Voltaire