Wednesday, 27 August 2014


How long does KM really take to bed in?


One of the things we were interested in learning about through our Global Knowledge Management Survey was how long KM takes to embed within an organisation.


We asked survey participants to describe the level of maturity of KM in the organisations in two ways, firstly an estimate of the number of years that KM had been a focus for them, and secondly a verbal description of maturity, choosing whether KM was "in the early stages", "well under way" or "fully embedded".

You can see the distribution of maturity levels in the graph here - more organisations surveyed are in the early stages than at any other stage.

However it also proved very informative to look at the average number of years spent on KM by the organisations which were at each of these maturity levels. The figures were quite surprising.

  • Organisations which were "in the early stages of introducing KM" had been doing KM, on average, for 3.5 years.
  • Organisations which were "well in progress with KM" had been doing KM, on average, for 8.2 years.
  • Organisations where "KM is embedded in the way we work" had been doing KM, on average, for 11.8 years.
These are quite large numbers of years. If the early stage leasts more than 3.5 years, and embedding takes place somewhere after 8 years and before 12 years, then Knowledge Management is a long term affair.

But does it have to take so long?  There are some indications from the survey that the length of time KM takes depends on how you introduce it, with change-management and pilot-led approaches being the quickest (exactly the implementation approaches we recommend at Knoco). Such approaches to implementation can shave 2 years off the time of your Knowledge Management program.

However the basic message from the survey is that Knowledge Management implementation is a marathon and not a sprint, and the culture change needed to fully embed Knowledge Management can take up to a decade to mature.

Monday, 25 August 2014


Recruiting the experts to your KM initiative


Remember the ancient approach to Knowledge Management, of Master and Apprentice? Throughout the middle ages, and into the early industrial age, the Masters were the knowledge holders, and Apprenticeship was the system of transferring that knowledge to a new generation of practitioners of a skill. The Masters saw themselves not just as doers, but also as Teachers.

Has that ancient model survived to the knowledge age?

Many clients we speak to are having real problems recruiting the knowledge holders to the concept of Knowledge Management. Even in those companies where knowledge holders are few, and knowledge seekers are many, the experienced subject matter experts are often reluctant to become involved with KM.

The reason is, that because knowledge is scarce, they are busy "doing the job", and have no time to teach or to share their knowledge. The fewer experienced practitioners the company has, the busier they are in actually performing the work.

Many experienced staff enjoy their expertise, and they see KM as a distraction or an added burden. They often feel that KM "is not my job".

"I am an experienced boiler-maker/salesman/brewer/application designer" they say; "my skills are in huge demand. Why should I take time out to share my knowledge? That's not my job"

Make KM "the job of the expert"

The answer to this, of course, is to make Knowledge Management (or at least a component of knowledge management) the expert's job.

You can't expect busy people, in demand from all over the organisation, to add to their burdens with work that isn't in their job description. But if their knowledge is vital to company performance, then acting as a steward of the knowledge of the organisation needs to be in their job description. It needs to be recognised as part of their job, and they need to be given the space, the resources, the assistance, and (if necessary) the training to allow them to share their knowledge with the next generation - the apprentice generation.

The old career progression was Apprentice - Journeyman - Master.

Knowledge Companies need to rediscover this progression, so that the Masters (of both sexes) - the Subject Matter Experts - can see their role as Teaching as well as Doing, and as passing on their skills to those who need them, through the tools of KM (wikis, community forums, peer assists etc) as well as through the traditional tools of apprenticeship (coaching, mentoring, training).

The New Role of the expert is two-fold - to be the Practice Owner for their domain of practice, and to play a coaching role in the relevant Community of Practice.

We need to rediscover this Mastership role, so we can fully reinstate the experts in their rightful place.


Two ways of Knowing - Facts and Familiarity


It has been a long running thread within this blog, that the English language is inadequate when it comes to talking about Knowledge. 

Where other languages describe two forms of knowing, we have only one word for both. It is this inadequacy that is at the heart of many disagreements about Knowledge Management. 

We use the same word when asking "Do you know her name" as when asking "Do you know her". However we are describing two types of knowing here - the first is a Fact, the second is a Familiarity.  If you know someone's name, then you can recall a fact about them. If you know someone, then you are familiar with them.

There is a big difference between these two types of knowing, even though we can hold both types in our heads. There are equally big implications for Knowledge Management, as the two types of knowledge will need to be managed in different ways.

The table below shows some of the differences.


Facts

Familiarity

Facts are memorised - they come through instructionFamiliarity is acquired, it comes through experience (your own experience, or shared experience from others)
Facts are "know-about"Familiarity is "know-how" as well as "know-why" and "know who"
Facts can be transmitted easily through written meansFamiliarity is difficult to transmit through written means, although context-rich instructions and stories can help to share experience
Machines and IT systems can store facts faithfullyMachines and IT systems cannot (or at least cannot easily) store familiarity - Familiarity is primarily a human attribute
Facts themselves do not facilitate action.Familiarity facilitates action. If you are familiar with a situation, you know what to do. If you are familiar with a person, you know how to interact with them.
Facts are information as well as knowledge, and can be managed through information management systemsFamiliarity is not information, it is only knowledge, and it cannot be managed through information management systems
Facts have value to an organisationFamiliarity has MASSIVE value to an organisation

In Knoco, we tend to focus our Knowledge Management support on ways to develop Familiarity (without losing sight of the need to provide access to facts), for example;

  • Using knowledge management to allow new staff to become rapidly familiar with organisational processes
  • Developing a shared familiarity of an operation or activity through discussions within a community of practice
  • Using team learning processes such as Peer Assist and After Action Review to help a team "climb the learning curve of familiarity" more quickly
  • Applying a Knowledge Retention Strategy to ensure that an organisation does not lose familiarity with crucial processes, practices and relationships when key people retire
  • Using Lessons Learned to ensure that teams become familiar with pitfalls and workarounds from previous projects.

Keep this difference in mind as you plan your Knowledge Management strategies. Knowledge is not a simple thing, and you will need to pay attention to these two ways of Knowing.

Friday, 22 August 2014


What sort of a thing is Knowledge Management?


One of the Linked-In forums had a debate recently about "Is Knowledge Management a science?" The consensus was that "No, it isn't a science", but what is Knowledge Management exactly?


I have met many people over the years who treat Knowledge Management as something entirely unique - a philosophy, almost, or a "world-view". For these people, there is nothing quite like KM.

Our view in Knoco is that KM is not unique, but is rather the latest in a range of management disciplines.

Knowledge Management represents a way of managing work, paying due attention to the value and effect of an intangible (namely, knowledge). And it's not the only management discipline which deals with intangibles. Risk management, quality management, customer relationship management, brand management, reputation management, talent management, safety management - all deal with intangibles.

This view - of KM as one discipline among many - is derived from recognising knowledge as one organizational asset among many. For centuries, organisations have managed their visible assets, such as money, people, property and equipment. More recently organisations have been addressing the intangible assets, such as their reputation, their IP, their customer base, the diversity and talent of their staff, their ability to work safely and sustainably, and now their knowledge.

The value of treating KM as a management discipline

The first great value of treating KM as "one among equals" - as another component of good asset management discipline - is that you can then place it within the same governance framework as you do the other disciplines. You can position it in the same structures and expectations. You can review it using the same review processes (the stage reviews of the project management framework, for example, or the Plan/Do/Measure/Learn cycle). In other words, you can embed it easily within "normal work".

Maybe that's a pragmatists approach rather than a theorists or idealists approach, but if you are looking to embed KM in your organisation, you will find that this is an approach that works.

The second great value of treating KM as "one among equals" is that it gives you an analogy for the practical issues of implementation and sustaining KM. You can look at the closest analogue discipline that is already embedded in your organisation, and ask "How did we implement this? What lessons can we derive about implementing such a discipline? How are we sustaining this? What lessons are there for KM?"

Probably the closest analogue disciplines for KM are safety management and risk management. Both of these disciplines are not about the management of tangibles - neither safety nor risk are things you can pick up, weigh and put in your pocket - but more about how you manage your organisation so that safety and risk are given priority, and so that people's safety behaviours and risk behaviours change.

So if your organisation has, in the past, successfully introduced risk management and safety management, then you should be greatly heartened as a knowledge manager, as KM can then follow a proven implementation path.


Thursday, 21 August 2014


What's wrong with keeping knowledge in people's heads?


The default approach to managing knowledge which many companies use, is to keep knowledge in people’s heads, and to move the knowledge where it is needed by moving the people, not by transferring the knowledge. 


In this old model, knowledge is owned and held by the experts and the experienced people. Knowledge is imported to projects by assigning experienced people as members of the project team.

Knowledge is transferred from site to site by transferring staff, and by using company experts who fly around the world from project to project, solving problems.

This is a very traditional model, but it has many major failings, and cannot be considered to be effective knowledge management.

Imagine if you managed your finances in this way! Imagine if the only way to fund a project was to transfer a rich person onto the project team, or to fly individual millionaires around the world to inject funds into the projects they liked!

The major drawbacks of this default ‘knowledge in the heads’ approach are as follows:
  • Experienced people can only be on one project at a time, whereas knowledge management can spread that experience to many projects. 
  • Knowledge cannot be transferred until people are available for transfer. 
  • Experts who fly in and fly out often do not gain a good appreciation of how things are done, and where the good practices lie. In particular, teams in projects may hide their failings from the company experts, in order to be seen in a good light. 
  • The burn-out potential for these experts is very high. 
  • Knowledge can become almost ‘fossilised’ in the heads of the experts, who can end up applying the solutions of yesterday to the problems of today 
  • Even experts forget things over time. The human brain is a very poor long-term knowledge store
  • When the expert leaves, retires, has a heart attack, or is recruited by the competition, the knowledge goes with them. 
Unfortunately, for the experts and the experienced people, this can be an attractive model, and was stereotypical behaviour for specialist engineers for many years. It can be very exciting travelling the world, with everyone wanting your assistance.

It is like early Hollywood movie scenes with the US Cavalry riding over the horizon to save the wagon train at the last minute. Knowledge management, however, would make sure that the wagon train did not get into trouble in the first place. As one experienced engineer said recently, ‘If you could fly off to some problem project, save the day and be a hero, or sit behind your desk and capture knowledge, what would you do?’

However if that engineer's knowledge had been more widely available, perhaps the project would not have become a problem in the first place.

Don't keep the knowledge in a few heads, spread it through the organisation instead.

Wednesday, 20 August 2014


Four types of knowledge transfer


There is no one-size-fits-all solution for knowledge transfer, because not every transfer context is the same.  However we can look at four main classes or types of knowledge transfer, by looking at the dimensions of TIME and LOCATION.

OTJ (On The Job) Transfer

The transfer of knowledge between people or teams who are co-located - doing the same sort of work at the same time in the same place - can be done on the job. Knowledge can be transferred through embedding processes like mentoring, coaching, after action reviews, as well as through numerous informal conversations.

Serial transfer

The transfer of knowledge within a series of projects in the same location, one after the other (and often with the same team) is called serial transfer. Much serial transfer can be accomplished by the transfer of project plans, designs, basis of design documents, and so on, as well as by transferring lessons learned, and transferring core team members. Project knowledge handover meetings can also be useful - sometimes known as baton-passing. Knowledge transfer between individuals working in the same place but at different times is accomplished by personal knowledge handover - a planned set of conversations, and compilation of a set of key documents, contacts, lessons and tips and hints.

Parallel transfer

The transfer of knowledge between a series of projects running simultaneously but in different locations, or between many individuals doing the same work in different parts of the business, is called parallel transfer. This can rely heavily on face-to-face activities such as peer assist, and knowledge visits, as well as real-time transfer of knowledge through communities of practice, online forums and enterprise social media. Because operations are simultaneous and continuous, much knowledge can remain tacit.

Far Transfer

The transfer of knowledge between projects running in different times and different places, or from person to person separated by time and distance, is called far transfer (a term coined by Nancy Dixon). Far transfer cannot rely on real-time conversations, or on simply transferring project plans, as the next project may take place in a completely different country in several years time. Knowledge will need to be transferred in written form as a knowledge asset, or as a series of Lessons Learned.

Tuesday, 19 August 2014


Knowledge of process, knowledge of product, knowledge of customer


Some companies make things, some do things, some maintain relationships. Process companies, Product companies, Client companies - different focus, different business, different approach to KM. 

OK, so that is an oversimplification - most companies are a mix of Doing, Making and Relationship Management; they have product departments where they Make things, and marketing departments where they Do things, and sales/service . However there are still three types of KM approaches; focusing on Product, Process and Client.  The figure attached here (from our global KM survey) shows how the balance between these approaches varies by industry sector.

Process-based KM.

A typical process-based organisation would be the Army. They don't make things, they do things, and their KM approach is all about the development and improvement of Practice. They develop their doctrines, they develop Communities of Practice, and they focus on continual practice improvement.

We see the same in the oil sector. The focus is on Practice Improvement. Communities of Practice, Best Practices (or whatever you prefer to call them), Practice Owners - the entire focus is on knowledge of Practice, Practice Improvement, and Doing Things Better.

Aid and Development, and Construction, are also strongly Process/Practice focused.

Product based KM

A typical product-based organisation would be an aircraft manufacturer or a car manufacturer. They exist to make things, and their KM approach is all about the development and improvement of Product. They develop product guidelines.

In DaimlerChrysler, their Electronic Book of Knowledge was about motorcar components, and their tech Clubs were more Communities of Product than Communities of Practice. The experts are more likely to be experts on a product, than experts on a practice area. With the more complex products, were design knowledge is critical, KM can become Knowledge Based Engineering, with design rationale embedded into CAD files and other design products.

The Air Force, in contrast to the Army, is focused primarily on Product learning - learning about the Plane itself, much of which learning is shared with the aircraft manufacturer. For a Product based organisation, the entire focus is on knowledge of Product, Product Improvement, and Making Better Things.

The KM focus in Legal firms is also Knowledge of Product; the product here being

The figure above shows that none of the sectors surveyed is purely focused on Product - there is always a mix of Product and Practice.

Customer based KM

A typical customer-based organisation would be a government department. They exist to  serve a customer base. They are not making anything (other than policy) and the KM focus is on the customer.

Customer focused Knowledge Management consists of developing and documenting a knowledge of the customer (through Customer-focused communities and through research), and may also involve the provision of knowledge to customers, and the involvement of Customers in discussion through communities and social media.

Balancing the types of knowledge 

The danger in KM comes when you try to impose a solution where it does't apply.

KM should be pragmatic, and consist of "horses for courses", rather than a one-size-fits-all approach. This is also true for divisions within large companies.

While the sales division, or the new business division, or the projects division may need Communities of Practice, perhaps the division that makes the products needs Communities of Product, so that Knowledge of Product can be transferred across company boundaries. Perhaps the traditional tools of Learning Before, During and After need to look at Product knowledge as well as Practice knowledge, and look for improvements in Product as well as improvements in Practice.

The idea of Communities of Product is an interesting one, as these Communities may extend beyond the designers and Developers, to include the Sales force and the Service Engineers, who also need product Knowledge, and can supply learning about the Product in Sales, and the Product in Use. Ultimately the Product Community can extend to the Users of the product - the customers themselves.

That's when it really gets interesting!

Blog Archive