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.

How many KM pilots do you run at once?

KM Pilots are a key step in agile KM implementation, but how many pilots do you run?

Knowledge Management pilot projects are a core componment of KM implementation. As we explained last month, a pilot project uses KM to solve a business problem in order to test and demonstrate that KM can do what it is supposed to do, and so that you can learn enough to improve and enhance the framework using experience from the pilot.

But how many pilots do you need, and how many can you run at once?

The answer is – you need enough pilots with enough positive results and enough learning that

  • you have fully tested your Knowledge Management Framework, and
  • you have enough evidence to convince both senior management and the knowledge workers that KM adds enough value to be adopted.

As for how many you can run at once, that depends on the level of coaching, mentoring and support resources you have available. Do as many pilots as you can handle, and no more. The process you need to decide which pilots to undertake is as follows:

  1. Canvas the business to find out a list of business issues which KM can help solve. This blog post gives you some pointers which business issues to look at, and you should be able to come up with a long list. 
  2. Rank the pilots against the 4 criteria of potential measurable impact, management support, doability and abiklity to upscale (see blog post for more guidance).
  3. Starting with the top ranking ones, select as many as you can support given the time and resources.
  4. Also try to select a portfolio of pilots that will test all elements of the KM framework.

In BP, for example, with our central team of 12 full-time KM staff, we ran 4 pilots at once. In Mars, with a smaller team, they ran 2 a year.

Choose your pilots wisely and run as many as you can handle until KM is tested, refined and proven

View Original Source (nickmilton.com) Here.

Google's ahead in machine translation, but have plateaued… still not ONE NATIVE AMERICAN LANGUAGE. Does Polly mean AWS investment in language tech? What a moonshot, and huge PR win of hearts & minds, to have 1st Native American AI translation capability. https://t.co/lzMaQpshpK

Google’s ahead in machine translation, but have plateaued… still not ONE NATIVE AMERICAN LANGUAGE. Does Polly mean AWS investment in language tech? What a moonshot, and huge PR win of hearts & minds, to have 1st Native American AI translation capability. https://aws.amazon.com/blogs/machine-learning/amazon-polly-gives-wordpress-a-voice/

(RSS generated with FetchRss)

Good, cheap, fast – choose all three

There is a well known saying; “Good, Fast, Cheap – pick any two.” It’s wrong.

The idea behind this saying is that there is a certain amount of work to be done to deliver a task, service or product, and that work is bounded by the limits of cost, time and quality.

If you try to improve any two of these factors, the third will be impacted. If you want something fast and cheap, for example, it won’t be any good. If you want it good and fact, it wont come cheap.

It’s like seeing work as an incompressible cube – if you press on two axies, the third will expand.

This is only true if the work really is incompressible. There is in fact a way to make things faster, better and cheaper, and that is the removal of waste.

If there is waste in the body of work, then removal of the waste will alllow all three axes to contract.

This is the principle behind Lean approaches to manufacturing, supply chain and product design, and is also an area that Knowledge Management can help with. Through effective KM, we can reduce waste from activity, and compress the “work cube”.

Good, cheap fast – if you use KM to reduce waste from work, you can pick all three.

View Original Source (nickmilton.com) Here.

Connect and Collect – the left leg and right leg of KM

The Connect and Collect approaches in KM are like the left leg and the right leg- you need to use both. 

image from PublicDomain Pictures

I was working with a client last week who is very interested and enthused about the use of Knowledge Management Processes to drive conversations between staff, as an antidote to previous attempts to collect knowledge. These previous attempts had resulted in a huge lessons database which people viewed as a chore, and a waste of time. 
Much as I applauded their new focus on conversation and Connection, I urged them not to neglect the Collect part of the knowledge cycle, as these two aspects of KM go and in hand.
In fact, they are like the left leg and the right leg. A focus on Connecting can help you make a great stride forward, but you need the other leg to catch up if you want to make real progress. 
I told them this story

We were working with a KM team, who had asked us to come into their organisation and run some Retrospects from major successful bids. They wanted to develop and deploy knowledge of how to bid successfully. 

We held a series of Retrospects, and they worked very well. We had some fantastic dialogue within the bid team, and with the internal client, and identified a series of learning points. We found some really good success factors whch should be repeated in future, and whole set of opportunities for improving the bid process, including some things that were really frustrating the bid teams (mostly related to inappropriate company policies) and we communicated these to other projects. Everyone was very enthused by the process.  

A few months later the client called, and said “That Retrospect process is rubbish”. That took me aback, as I know from experience that it is a very powerful and robust process, so I asked him why he said this. He replied – “those issues that were frustrating the team when we started, are still there. They have come up again in the latest Retrospects. Nothing has been changed”. 

 Well – nothing would be changed, if all they did was hold Retrospects. Retrospects are great for identifying team learning, but there needs to be a follow on process to take action on the issue, and for this particular company, those actions needed to be taken at a high level in the organisation. They had not implemented a process or workflow for documenting the lessons addressing the actions, and had no engagement from senior managers in the learning process. Retrospects, like so many KM tools, need to be part of a system, and no tool in isolation will stand in for the system as a whole.

Connect and Collect  – Conversation and Content – need to work together. Conversation is where content is born, and content is something to talk about together. Retrospects need to work together with the lesson management system, not in isolation.

Connect and Collect are like the left leg and right leg of KM – there is only so far you can travel using one and not the other.

View Original Source (nickmilton.com) Here.

Skip to toolbar