Monday, 29 November 2021

The top 7 tips for successful knowledge management programs

This is a blog post I repeat every 5 years or so, my summary of Top 7 success factors for implementing Knowledge Management. 

There are more than 7, of course (see the knowledge manager's handbook for details), but these are some of the most fundamental recommendations. Many if not all of these are now included within the ISO KM standard, and this blog post has been updated this year to reflect this.

"Tip of the Day" from Wikipedia

1. KM needs to be driven by operational needs.  

It is vital that KM efforts are clearly linked to operational outcomes, with a clear business objective. I have a quote from a survey from the early 00s, that reads as follows

“Most successful knowledge management applications addressed a ‘life or death’ business situation. Successful cases answered two questions at the outset - What business objective am I trying to achieve? How can I apply existing knowledge?”

Here's another quote

"We have been looking at the key processes of the business, testing them for their "knowledge intensity" to see if we would create some significant new change in the performance of that particular process if we managed knowledge in a more profound way. The concept has not been difficult to sell to the top executive team." 

See how this approach starts with the key business processes?

Tom Davenport and co-authors, in the paper "Building successful Knowledge Management projects", conclude that "Link to economic performance or industry value" is the number one success factor for successful KM. Mars, for example, implemented KM at a rate of two business issues per year

ISO 30401 (the ISO MSS standard for KM), in its first requirement clause, links KM to defined operational outcomes, so this first success factor is fundamentally woven into the ISO KM standard. 

2. KM needs to be introduced as a management framework. 

A Knowledge Management Framework is a a small defined set of technologies and processes, embedded into business activity, and a small defined set of roles embedded into the organisational structure, all under an umbrella of Governance.  Like other management systems, effective KM is a framework of roles, processes, technologies and governance which has been embedded into the business. Just as Financial Management is not a single tool - budgets for example, or invoicing - and is not a toolbox ("you can try writing budgets if you like - here's a guide"), but is a complete framework embedded into the business process, so Knowledge Management needs a framework. If there are holes in the framework, it will not deliver value.

A common mistake is to introduce one element of the Framework - a technology for example - and expect knowledge to start to flow. It won't. It might trickle, but it won't flow. 

Again, ISO 30401 requires KM to be implemented as a framework, including roles and accountabilities, processes, technology, governance, and culture (clause 4.4.4), covering the 4 main transitions or flow elements of knowledge (clause 4.4.3) and the lifecycle of knowledge (clause 4.4.2). Indeed, the whole concept of a "management system" as embodied in the KM standard equates to a management framework. 

3. KM needs to address Pull as well as Push and demand as well as supply.

I have blogged about this many times - Push creates supply, Pull creates demand and the two need to be in balance. Too many organisations focus on knowledge sharing, not on knowledge seeking and re-use. Pull, in the early stages, is more powerful than push. Creating demand for knowledge creates a market for knowledge.

We didn't manage to get this principle into the ISO standard, though the standard is careful to refer to the need for a culture of seeking as well as sharing. With hindsight, I wish this element had been much stronger in the standard.

4. KM is a culture change process. 

It is not a gradual change either - it is a step-change. It is a remodelling of the organisation; a make-over, a new way of thinking. It needs to be treated as a change process and measured as a change process. Don't go into KM thinking that it is about a new IT tool, or just "trying out communities" - you won't get far if you don't start to address the hearts and minds. This also means that KM implementation must be structured like a change program (including a piloting component), and must have a strong team of change agents to implement the change.

Again, ISO 30401 supports this principle, and clause 4.5 requires organisations to demonstrate that they are addressing the cultural issues within the organisation.

5. KM must be embedded in the business

If its not embedded, you risk "tipping back" to a pre-KM state. Many of the high profile failures of KM are due to a failure to embed. You can't rely on KM being driven by the efforts of a central team. A central team are needed, but their role is an assurance and support role. The drive must come from the business. 

ISO 30401 requires a chain of accountability for KM to be established within the organisation (clause 5.3) and KM objectives and plans to be developed at appropriate levels and functions (clause 6.2). These plans and accountabilities are the means by which KM is embedded.

6. KM needs not just high level support, but high level expectation

People do what they believe is expected of them. People are generally good workers, they want to do a good job, and if something is expected of them as part of the job, they generally do it. Expectation can be explicit or implicit - written or unwritten. Expectation comes from leadership, and from peers, and these two sources of expectation need to be aligned to be effective . For example there is no point in the boss saying "I expect you to have a work life balance" if all your peers are working to 10pm and expect you to be part of the team, or if your boss is emailing you on a Sunday afternoon and expecting a quick reply. 

Senior management in the organisation needs to make KM expectations clear by explicitly stating what needs to be done in Knowledge Management, and by whom. They need to write these expectations down, and keep reinforcing them by what they say and do. They also need to make sure these expectations do not get weakened by, or conflict with, other company structures and expectations.

ISO ensures this is done by requiring leadership to approve and endorse a KM policy (clause 5.1). It is this policy that sets the clear expectation that KM is a vital component of the organisational  management systems set. 

7. KM should be introduced first where the highest value decisions are made. 

This might be at operator level (the operator of a plant, the driller of an oil-well, the pilot of a passenger aircraft) or it might be at senior management level. Knowledge supports decisions, and decisions are made at all levels. In fact the most valuable and risky decisions are made at senior level. The default approach to supporting these senior management decisions is to hire a big-5 consultant firm to supply the knowledge, but there is no reason why KM can't help as well.  Delivering a high level KM pilot at senior level has three benefits.
  • It delivers massive value to the business
  • It engages senior managers in KM, and helps them understand the value KM can bring
  • It gets senior managers on-side, by solving their problems for them (see the thorn in the lions paw).
Although ISO 30401 states that the role of knowledge, and therefore KM, is to support and improve decision making, the standard makes no recommendations about which decisions to prioritise. That is because the standard is a standard for the final KM system, not for the way in which the system is introduced to the organisation. Therefore let's repeat this one again, as you wont get it just by applying the ISO standard - "Introduce KM first where the highest value decisions are made"

These 7 success factors should help you introduce and sustain successful KM. It's no surprise that most of them are embodied in the ISO KM standard.

Friday, 26 November 2021

Value-focused Knowledge Management (video)

 The video below is from a talk I gave to the Gesellschaft für Wissensmanagement (GfWM) knowledge camp last week, on the topic of "value focused KM". You can find more videos from the same event here.

The video lasts about 30 minutes, and covers the source of value that KM taps into, and how that value is measured.

Monday, 22 November 2021

Why knowledge is social, not personal, and the implication of this view for KM.

There is a school of thought that knowledge lies only in the minds of individuals. I think this is misleading, and that reality is both more complex than this, and more interesting.

A search of the internet will find  a commonly held view in KM circles that Knowledge only exists in the brains of individuals.  

"Knowledge is in the mind" people might say, "and all else is information".  Thomas Wilson argues this point in his provocative paper "the nonsense of Knowledge Management", which was written as a polemic against the way Information Management was rebadged Knowledge Management by software vendors and consultants (a process described by Wilson as "search and replace marketing").

This viewpoint suggests that any way that an individual can find to express knowledge (spoken words, written words, recorded demonstrations) just turns it into information, and that any management applied to this process can only be information management.

Certainly the view of knowledge as a human attribute is very useful as a way of distinguishing knowledge management from information management. However I feel that this view focuses too much on the individual, and that in reality knowledge is not an individual attribute, but something shared and social.  (Please note that in this blog, I use the word "social" to mean related to interactions and relationships between people, rather than as a type of media).

The social nature of knowledge

To introduce this topic, I can do no better than to repeat the words of the great Larry Prusak, spoken at RostatomKM 2016

A key point that we (and by we, I mean the collectivity of practitioners and researchers) have learned is that Knowledge is profoundly social. It is not a factor of the individual but a factor of groups of people. Individuals may have separate memories, but do not have separate Knowledge. 

Larry's point is that Knowledge is a collective thing. The "tacit knowledge" we hold in our heads is either invented by ourselves or comes from the collective, and what we invent for ourselves is at best provisional knowledge, and at worst delusion. It can include

  • opinions
  • hypotheses
  • prejudices
  • cognitive biases
  • fantasies
  • falsehoods.

What turns these opinions etc. into knowledge is social confirmation and acceptance.

You think you might know something, but it could so easily be confirmation bias, and you don't know this until you start to test it with others. 

We see this clearly in the development of scientific knowledge. As part of the scientific method individual scientists develop and test hypotheses, but before these hypotheses are accepted as knowledge, they go through a process of peer review and socialisation. As the UK Parliament site explains

Peer Review is the means by which scientific experts in the field review the output from this process for validity, significance, originality and scientific clarity. Peer review is not, as some outside of science might think, designed to be a fraud detection system. Therefore in our view Peer Review and the subsequent publishing of research is only part, albeit an important one, of how new discoveries become accepted into our collective scientific knowledge.

That last sentence is important - "collective scientific knowledge". There is no such thing as "individual scientific knowledge", and you could argue, as Larry Prusak does, that there is no "individual knowledge" either.

Plato defined knowledge as "justified true belief", which means there needs to be a justification mechanism which can judge "truth". Self-justification by the knower makes no distinction between truth and opinion, and between knowledge and bias. It is the social group that justifies knowledge.

Note however that just because a social group confirms something, does not yet make it knowledge. There are many people in the USA for example who "know" that the world is run by a cabal of devil-worshiping paedophiles, or who "know" that Covid vaccination programs are a tool for government control. Most of us recognise this knowledge as false delusion, but these people "know" they are correct because their views are confirmed by others on the internet. Therefore social justification is not enough to make something knowledge - that justification needs to be continually tested (something that is very difficult to do when confirmation bias is involved). 

The implications for Knowledge Management

This alternative viewpoint - that knowledge is social and is held by groups of people rather than by individuals - still distinguishes knowledge from information, but takes us away from the individual human as the unit of analysis for Knowledge management. Here is Larry Prusak again;
There is much greater emphasis on Networks, Communities and Practices, and I state today that this is the correct unit of analysis if you want to work with knowledge in organisations: Networks, Communities and Practices.

This has five main implications:

  • You need to define your Knowledge Management Framework so that the primary "knowledge unit" is the practice area, and the networks and communities of practice are the mechanisms by which knowledge is shared and managed. This is the approach we take at Knoco when building Knowledge Management Frameworks, and we know that it works.
  • Much of the knowledge work you do will not be concerned with individuals or with documents, but with the interactions between people working in social groups. It is within these interactions (Peer Assists, Retrospects, Knowledge Exchange) that knowledge is built, tested and justified.
  • Documented knowledge should be owned and managed by the communities and networks. They should manage the wiki sites where knowledge is compiled and kept up to date (I mention wiki sites because wikis are, by design, created by ad managed by communities and networks.
  • The collective knowledge should always be open to challenge and testing, in case the community has fallen into a trap of confirmation bias.
  • You will find that the main culture change is getting people to see knowledge as something collective, to be built and maintained socially, rather than their own personal property to be protected and hoarded. 

Try this alternative social-centric viewpoint - I think you will find it very powerful.

Wednesday, 17 November 2021

What's the status of Knowledge Management today? Hear from two of the pioneers

The video below is a conversation between Nancy Dixon and Tom Stewart, two of the early pioneers of the KM discipline. This is great stuff with important insights - please set aside 30 minutes to listen to it!

The conversation is part of Columbia University’s "IKNS Conversations That Matter" series (see the video in context here). In this conversation these two KM pioneers discuss KM's beginnings thirty years ago, how it has improved organizational outcomes, and what challenges remain within the practice.

In case they need any introduction to people new to the KM field:

Monday, 15 November 2021

There is no "silver bullet" for knowledge management. Here's why

There is no silver bullet for Knowledge Management, because KM is a management system with many component parts, all of which need to be in place. 

We often hear vendors promising us a KM silver bullet - usually some sort of technology. "Buy our search engine/Collaboration software/enterprise social app/remote working platform and your KM problems will be solved".

But it doesn't work like that I am afraid.

Knowledge Management requires more than technology, it needs a management system. And as ISO 30401 reminds us, this system has many elements. For example it should cover the four enablers of
ISO 30401 adds the 5th enabler of KM culture - which ensures that when the management system is in place, it is applied, supported and sustained.

All of these elements are mutually supportive. There is no point in introducing one of them (collaboration tools, for example) without addressing the others as well.

Also many of the promised solver bullets cover only one aspect of Knowledge Management, such as searching, or allowing conversation. However there is no point in searching for knowledge, without addressing the possibility that the knowledge is still tacit and can only be accessed through conversation. Also there is no point in conversation if the knowledge needed lies beyond the memories of individuals, and is documented somewhere, waiting to be found.

ISO 30401 also tells us that the roles, processes, technologies and governance need to address:

Knowledge Management is therefore a management system, with a framework of components which need to be interlinked in order to deliver a functioning knowledge workstream within the organisation. 

  • Search technology is therefore not a silver bullet, as without processes, roles, governance and culture there will be no documented, synthesised and maintained body of knowledge to search, and no behaviours of seeking or of applying any knowledge which is found.
  • After Action Reviews are not a silver bullet. Although they can be very useful in helping teams improve their internal process, any knowledge generated is unlikely (without the existence of a management system) to find its way to other teams which need it, nor to update the body of knowledge. 
  • Communities of practice are not a silver bullet (though they come close) as they address only the functional axis of organisational matrices, and not the project axis.
  • Even Peer Assist (though it also comes close) is not a silver bullet, as it covers only the element of tacit knowledge seeking; one of the generic 4 dimensions for KM.

In most organisations therefore, introducing Knowledge Management is not a case of introducing one component - one silver bullet.  It is a case of introducing a system - a new way of working, and a new way of thinking.

Think System, not Bullet. 

Tuesday, 9 November 2021

Why you can't solve knowledge problems with information tools alone

Knowledge and information are part of a continuum but not the same, and knowledge problems cannot be solved with information tools alone.

Image from wikimedia commons
Often a client comes to us and says something like "We have a Knowledge Management problem. Our project teams can't find the knowledge they need to deliver their projects. We want you to work with us to develop a better system to store and access project information".

They have a Knowledge problem, which is a lack of access to project knowledge.  They think this problem can be solved with Information tools, such as taxonomies, metadata, portals and search. They think better access to project documents is the answer. However you cannot solve knowledge problems with information tools alone (I say "alone", as these tools will be part of the final framework) for the following reasons.

Firstly much of the knowledge of the organisation is never codified as information. People know more that they can tell, and tell more than they can write. Maybe as much as 80% of the knowledge in an organisation is undocumented, and can only be accessed through networks, communities of practice, and conversational processes such as Peer Assist and Knowledge Exchange. Information tools leave this knowledge untouched.

Secondly, a common problem (a corollary of the first) is that project knowledge may never have been recorded in project documents. The project may never have created knowledge products, because these were never in the workplan, nobody was assigned to create them, and therefore knowledge never got recorded. Maybe the project might have collected a few one-liner lessons, but frequently these are poor quality as there is no quality control on lesson content. You need to introduce processes of team reflection and lesson-learning, together with the relevant accountabilities and quality control, for this knowledge even to be recorded in the first place. So even if you provide better access to project documents 
  • you might find what the project did, but not what they learned, or would have done differently in hindsight;
  • you might find what the project spent, but not where the value came from, or the reasons for any overspend;
  • you might find the slide-decks and the reports, but not an analysis of the reasons for success and failures.

Thirdly, and a corollary to the first two, the vast majority of project information is not knowledge anyway. If you are relying on project documents as a source of knowledge, you will be relying on a very diluted source - a lot of noise and not much signal. Many of the documents are purely transactional (reports, memos, invoices, charts), and looking for knowledge content would be like looking for a needle in a haystack, no matter how good your search. If you want to create and pass on needles, then a haystack is not the place to keep them

Fourthly, if there is codified knowledge in the project documents, it tends to be scattered across many documents and many projects. Project A may have learned a little bit about a specific process, product or client, and so may Projects B, C, E and Z.  But those little bits will not have been pulled together and synthesised into a body of knowledge without specific accountabilities and processes to do so. Managing little bits is not like managing the whole.

Finally, many of the knowledge problems are cultural. People are incentivised to rush on to the next job rather than to spend time reflecting on lessons, no matter how important. They may not want to share knowledge, as they feel this knowledge is better kept to themselves in order to build their in-house status and value. People suffer from "not invented here" syndrome which leads them to prefer to reinvent than to reuse. There is no point in organising your project information if people do not want to seek for knowledge, and would not use it if they found it. I often use the analogy of teaching your child to read. The first thing you do is instil a love of books, so the child is eager for stories. Afterwards you can organise the book collection, but that comes later. Firstly we need the hunger for stories. Similarly we need to instil a hunger for knowledge as one of the first steps in KM, before organisation can be helpful.

Once we know that project knowledge is being collected, that projects are creating knowledge products and that these are of high quality, that these products are being synthesised into a body of knowledge, and we know that there is a demand for this knowledge and that people are actively seeking it, then the information tools really will provide an excellent support, as tools within the knowledge workstream I described last week

Better management of information can help with, but cannot on their own solve, knowledge problems. If you have a knowledge problem, you need knowledge management as well as information management.

Monday, 1 November 2021

What is the organisation that delivers your knowledge workstream?

I have blogged before about the two simultaneous and overlapping workstreams in an organisation - the product workstream, and the knowledge workstream. But what exactly is the in-house organisation that delivers your knowledge workstream?

Any organisation that makes product, also makes knowledge about that product. Products are made through projects, projects have beginnings and ends, but the knowledge needs to be collected from each project and passed from one to the other. It is this knowledge, passed from one project to another, that allows old products to be improved and new products to be developed. 

There is a project workstream, within is intermeshed and interoperative with a knowledge workstream.

"Product development is not about developing cars, its about developing knowledge about cars. Great cars will emerge from the interaction". 

As we know, Toyota has a whole organisation dedicated to delivering products. In their case, they have car factories; other organisations have factories making cellphones, or shavers, or chocolate, or (to stretch the definition of "factory") making legal products, or training courses, or advice to clients.

All of these production organisations are well developed, and are focused on delivering product.

But what and where is the organisation focused on delivering knowledge?

If there is a well-defined "factory" producing product, and accountable for the product workstream, then there where is the well-defined "factory" producing knowledge, and accountable for the knowledge workstream?

Toyota have such a knowledge factory, and so do many of the world's leading Knowledge Management organisations. These "knowledge factories" generally consist of a framework something like this:

  • Knowledge owners, accountable for specific areas of knowledge
  • Clear accountabilities for knowledge within the operating units and projects
  • A "Body of Knowledge" - accessible to all who need it; maintained, synthesised, collated and updated
  • Communities of practice, acting as contributors to, and co-creators and users of, the body of knowledge
  • Learning from Experience systems, where new knowledge can be harvested from projects and used to update the body of knowledge
  • Collaborative technologies which allow the body of knowledge to be maintained by the community
  • Discussion technologies for the community
  • Effective enterprise search
  • Clear governance.
The point is, though, that if you have two workstreams, you need two intermeshed organisations. You need a matrix of intersecting organisations - with one axis of the matrix being the project dimension, and the other being the knowledge dimension. 

If you try to create a knowledge workstream using the same organisation that creates products, you will run into difficulty. You need a knowledge organisation as well. 

Blog Archive