Why so much knowledge sharing, so little knowledge seeking?

Knowledge Management requires knowledge seeking and knowledge sharing. But why so much focus in internal processes on sharing and so little on seeking?

Learning Happens
Learning Happens by shareski, on Flickr

One of the standard models for Knowledge Management in project environments is the idea of “Learning Before, During and After“.

Ideally these three activities should be embedded in project process, so that a project

  1. Starts by reviewing and accessing all the knowledge it needs,
  2. Learns as it goes, improving its processes during the course of the project, and
  3. Identifies, analyses, documents and shares the new knowledge it has gained, for the sake of future projects. 
For the project itself, the most powerful of the three is “Learning Before”. If a project can maximise it’s knowledge up front, especially if the team can discover the things it doesn’t know that it doesn’t know, then success is much more likely. “Learning Before” activities such as Knowledge gap Analysis, KM planning or Peer Assist can overcome some of the more serious cognitive biases for KM, and are the nearest thing to KM Silver Bullets that we have. Learning before activities drive receptivity, increase absorptive capacity, and help teams “want to learn”.  
And yet, when you look at internal company project frameworks, or even at  generic frameworks such as Prince 2 or ISO, there is almost always a requirement for capturing and sharing lessons after the project, and no such requirement for Learning Before. According to our global survey, 68% of companies require their projects to do some sort of Learning After, but only 15% require them to do Learning Before.  Prince 2 has a required, and well documented, step at the end, for creating lessons (although this could be much improved!), but has no step at the project start-up, requiring a search for, and review of, existing knowledge.  
This astounds me.

Why even bother to collect lessons at the end of a project, if nobody reviews them at the start of the next project!

I think the answer is that it is psychologically easier to share than it is to learn.  A project team can feel proud and recognised (even a little smug at times) for sharing lessons, while asking for lessons can feel like an admission of incompetence (“can anyone help me with this?”). 
Learning After is Teaching – Learning Before is Learning, which is Much Harder. Knowledge reuse is more difficult than knowledge sharing, yet that is all the more reason we should make it a focused and deliberate step. 
You get around some of these barriers by introducing non-judgemental techniques such as Peer Assist and Knowledge Management plans, which take the exposure out of asking for help, or seeking for knowledge. And you also address it by developing a culture of Asking, rather than a culture of Sharing.

Please, let’s introduce the full cycle of Learning Before, During and After, and let’s not skip the Before step!

View Original Source (nickmilton.com) Here.

When Peer Assists add value

Peer Assists are one of the most powerful processes in KM, but they are not for every occasion.

A  Peer Assist – a meeting when a project team seeks input of knowledge and advice from experienced peers – is one of the most effective tools in the KM armoury. It is demand-driven, the knowledge which is shared will almost certainly be reapplied very quickly, the knowledge is brought into the project in its richest form (in the heads of experienced practitioners) and the diversity of viewpoints within a peer assist helps eliminate many of the common cognitive biases.

However a Peer Assist is costly in time and (in the case of multinational companies) in travel costs. It is not something that can be done quickly, as it takes time for the visiting peers and the project team to fully understand each others’ contexts. A Peer Assist for a major project may take days.

The value of the Peer Assist must outweigh the costs, which is why they are not a cure-all for every problem.

Here are some guidelines for whether a Peer Assist is the right solution for a project

  • The project recognises that it needs knowledge
  • The required knowledge is complex knowledge, which has not been codified into standards and best practices.
  • The Project team has tried traditional knowledge seeking methods such as searching, browsing, eLearning, formal training, expert support etc.
  • The scope of work, and the issues which need to be discussed, are clear.
  • The project team have enough knowledge of the subject to understand the core issues, but still need expertise and experience from other people to help them make the correct decision.
  • The project team are still open to new ideas and challenges, and are not yet committed to a course of action
  • The potential saving exceeds the cost of the meeting.
  • Therefore they need a Peer Assist

View Original Source Here.

How to hold an effective Peer Assist

Peer Assist is one of the most effective KM processes, when applied well. But what is the key to a good Peer Assist?

Peer Assist in China

Peer Assist
is one of the most popular, simplest and most effective of the KM processes, the closest we have in KM to a Killer Application.  In our 2014 KM survey, Peer Assist was judged to be the most popular and most effective of the KM processes.

Here are some tips for getting the most out of Peer Assist.

  • Run a team planning process to determine which topics require a peer assist. Try Knowledge Gap Analysis, or KM Planning
  • Research and network to determine if a possible solution to your challenge already exists, before calling for a Peer Assist. A Peer Assist is too valuable to waste on solving questions where the answer is already obvious
  • Plan the Peer Assist once you are clear on the questions to be addressed, but early enough to incorporate the feedback. You must have an open mind for a peer assist to add value.
  • Be very clear about the objectives. Fuzzy objectives is a common form of failure for peer assists.
  • Spend time on getting the questions right – neither too general nor too detailed.
  • Don’t invite only the “usual suspects”! Look for diversity and relevant experience
  • Appoint a facilitator. Although a peer assist is simple, a facilitator can add massive value.
  • Include time for socialising to build relationships and promote knowledge sharing.
  • Set the atmosphere to ensure frank and open exchange.
  • Allow the host team to describe their context and identify their issues.
  • Allow the visitors also to list issues which the host project team may have overlooked.
  • Run a quality dialogue session around each of the issues in term
  • Finish the Peer Assist with feed back from the visitors summarising their advice, and feedback from the host team summarising their actions.

View Original Source Here.

How to avoid "intellectual inbreeding" through knowledge management

Someone came up with a great phrase in a workshop recently – “Intellectual Inbreeding”

What they meant by Intellectual Inbreeding is the sort of restricted group think you get when ideas or practices have been the province of a small group of people, and they have become stuck in a set of shared views and opinions which are impervious to (or oblivious of) external views.

On this blog I have often referred to this as “knowledge bubbles” (see the Brexit example, the Hitler/Stalin example, the social media echo chamber,  and how to burst the knowledge bubbles, perhaps through a lesson escalation route).

Intellectual Inbreeding is what happens when the pool of ideas is too limited, and people can’t think outside the box, to bring in new ideas and topics. Intellectual inbreeding results in a restricted “meme pool”, and can lead to catastrophic error.  I recommend Christopher Burns’ excellent book “Deadly Decisions – how false knowledge sank the titanic, blew up the shuttle and led America into war” for some scary examples

On a smaller scale, we see this intellectual inbreeding very clearly in our famous and powerful Bird Island Knowledge Management exercise, where groups can get stuck on a particular design, and can’t see the wider possibilities. Maybe they have built a design that reaches 60cm, and think that if they really push everything to the limits, they might reach 75cm, little knowing that the best practice design is far far taller.

The way to beat Intellectual Inbreeding is to bring in ideas from elsewhere, from outside the meme pool. You can do this through peer assist, for example, or through knowledge learning visits. In the Bird Island game, we open the doors and bring in people from other teams to share their knowledge and ideas. Often, while the team was racking their brains to take their design up to 75 cm, a member from another team might come in having built a design that already reaches 120 cm.

What happens then, is dramatic. You can almost see the scales falling from people’s eyes, and you can almost hear the sound of the penny dropping, or the bubble bursting.

Intellectual Inbreeding is one of the most dangerous outcome of siloed organisations. Use techniques such as Peer Assist to break the silos, exchange the ideas and experiences, and expand the meme pool. A healthy meme pool leads to a healthy knowledge ecosystem.

View Original Source Here.