Learn - Remember - Recall. KM is as simple (and as complicated) as this.

The way that individuals remember is a small-scale analogue for Organisational Knowledge Management. 

Image from Wikipedia

1. We acquire knowledge through experience or through learning;
2. We store that knowledge in our short term memory;
3. If we feel is has long term value, we transfer it to our long-term memory, where it can also be combined with other knowledge as part of our experience base;
4. We retrieve the knowledge when we need it, through the act of recall (often by association).

This process works well for individuals, and allows us to build up our knowledge over our lifetimes. 

Note the two types of memory. Short term memory is rich but limited, and fades if we try to remember too many things (more than 7 seems to be the limit), and if we do not make an effort to commit the knowledge to long term memory (through rehearsal and repetition) within a minute or less.

In organisational Knowledge Management, we see the same processes and systems in operation.

The organisational short term memory is the tacit knowledge held by the communities of practice. When practitioners are active and knowledge is current, leaving important knowledge undocumented is a low risk option, as it can easily be retrieved by asking the community. Through community discussion, new knowledge is acquired and spread, rehearsed through use, and updated through combination with other sources of knowledge. Retrieval is done through questioning; either face to face or online.

However unless the knowledge is captured into the organisational long term memory, it can be lost if not rehearsed. Communities of practice forget over time, and non-rehearsed knowledge (knowledge which is not in everyday use) will fade from the collective memory.  Much as the brain's short-term memory is an active system involving rehearsal, so the organisation's tacit knowledge is an active system involving practice.

The long term memory for the organisation is the documented knowledge, as well as the knowledge encoded into practices, procedures and operations. This knowledge needs to be consciously acquired through capture and documentation, using processes such as interviewing, Learning histories or Retrospects. It needs to be validated, and over time it can be synthesised with new knowledge which will often modify or even overwrite the old knowledge. The store for the organisational knowledge is the knowledge bases, owned by the practice owners. This knowledge can even, in some cases, remain while a whole generation of workers come and go.

Retrieval of the documented knowledge is not easy, just as recalling knowledge from our deep memory is sometimes not easy. We tend to recall facts through association, and maybe we need to do the same with our knowledge bases. A heavily-hyperlinked wiki, for example, may help us make connections more easily than a linear filing structure.

Organisations learn like people learn, through short term and long term organisational memory; through Connection and Collection. 

Contact us for further details on how to help this happen.

Whose knowledge is it anyway?

Who owns the knowledge in your head; you, or the company you work for?

Image by Frits Ahlefeldt on Wikimedia Commons

Instinctively most of us assume that we own the knowledge in our heads. It's our head, so it's our knowledge.  A 2012 LinkedIn poll tested this question, providing 3 options -

• I own it and the organisation leases it from me
• My employer owns it
• We co-own it

Most of the respondents felt the knowledge was theirs, and was leased, not owned, by the organisation. And a New Scientist article from 2018, discussed here, took a similar tack, arguing that, in the scientific world at least, the knowledge should belong to the scientist, and that knowledge management is a mechanism or organisational control.

"Scientists are slowly losing control of their discoveries, both in private industry and in academia... (as companies) extract workers’ know-how so that the company can store and own it indefinitely".

But is this view really fair - that knowledge in our heads belongs entirely to us, and KM is an attempt by ruthless business to take control of this knowledge? There are several arguments to the contrary.

Firstly, Knowledge Management teaches us that knowledge is a collective property.  Knowledge is distributed. What is in your head is only opinion, until it is validated through combination with the knowledge of others. No one person can hold all the knowledge of a topic in their head any more, and it is generally shared with many present and past contributors. In an organisational sense, knowledge is owned by the communities of practice.

Secondly the organisation has invested a lot of money in developing your knowledge. Through training, through on-the-job coaching, and through the provision of knowledge management frameworks, the organisation has supported and sponsored you in developing the knowledge in your head. They have a stake in it.

Thirdly you cannot share company confidential knowledge. You will have been working with confidential material for many years. Some of the codified, documented knowledge in your organisation will be confidential. Some will be secret. The same is true of some of the tacit knowledge, some of which you have have in your head. You cannot leave a company and immediately start to share confidential material just because you remember it. You cannot legally give away trade secrets, proprietary methodologies or confidential approaches.

Fourthly you may well have signed away rights to some of the knowledge. When a consultant works with a company, they sign clear agreements which define, as closely as possible what existing knowledge belongs to whom, and what must happen to new knowledge created during the consultancy. Generally the new knowledge remains with the company, not the consultant, and the consultant keeps what he/she brought to the party, and anything that was in the public domain.

There is some knowledge that is truly yours to take away, however.

The first is the knowledge that has become embedded and encoded in your muscle memory and your skills. Imagine you are a sports star and you transfer clubs. You are not allowed to give to the new club the details of your previous club's playbook (this is confidential knowledge) but you can take your skills and ability with you, even though your previous club invested in your skills development.

Secondly you can take away your judgement. Judgement, aka wisdom, represents how you act on the knowledge you receive, and this is so innate to the way you operate, than it cannot be taken away.

Thirdly you take away your experience. This is the aggregate of all the work you have ever done, and represents the heuristics you apply to future work.

So who owns the knowledge?

I would suggest that the best approach for anyone working in an organisation is to treat the knowledge as something shared within the organisation, something that you do not own, but can contribute to and draw from.  Certainly do not hoard your knowledge - your hoard is trivially small compared the the sum total knowledge of the network. Share what you know openly, and openly benefit from the knowledge of others. Then when you move on, leave the details and the confidential material behind and take your skills and experience with you.

Take your playing skills and experience with you - those are yours -  but leave the team playbook behind.

The 4 legs on the KM table - comparison of Google vs ISO

A recurrent theme on this blog is to address "the 4 legs on the Knowledge Management table" - the four enabling elements of the Knowledge Management Framework (and indeed of any management framework) - roles, processes, technology and governance.

Two days ago I published a quick exercise, looking at the relative "Google ranking" of these four elements, as a proxy measure of where the attention typically lies, and comparing this with results 5 years ago.

• A search for "knowledge management process" gave  632000 hits
• A search for "knowledge management technology" gave 416,000 results
• A search for "knowledge management roles" gave 169,000 results
• A search for "knowledge management governance" gave 122,000 results 

These figures show an imbalance between the 4 elements  (although less so than in 2015) with far more attention paid to KM processes and KM technology than to KM roles or governance.  My colleague Ian Fry in Australia then suggested we look at ISO 30401:2018 for a good coverage of governance.  So I went through the various clauses of ISO 30401:2018 to determine which referred to each of the 4 elements. The results are shown in the chart below, and are very interesting.

The plot above shows the results. In ISO 30401 there are

• 4 clauses addressing Roles (4.4.4, 5.3, 7.1, 7.2)
• 2 clauses addressing Process (4.4.4 and the single clause in section 8)
• 1 clause mentioning technology (4.4.4)
• 15 clauses on governance (4.4.4, 5.1, 5.2, and all of sections 6, 7, 9 and 10)

So the view of KM on Google (its all about KM process and technology) and the view of KM on ISO (its all about governance) are diametrically opposed.

Now to an extent that is to be expected, as ISO is a governance document, but it certainly shows that, for organisations wanting to comply with the ISO standard, governance is something that no longer can be neglected. There is no point, for example, in having a toolkit full of processes and technologies if there is no planning, no leadership, no policy, no objectives, no measurement of results, no regular audit, no controlled documentation and no means of continuous improvement of the KM Framework.

Hopefully an increased use of the ISO KM standard will lead to a further balancing of the 4 critical elements that form the 4 legs of the KM table.

Product Life-cycle Knowledge Management

Product life-cycle management (PLM) is a well-established discipline. To support this, we are going to need Product life-cycle knowledge management. 

Image from wikimedia commons

In industry, product lifecycle management is the process of managing the entire lifecycle of a product from inception, through engineering design and manufacture, to service and disposal of manufactured products.  Industry has already made big strides with using shared data systems to support the lifecycle of a product. Similar strides can be made in using Knowledge Management approaches.

PLKM differs from standard practice-based KM.

• Instead of Communities of Practice, we need to look at Communities of Product (or Product line, or product family). The Community members will cover the lifecycle of the product; from development through manufacturing through sales to service and maintenance,and back to redevelopment. 
• Instead of Best Practice, we look at Best Design
• Knowledge is passed along the value chain; downstream from development to manufacturing, from sales to service, and back upstream from service to development.
• The key knowledge is mostly "Why" knowledge - why the product was designed the way it was, why design changes were made, why the marketing has taken the chosen approach, why failures happen in service, and so on. 
• The taxonomy will not be a practice-based taxonomy, but will align with the product tree
• Some of the KM processes will be different as well. Specifically the A3 report will replace the After Action Review.

For those of us who are working in a product-based organisation and who are looking to introduce KM into a PLM structure, we need to be thinking in terms of Product Lifecycle Knowledge Management. 

Are the legs on the KM table getting less wobbly?

A recurrent theme on this blog is to address "the 4 legs on the Knowledge Management table" - the four enabling elements of the Knowledge Management Framework (and indeed of any management framework) - roles, processes, technology and governance.

In a 2015 blog post entitled "the wobbliest legs on the KM table" I looked at the relative "Google ranking" of these four elements, as a proxy measure of where the attention typically lies. The results showed that there was far more published on technology and Process than on Governance and Roles.  Today I decided to repeat the exercise.

• A search for "knowledge management process" gave  632000 hits (up from 330,000 in 2015)
• A search for "knowledge management technology" gave 416,000 results (up from 264,000 in 2015)
• A search for "knowledge management roles" gave 169,000 results (up from 68,000 in 2015)
• A search for "knowledge management governance" gave 122,000 results (up from 34,700 in 2015)

We can see two things from these figures - firstly the number of hits has increased (as you might expect, given that google hits are cumulative), and secondly that the imbalance between the 4 elements seen in 2015 is beginning to lessen, as shown in the plot below.

This plot shows the relative attention given to these elements, in the quick surveys in 2015 and 2020, measured by Google hits. So for example in 2015 "knowledge management roles" received just under 10% of the total hits, and in 2020 this is up to 12%. The proportion of hits on "knowledge management governance" is still low, but double what it was in 2015. The proportion of hits on "knowledge management technology" has decreased.

Now in reality attention is needed to all 4 of these elements.

• If there are no roles and accountabilities, then Knowledge Management is nobody's job (or else, it's "everyone's job" which soon becomes "no-one's job") 
• If there are no processes for KM, then nobody knows what to do, or how to do it. 
• If there is no Technology for KM, then nobody has the tools, and KM can never extend beyond the immediate and local 
• If there is no Governance, then nobody sees the point. KM remains an optional activity, and nobody has time for optional activity.

If these are the 4 legs of the table, it is still a wobbly table, with 2 strong legs getting all the attention, and 2 weaker legs. However its not quite as bad as it was 5 years ago.

The message remains this  - if your KM programs are going to be in balance, you need to address all 4 legs of the table. Your processes and technologies may well be fine - you need to bring your roles and governance up to the same level. The evidence is that this is beginning to happen. 

How to sell KM - what we can learn from the Wolf of Wall Street

The knowledge manager, seeking to lead the change to a Knowledge Management culture in their own organisation, needs to know how to sell their product. 

Image from wikimedia commons

As a Knowledge Manager, you are asking people to pay attention to something (knowledge) which previously has been ignored. You are asking them to reprioritise, and you are "selling" the need to do something different. Like it or not, you are in the sales business, selling KM.

How then can we sell? What are the selling skills that a Knowledge manager needs?

We can pick up one or two tips from the classic film "the Wolf of Wall Street," which is all about selling. It tells the story of an unscrupulous stockbroker who makes a fortune in New York through a combination of outrageous selling techniques and fraud. One of the themes of the film is "sell me this pen".

In one scene the stockbroker is testing the selling skills of his team. "Sell me this pen" he says, handing them an ordinary ball-point.

One by one they make the same mistake. "This is a great pen" they say; "easy to use, convenient, cheap ....".   "I don't want it" he replies.

Eventually one of his friends gives the right answer. "Write your name down for me" he says. And of course, the stockbroker needs a pen to do this, and he has just given his pen away!  He needs to do something (write his name) but can't. The pen seller can satisfy the need, remove the "pain point".

What the friend had done, was to create the need for a pen. If someone does not believe they need a pen, they are not in the market to buy one, no matter how much you talk it up. The same is true for Knowledge Management - if the person talking to you does not think they need Knowledge Management, they won't buy it, no matter how much you talk it up.

Taking it further

The "sell me this pen" question used to come up in interviews for sales staff in the 80s and 90s, and there are some sophisticated ways to answer this question. The text below comes from this LinkedIn article and is is a suggested "best way" to answer the question. This involves finding out how the customer uses the product, establishing the importance of the product, selling something wider than the product (such as status, or reassurance), and then asking for the buy. Remember - you cant sell something until you understand the buyer and their needs.

CEO: Do me a favor, sell me this pen.
Salesperson: Let me ask you, when was the last time you used a pen?
CEO: This morning.
Salesperson:  Do you remember what kind of pen that was?
CEO: No.
Salesperson:  Do you remember why you were using it to write?
CEO: Signing a few new customer contracts.
Salesperson: Well I’d say that’s the best use for a pen (we have a subtle laugh). Wouldn’t you say signing those new customer contracts is an important event for the business? (nods head) Then shouldn’t it be treated like one? 

What I mean by that is, here you are signing new customer contracts, an important and memorable event. All while using a very unmemorable pen. We grew up, our entire lives, using cheap disposable pens because they get the job done for grocery lists and directions. But we never gave it much thought to learn what’s best for more important events.  

This is the pen for more important events. This is the tool you use to get deals done. Think of it as a symbol for taking your company to the next level. Because when you begin using the right tool, you are in a more productive state of mind, and you begin to sign more new customer contracts.  

Actually. You know what? Just this week I shipped ten new boxes of these pens to Elon Musk's office. Unfortunately, this is my last pen today (reach across to hand pen back to CEO). So, I suggest you get this one.  

Try it out. If you’re not happy with it, I will personally come back next week to pick it up. And it won’t cost you a dime. What do you say? 

The Knowledge Management equivalent

So let's try the same conversation in KM terms, again finding out how the customers organisation uses the product (or uses Knowledge, in this case), establishing the importance of the knowledge, selling something wider than KM (such as success or reassurance), and then asking for the buy.

CEO: Sell knowledge management to me
KMer: When do your people use knowledge?
CEO: Every day, when making decisions.
KMer:  Tell me about some of the important decisions, where knowledge is critical
CEO: Umm, maybe the bidding process. The bid teams need knowledge of how to craft a bid, how to price it, and how to set the margin so that we win the work and also bring in a good income stream.
KMer:  I can see that bidding knowledge would be absolutely vital. If we had a situation where every bid team had complete access to the knowledge they needed, how much more business do you think we could win?
CEO: I don't know, but the next two bids are billion-dollar bids which are crucial to the company future.
KMer:  And how certain are you that your bidding group are currently handling this vital billion-dollar knowledge - knowledge of how to craft the bid, how to price it, and how to set the margin-  in a rigorous, systematic managed way? How do you know they are learning from every bid this company has made, rather than the ones they personally have been involved in?
CEO: To be honest, I could not tell you. I assume they are, but I don't know.
KMer: Well, there you go. That bidding knowledge is potentially a billion dollar asset for the organisation. If the bid teams have the knowledge, we win those bids. If they don't, we lose. And if something is as valuable as that, then as CEO it's not right that you should have to just assume. You deserve to be fully assured that this asset - this knowledge - is being properly managed, because the future of the company may depend on it.  

There are things we can do to manage that knowledge better, and to make it available to key staff such as the bid teams, who make the decisions on which the future of the company depends. This is what we call Knowledge Management, and this approach is used by many of the Fortune 500s who need the reassurance that their critical knowledge is well managed. 

I am not asking you to buy Knowledge Management right now, I am asking you to try it out; perhaps in the bidding area, or perhaps another part of the business where knowledge is critical to success. We will see what value it delivers, and if you’re not happy with it, then we progress no further. If it works, and helps deliver value, then we take it further. What do you say?

If you are a knowledge manager responsible for KM implementation, then learn how to sell. See if you can become the Wolf of KM Street!  Don't start by extolling the virtues of KM, or the ROI you might expect; start by asking questions and understanding the buyer. Find how your customer uses knowledge, how valuable that knowledge is and where their knowledge hotspots  or pain points are, and then sell into that need.  Find that "something wider" that you can sell - reassurance, or pride, or the opportunity to beat the competition.

Learn to sell KM, as if you were learning to sell a pen

Contact us if you need any help in building your argument.

Why a no-blame culture needs no-blame processes

We hear a lot about the importance of a "no-blame culture" in Lesson-learning, but a no-blame culture won't work unless you have no-blame processes as well. 

Image from wikimedia commons

Learning lessons in an organisation requires a culture of openness, so that people are willing to explore honestly and openly what happened, and what might be learned.  This is particularly important when learning from projects or incidents where things have gone wrong and where mistakes have been made.  If people feel they are likely to blamed for the mistakes, and that their career or reputation might suffer as a result, they are unlikely to discuss the issue openly.

When we discuss the topic of lesson-learning with clients, we often hear the concern that lesson-learning meetings could be seen as "witch-hunts" - in other words, a search for someone to blame. To reassure them, we talk them through the lesson-learning process we use; the Retrospect.

The Retrospect is an externally-facilitated team meeting, held after the end of a project or project stage, where the team identifies and analyses learning points through discussion and dialogue, in order to derive lessons and actions for the future. The facilitator leads an inclusive discussion to identify

• What went well and what did not go to plan in the project
• Why the successful elements succeeded, and why the failures and mistakes happened (looking for root cause)
• How future projects can repeat the success and avoid the failure. 

The key questions are therefore What, Why and How; very open questions which allow full exploration of the lessons learned.

Note that there is no Who question. 

We do not really care who was the hero or who was the villain. This is a no-blame process, as well as a no-praise process. We are searching neither for Witches or for Knights; only for the truth.

An open, no-blame culture requires open no-blame processes such as the Retrospect.