Why effective knowledge transfer requires nuanced language

To be able to transfer subtleties of knowledge, we need subtleties of language.

Image from wikimedia commons

The Eskimo languages have, it is claimed, 50 words for snow (falling or lying snow, and ice).  This may or may not be true, but their various words can carry a huge amount of subtle detail, and this detail is vitally important for a people that live, travel and hunt on snow.

For example there is a word “Nuyileq”, meaning “crushed ice beginning to spread out; dangerous to walk on. The ice is dissolving, but still has not dispersed in water, although it is vulnerable for one to fall through and to sink. Sometimes seals can even surface on this ice because the water is starting to appear.” (source here). This is a crucial distinction if you intend to  travel on this ice.

Those of us who live in temperate and tropical cities find this level of detail remarkable.  Snow is an unusual feature for us, and we basically only have two or three words for it; snow, slush, and “the wrong sort of snow” (the stuff that shuts down the rail network).  To have 50 words seems quite amazing.

Winter mountain climbers on the other hand, who rely on snow and ice for the safe ascent of mountains, have additional words –

  • “Neve” – that tough snow that securely holds the pick of your ice-axe
  • “Rime” – the coating of frost and snow over rock which you can brush off using a glove
  • “Spindrift” – fine falling snow swirling in the air, not enough for an avalance, but enough to get down your neck and soak your shirt
  • “Cornice” – the awkward overhang of snow at the top of your climb which you must circumvent, or tunnel through.
  • “Verglas”  – a thin coating of ice that forms over rocks when rainfall or melting snow freezes on rock. Hard to climb on as there is insufficient depth for your crampons to have reliable penetration.

Words convey nuance, and the more important a context is to you, the more nuance you need and the more words you use. Some call this jargon, but really it is nuanced communication which allows efficient and effective knowledge sharing.

As an example of nuance, the UK is a very wet place, and how many English words do we have for water?  Falling water, or water lying or running across the ground?  We certainly have many more than 50, and yet water is not much more complex than snow.  See the list below, and add more if you want to. (This article suggests the Scots have 100 words for rain, but to be honest, some of these are cheating).

We have so many words because water is a very familiar concept to us, we know it well, we see it in its manifestations and all its scales, it affects our travel, our gardens and our crops, and we know it well enough to make fine and subtle differentiations. It is useful for us to be able to differentiate between different types of water, just as it is useful for the Inuit to differentiate between different types of snow.

This actually makes it quite difficult to exchange knowledge between two such different contexts. 

 Without some experience of different types of snow, or different types of water, you don’t have the words to explain the difference.  In fact without the experience of the subtleties, you can’t understand the differences.  And how do you communicate when you cant understand the meanings behind the words? How do you exchange knowledge, when the contexts are not there?

That is why one of the first things you need to do when setting up knowledge transfer between people with different contexts is to agree on terminology, and what it means. 

And those fifty words for water? Here’s 55 – tell me if I have missed any!

  1. Drip
  2. Drop
  3. Droplet
  4. Rain
  5. Shower
  6. Deluge
  7. Downpour
  8. Drizzle
  9. Mist
  10. Fog
  11. Smirr
  12. Puddle
  13. Pond
  14. Pool
  15. Lake
  16. Tarn
  17. Loch
  18. Lochan
  19. Mere
  20. Ditch
  21. Dyke
  22. Swamp
  23. Bog
  24. Lagoon
  25. Oasis
  26. Seep
  27. Spring
  28. Source
  29. Spout
  30. Fountain
  31. Rising
  32. Creek
  33. Trickle
  34. Rivulet
  35. Tributary
  36. Stream
  37. Brook
  38. Bourne
  39. Brooklet
  40. Streamlet
  41. Beck
  42. Burn
  43. Gill
  44. Rill
  45. Runnell
  46. Rapids
  47. Waterfall
  48. Force
  49. Falls
  50. Cascade
  51. Cataract
  52. Flume
  53. River
  54. Flood
  55. Estuary

View Original Source (nickmilton.com) Here.

Is questioning the most important skill for the KM professional?

Perhaps the most important skill for the KM professional is the skill of Questioning.

Questions are the hook from which most of your knowledge hangs. Anyone with small children knows that itireless questioning underpins their early learning. The same principle applies in organisations.  Making knowledge conscious, making it explicit, and capturing or transferring that knowledge is triggered through the use of questions.

Poor questions result in poor knowledge, or result in knowledge never been identified in the first place. We recognised this recently when working with a company who had been trying to identify knowledge through Retrospects, without giving any training in questioning skills to the Retrospect facilitators. As a result, the knowledge gathered was superficial and of very low value.

Questioning is important in knowledge interviews, when you are trying to help the interviewee to reflect on their experience. Group questioning works the same way in the after action review and retrospect processes. In communities of practice, the facilitator often needs to “question the question”, and find out what a community member is really asking about and looking for, before they a question can be answered.

Questioning techniques include the use of open questions, the use of probing questions to get down to the next level of detail, the use of closed questions to home in on a learning point, and the use of summarising and feeding back to ensure you have fully understood the answers. We terach the skills of open questioning, and the use of question trees, in our core Knowledge Management traning courses.

Listening skills are also very important, and are part of good questioning technique.  Listening carefully to the answer, assessing how much knowledge has been provided, and asking additional questions to fill the gaps – this is also part of the Knowledge Manager’s skillset.

Ensure your KM staff are skilled in questuioning and listening.

View Original Source (nickmilton.com) Here.

When KM becomes group therapy

There can come a time when the therapeutic benefits of Knowledge Management can outweigh the commercial benefits.

[25/365] On the couch (Explored)One of the spin-off benefits of Knowledge Management is the culture change it can bring with it. Facilitated dialogue-based processes such as after action review, peer assist, retrospect etc are all themselves agents of culture change.

However they can have other spin-off benefits as well, and at times the facilitated listening almost acts as therapy.

When I am facilitating a retrospect, particularly from a project that has had its troubles, or was a bit of a disaster, it almost feels like I am conducting a group therapy session. If a project really was a bad experience, then it really helps the team to be able to talk about it in an open and non judgemental way. And that’s what a retrospect is; it’s a session where you talk about what happened in a non judgemental way. It’s a no blame process. (As I often say, when teaching the skills of Retrospect, that we will ask What, How and Why – What happened, Why did it happen, and How do we ensure it doesnt happen again – but we never ask Who).

People at the session really appreciate the chance to talk through the problems and challenges,they appreciate being asked for their views and being listened to,  and even more they appreciate the commitment to identify and apply lessons which make sure that similar projects will not have to go through the same trouble as theirs did. It’s more than just the chance to talk, it’s the opportunity to make a difference.

This feeling of “Therapy through Learning” comes back strongly when I recall an exercise I did on an offshore gas rig a long time ago.

 This visit was in the aftermath of a merger where things had not always gone well, and where the staff on this particular rig had ended up with a real feeling of grievance and anger. I spent a couple of days on the rig conducting learning interviews, and people were very forthright about the feelings that they shared with me. I came away with a whole list of learnings for the future, and I was sitting in the departure room waiting for the helicopter, feeling emotionally quite exhausted, and one of the roughnecks I had spoken to walked past. Seeing me he stopped, came over and shook my hand and said “I just want to say thanks mate. It was really good of the company to send somebody out just to listen to us”.

That’s when I realized that, although the learning was the primary objective from this exercise, it had not been the only benefit, and even if all I had done was listened, I would have still added real value.

View Original Source (nickmilton.com) Here.

There are only 4 types of barrier to Knowledge Management

Here’s a great Boston Square which looks at the four barriers to KM in a generic way.

It looks at the unwillingness and the inability that can affect both the knowledge supplier, and the knowledge user. Any combination of these is a block to Knowledge management.

The Supplier is Unwilling to share.

The unwilling supplier is afflicted by Knowledge Hoarding. He or she feels they will lose something (power, job security, reputation) if they give their knowledge away. Luckily we can demonstrate that this is not true, and managers can ease the shift from hoarding to sharing by careful use of incentives, eventually outlawing hoarding entirely.

The User is Unwilling to learn.

The unwilling user is afflicted by Not Invented Here (NIH). He or she feels more secure in their own (“invented here”) knowledge than in scary knowledge from somewhere else. This barrier can be addressed by redefining “here”, so that “invented in my community” equates to “invented here“, by using performance metrics to shock people out of complacency, and eventually by outlawing NIH completely.

The Supplier is Unable to share

The unable supplier suffers from the Stranger problem – “I don’t know who to share this with”. This can be tackled through developing a Pull-based approach, so that they share by answering  the questions of an individual or team (through community forums, or peer assist), or by using the concept of the “Unknown User” – the psychological construct that we can bring into retrospects and after action reviews.

The User is Unable to find knowledge

The unable user suffers from “needle in a haystack” – they don’t know where to look. Here we need the knowledge assets, that synthesised knowledge that creates the faucet rather than the firehose. We need the expertise locator. We need good search, and we need the places to ask – the community forums described above.

All four of these barriers are very real. All four can be overcome.  The Ability to share and learn is provided by the creation and roll-out of a Knowledge management framework, while the Willingness to share and learn is provided by culture change and communication activities, and cemented by KM governance. 

View Original Source (nickmilton.com) Here.

The "One Year After" knowledge capture event.

Many of us are used to holding knowledge capture events at the end of a project.  There is also merit in repeating this exercise one year (or more) later.

Imagine a project that designs and builds something – a factory, for example, or a toll bridge, or a block of student accommodation. Typically such a project may capture lessons throughout the project lifetime, using After Action Reviews to capture project-specific lessons for immediate re-use, and may then capture end-of-project lessons using a Retrospect, looking back over the life of the project to identify knowledge which can be passed on to future projects. This end-of-project review tends to look at the efficiency of the practices used during the project, and how these may be improved going forward. 
The review asks “Was the project done right, and how can future projects be done better”.  However what the review often does not cover is “Was the right project done?”
At the end of the project the factory is not yet operational, the bridge has only just opened to traffic, and you have just cut the ribbon on the student accommodation block. You do not yet know how well the outcome of the project will perform in practice. 

This is where the One-Year operational lessons review comes in.

You hold this review after a year or more of operation. 
  • You look at factory throughput, and whether the lines are designed well, how they are being used, how effective the start-up process was, whether there are any bottlenecks in dispatch and access, and even whether the factory is in the correct location. 
  • You look at traffic over the bridge – is it at expected levels? Is it overused or underused? Is it bringing in the expected level of tolls? Does the bridge relieve congestion or cause congestion somewhere else? Does the road over the bridge have enough lanes?  Does it ice up in winter?
  • You look at usage of the student accommodation. Is it being used as expected? Are the kitchens big ebnough? Are there enough bike racks? Where is the wear and tear on the corridors? Where are accidents happening? What do the neighbours think?
In this review you are looking not at whether the project was done right, but whether it was the right project (or at least the right design). The One Year operational learning review will generate really useful lessons to help you improve your design, and your choice of projects, in future. 

Don’t stop collecting lessons at the end of the project, collect more once you have seen the results of a year or more of operations.

Contact Knoco for help in designing your lesson learned program.

View Original Source (nickmilton.com) Here.

Why storing project files is not the same as storing project knowledge

There is often an assumption that storing project files equates to managing knowledge on behalf of future projects. This is wrong, and here’s why.

For example, see this video from the USACE Knowledge Management program says “if you digitise your paper files, throw in some metadata tagging, and use our search appliance, finding what you need for your [future] project is easy”. (I have added the word [future] as this was proposed as a solution to the next project now anticipating things in advance).

However there is a major flaw with just digitising, tagging and filing the project documents and assuming that this transfers knowledge, and the flaw is that the project may have been doing things wrong, and almost certainly could have done things better with hindsight. Capturing the files will capture the mistakes, but will not capture the hindsight, which is where the learning and the knowledge resides.

It is that hindsight you need to capture, not the files themselves.

  • Don’t capture the bid package presented to the client, capture what you should have bid, the price you should have quoted, and the package you should have used. All of these things should come from the post-bid win/loss review.
  • Don’t capture the proposed project budget, capture the actual budget, where the cost overruns were, and how you would avoid these next time. This should come from the post-project lessons review.
  • Don’t capture the project resource plan, capture the resource plan you should have had, and the resourcing you would recommend to future projects of this type. This also should come from the post-project lessons review.
  • Don’t capture the planned product design, capture the as-built design, where the adjustments were made, and why they were made. (See  my own experience of working from stored plans and not as-built design which cost me £500 and ten dead trees).
  • And so on. You can no doubt think of other examples.
Capturing the hindsight is extra work, and requires analysis and reflection through Knowledge Management processes such as After Action Review and Retrospect. These processes need to be schedules within the project plan, and need to focus on questions such as 
  • What have we learned?
  • What would we repeat?
  • What would we do differently?
  • What advice and guidance, with the benefit of hindsight, would we give to future projects?
These are tough questions, focused on deriving hindsight (as in the blog picture above). Deriving hindsight is not easy, which is why these Knowledge Management processes need to be given time, space, and skilled facilitation. However they add huge value to future projects by capturing the lessons of hindsight.  Merely filing and tagging the project files is far easier, but will capture none of the hindsight and so none of the knowledge.

Capturing documents from previous projects and repeating what they did will cause you to repeat their mistakes. Better to capture their hindsight, so it can be turned into foresight for future projects. 

View Original Source (nickmilton.com) Here.

Here is a useful KM Strategy matrix

This a a reprise of a post from 5 years ago, describing a useful matrux for plotting your strategic knowledge topics.

I first described this matrix in this article in KM review in 2007, as a tool which can be useful in developing your KM strategy.

This Boston Square-style matrix is formed of two axes; the current level of in-house knowledge, and the global level of maturity of that knowledge (i.e. whether it is new knowledge with a significant rate of evolution, or old established knowledge which is no longer evolving). These two variables allow key knowledge topics important to your organisation to be plotted into one of four boxes on the matrix, as described below.

  • New Knowledge.These are areas of new evolving knowledge which the company thinks will be very important in the future, but which currently they know little about. The KM focus for strategic new knowledge is on experimentation and knowledge creation, particularly from pilot programs. Ownership of New Knowledge may lie with the R&D or technology departments.
  • Competitive knowledge.These are areas of new evolving knowledge that the company knows a lot about. This knowledge may well give them a competitive advantage – the first learner advantage. In areas of evolving knowledge, the company that learns the best and learns the fastest, has the potential to outperform its rivals.  The KM focus for competitive knowledge is on the development of best practice. As this knowledge is being applied around the business, there needs to be a continuous capture of knowledge from practice, comparing of knowledge through communities of practice, and development of best practice. Ownership of competitive competence probably lies with the communities and networks. 
  • Core knowledge. These are areas of established knowledge that the company knows a lot about. This knowledge is likely to be core to their existing business, and needs to be managed well if the business is to perform efficiently and effectively. The KM focus for core knowledge is on the development of standards. Once the knowledge area is mature and established, best practice can be codified into standards and routines, and embedded in the work practices and procedures of the organisation. In some cases it can even be embedded into software or mechanised processes.  Ownership of this type of knowledge lies with the technical functions and in-house experts.
  • Non-core knowledge These are areas of established knowledge that the company knows very little about. These should be areas where the company has chosen not to apply this knowledge itself, but it may be areas where they have lost knowledge through retirement of key staff.

Using the matrix

Knowledge Management is not just about categorising knowledge, but more about working with knowledge.  This matrix therefore becomes a lot more useful when you use it not just to categorise knowledge, but to plot where you would like knowledge to move to, over time.

  • Imagine some new knowledge, developed in your research centre, which is currently in the “new knowledge” box, somewhere towards the top of the box as well. It is low maturity, and few people in your organisation know about it. You would like it to become competitive knowledge. Therefore it probably needs to increase in maturity a little until it is robust, and then needs to be a lot more widespread within your company. You move it from the top left box to the top right box, following blue arrow number one. You set up the communities of practice, and begin to deploy this knowledge, discussing it within the community and refining it into good practice through use. 
  • Imagine some competitive knowledge which you would like to be core to your business. It is currently relatively low maturity, but widespread in the company. You would like it to be more mature, so that you can embed it into processes and routines. The community needs to compare practices, choose the best, and come up with a standard company approach, documented in the knowledge base. The knowledge moves from the top right box to the bottom right, along blue arrow number two. 
  • Imagine some core knowledge which you decide, in the future, can be non-core. You would rather outsource it. You need to take your definition or specification for standardised knowledge, and move it outside the company so that you no longer have to deal with this area of knowledge. Someone else will manage it for you (which means that you need to make sure they have a good knowledge management capability themselves). The knowledge moves from bottom right box to bottom left, along blue arrow number three. 
  • Alternatively there may be knowledge which is currently non-core, but you need to insource it. You need to learn from those who do it well, develop a standard approach, and deploy this widely within your organisation. The knowledge moves from left to right along blue arrow number four. 

So you can use this matrix not only to plot the current status of your critical knowledge areas, but also plot where you want them to be in future. You can determine how you would like this knowledge to move along the strategic matrix, and you can put in place the knowledge management activities that will move the knowledge to where you want it.

Contact Knoco if you want more help with your Knowledge Management Strategy

View Original Source (nickmilton.com) Here.

Why beginners and experts behave differently in KM

Experts and beginners behave differently in Knowledge Management systems. Here’s why.

Great Meadows Fishing Day 2010
Great Meadows Fishing Day by U. S. Fish and Wildlife Service, on Flickr

Confucius said “Shall I tell you what true knowledge is? When you know, to know that you know, and when you do not know, to know that you do not know—that is true knowledge”. So the true expert is the person who knows what they know, and what they don’t know.

Before you get that true knowledge, before you become an expert, you don’t know what you know and you don’t know what you don’t know.  That’s a description of a beginner, or a novice; beginners do not yet know the level of their ignorance.

In knowledge management terms, that means you have to treat the beginners and the experts differently. Experts, and budding experts, will become fully involved in Communities of Practice – gaining knowledge through discussions and through questions., When they need knowledge, they will ask for it and receive answers. Their questions are clear and focused, because they know what they don’t know. They won’t tend to use the Knowledge Base so much, as they already know what they know, and are looking to “fill in the gaps” in their knowledge that probable aren’t in the knowledge base.

The novices, on the other hand, will not take part in the community discussions, although they may “lurk” – read the conversations but without taking part. Because they don’t know what they don’t know, they don’t know what questions to ask. When they do ask questions, they tend to be general and basic rather than specific and targeted. However the beginner will find the knowledge base – the wikis, the FAQs – very useful, because it gives them the full picture. It shows them all aspects of the knowledge, so they can understand the full range of the things they don’t know.

The demographics of the workforce determines which knowledge management tools to focus on. A company with large numbers of experienced staff will get huge value from communities of practice, and from question-led discussions among the experts and budding experts. A company with large numbers of new staff and inexperienced staff may get more benefit from building FAQs, knowledge bases and wikis. 

View Original Source (nickmilton.com) Here.

What to do when knowledge is a core product deliverable

For some projects, knowledge is their most important deliverable, but how is that deliverable defined?

We are used to thinking of knowledge as an input for a project, but it is often an output as well. Projects can learn new things, and can create new knowledge for an organisation. Often we assume that this new knowledge will be transferred through the lesson learned system, but is that really enough?

Usually it isn’t, and instead a different approach might be better.
Lessons are increments  of knowledge, usually identified after the event, at the end of an activity or a project stage. In an ideal world every lessons would be associated with an action, and each action would lead to the update of a best practice, a doctrine or a corporate standard. Lessons are usually captured in a team meeting such as a Retrospect.
However if a project is doing something new – something which has never been done before – then the standard lesson approach is insufficient. Rather than identifying and capturing the learning after the event, the organisation should identify the potential for learning at the start of the project, make sure resources are assigned to learning, and require the project to create a guideline, best practice or standard as a project deliverable. 
Imagine an organisational project to set up the company’s first manufacturing facility in Asia – the first of many such plants in an expansion program. The project is expected to deliver a manufacturing plant with a certain production capability, and the success of the project will usually be measured by whether the plant is delivered on time, to quality and to budget. However the success of the program will be influenced by how mush knowledge is passed from the first plant to the others, and the value of this knowledge may be higher than the value of the plant itself.
Therefore the project can be given a second deliverable – to create best practice guidance documents, doctrine or first-pass standards on topics such as
  • Doing business in that particular Asian country
  • How to negotiate the bureaucracy
  • How to obtain permits
  • How to construct the plant efficiently and effectively
  • How to recruit a skilled workforce
and many other topics. These deliverables should be managed through the project KM plan, and reported to management the same as other deliverables.
This set of knowledge deliverables could be given its own resources and its own workstream, in order to make sure that the knowledge is captured. Without this focus on knowledge, it is quite possible to get to the end of the project and find that no knowledge has been captured at all. 

View Original Source (nickmilton.com) Here.

Skip to toolbar