Friday, 15 November 2019

How to identify a knowledge "near miss"

In organisational safety management, they identify a "near miss" as evidence that safety practices need to be improved.  We can do the same in knowledge management.


Image from safety.af.mil
I have often used Safety Management as a useful analogue for KM, and here's another good crossover idea.

In safety management they identify safety breaches (accidents, injuries, "lost time incidents") as metrics and indicators that safety management needs to be improved.

They also track "near misses" - incidents where nobody was harmed, but only by luck, or "unplanned events that did not result in injury, illness or damage – but had the potential to do so". A hammer dropped from height and landing a few feet away from a worker on the ground, a bolt blown past someone's head by an escape of compressed gas, a near collision between two aircraft, all are examples of near misses indicating that safety management needs to be improved. 

In KM we can  track lost knowledge incidents, where time, money or effort was wasted because knowledge should have been available but "got lost" along the way. The knowledge is or was once available to the organisation, but failed to reach the person who needed to act upon it, with resulting cost to the organisation in terms of recovery cost, rework, lost sales, delay etc. If you are lucky you can quantify this cost as part of the Cost of Lost Knowledge, aka the Cost of Ignorance, and use this in your KM business case.

But we can also track Knowledge Near Misses. This is where the knowledge was not lost and no cost therefore incurred, but it was only found or transferred by lucky chance.

I heard a great example recently in a client organisation (and I paraphrase below).

The organisation was planning an activity. It seemed a little risky but quite doable, and there was management pressure to go ahead. They were discussing this activity in a meeting, and someone from another part of the business who happened to be in the meeting by chance (he was not invited to discuss this particular activity) spoke up and said "I was part of a team that tried this before. It was a complete disaster, and we are still recovering from the mess it created".

The lessons from this previous project had not been captured, they were not in the lessons database, and the project report was not findable but buried in a mass of project files on a hard drive somewhere. Had that person not by chance been at the meeting, the "complete disaster" would most likely have been repeated with resulting costs in manpower, money and reputation.

This was a knowledge near miss. This event did not result in cost to the organisation through lost knowledge, but had the potential to do so, and was only avoided through luck. With a proper KM framework in place, and followed by all staff in a systematic way, this knowledge would not have been lost, and the planned activity could have been assessed in the full light of historic lessons.

You can find another KM near miss story here

The knowledge near miss is a useful metric which provides evidence of the value of, and need for, effective KM.



Tuesday, 12 November 2019

Charts and Pilots - an illustration of tacit and explicit knowledge

If you are a competent ship's master, what types of knowledge do you need to be able to navigate on a new voyage to an unknown port?  You need two types - explicit and tacit, charts and pilots.


The charts, and the associated tide tables and weather forecasts are the explicit knowledge, whether these are paper charts or electronic. They record the unchanging features of coastlines, currents, buoys and lighthouses. With a good set of charts, any competent mariner can navigate any sea anywhere in the world, provided they have their own set of tacit knowledge - how to read a chart, how to determine position, how to plot a course allowing for wind and tide.

A chart is never complete - there are often uncharted hazards - but they as being constantly improved, and it is now possible to order a set of charts which are updated as of the day of ordering.

But when it comes to entering the narrow congested waters of an unfamiliar foreign port, the ship master's tacit knowledge is not enough, even bolstered by the explicit knowledge in the charts and manuals. Here you need a Pilot.

A pilot is a sailor who maneuvers ships through dangerous or congested waters, such as harbors or river mouths. They are navigational experts possessing knowledge of the particular waterway such as its depth, currents, and hazards.

The economic and environmental risk from today's large cargo ships makes the role of the pilot essential. Pilots possess detailed knowledge of local waterways, and most ports have compulsory pilotage for big ships. Pilotage is one of the oldest professions, as old as sea travel, and it is one of the most important in maritime safety. The complexities and risks of close navigation make pilotage essential.

Pilotage is an example of deep tacit knowledge which cannot safely be codified, and the master and pilot work together, combining their knowledge of the ship and knowledge of the harbour, to finally berth the ship and end the voyage.

Similarly your knowledge workers need access to two types of knowledge.

They need the documented guidance of the "broad areas" of their work, so they can be guided through most of the job. Then they need access (through communities of practice, or subject matter experts) to the deep knowledge of the most risky or complex tasks that can never be made explicit.

Once again, this takes us back to the dual nature of KM - Connect and Collect, Tacit and Explicit. These both need to be components of your Knowledge Management Framework,so that you can take your knowledge workers to the mouth of the harbour, and then guide them to safe anchorage.





Monday, 11 November 2019

Engaging leaders through a KM "proof of concept" demonstration at De Beers

The story here is taken from the book "Performance through Learning", and tells of a crucial "proof of concept" exercise at De Beers, the global diamond company, which was instrumental in demonstrating the value of Knowledge Management to senior management, and gaining their support and buy-in.


De Beers Headquarters, Johannesburg;
Image from wikimedia commons
 One of the earliest stages of the De Beers Knowledge Management strategy was to try some simple KM processes on some of the key activities or projects within the organization; to see if they worked, to see if they generated value, to come up with some early wins, and to create some success stories which could be used for marketing. 
Ian Corbett, the De Beers Knowledge Management lead, had already identified one or two possibilities, and more had come up during the strategy workshop. There was one very interesting and challenging possibility though, which would be a real test of the power of Knowledge Management; the !Gariep project. 
 !Gariep had been a blue-sky technology project for De Beers Marine. The De Beers Marine team had planned to build a piece of mining technology beyond anything that currently existed. The project had been an ambitious challenge, and many many learnings had been generated; so many learnings that the organisation had been unsure how to harvest them for reuse. Some of the key players were still in the organisation, others had left. 
Ian saw the possibility of using the Retrospect process as a powerful and non-confrontational way of harnessing some of that knowledge. 
 The !Gariep retrospect took place over two days in Cape Town, involving 25 members of the project team, with up to four years history with the project. We divided the project into four stages, and spent half a day on each stage. With the benefit of hindsight, we can see that we invited too many managers and not enough "workers" to the retrospect, because many of the most valuable insights came from some of the more junior members of the project team. 
 However some very interesting and powerful lessons were captured, and we took the opportunity to record some video advice from the participants, as well as some feedback on the retrospect process itself. Although the lessons from !Gariep were extremely valuable, and have already been carried forward to future projects to great effect, those video clips were an even more powerful demonstration of the value of Knowledge Management. 
 Shortly after the retrospect had been completed, Ian attended a meeting of the senior management team of the De Beers group to talk to them about KM. He had recorded one of the engineers at the retrospect, a young credible and eloquent contributor with some excellent knowledge and advice to offer, and he embedded the video in his presentations. 
This was the turning point for some of the senior managers; it transformed the whole presentation and got them on the edge of their seats. It was a real-life, highly relevant demonstration of what KM within the De Beers context, and from a complex and high-profile project as well. And then, when the senior managers asked "and how did the participants feel about the Retrospect process?" Ian was able to show them a second video clip of enthusiastic feedback.

Turning the "proof of concept" into high level support


Ian later reported the following;

"The embedded video was the best way to market how powerful this approach is. I recorded one of the engineers talking. He is young, credible and eloquent, and I put his video in a presentation for the senior management team. I gave the talks, and I showed Steve, and it transformed the presentation and got people on the edge of their seat. This was the turning point for the Director of operations, who became the high-level sponsor for Knowledge Management in De Beers”

This approach for engaging key leaders can be replicated by any courageous knowledge manager.

  • Find a big business issues
  • Apply Knowledge Management as a "proof of concept" exercise to solve, address, or learn from that issue
  • Ask the people involved in the KM exercise to tell the story, in their own words, on video
  • Use that video to engage your senior managers

Friday, 8 November 2019

Why a Performance Culture drives KM

KM requires a learning culture, and motivation to learn comes from motivation to improve.  That's why KM thrives in a high-performance culture, where people are not content with existing performance, and actively seek new knowledge that will help them perform even better.

Image from eglin.af.mil
U.S. Air Force photo/Samuel King Jr

This was a topic of conversation in one of out recent Bird Island exercises where, as always, the teams made massive leaps in performance as their knowledge base increased.

The real value of this exercise comes in the debrief, when we analyse the success factors and relate them back to KM at work. One of the topics we analysed was Motivation and Target setting. What motivated the teams to set themselves aggressive performance targets, and what motivated them to use the knowledge from others, to deliver those targets?

The primary motivation factor was "to do a great job". 

They didn't set the target of beating the world record, they set the target of being "up there with the leaders" and delivering a great result. They wanted to be proud of their achievement - that it should stand well in the rankings. Of course, in order to set the target properly, they needed good benchmark data, and data from historical performance. We gave them that data, so they knew what to aim for, and they know what was possible.

And of course, in order to reach the benchmark, they needed the entire knowledge base of how to complete the task, so they could reproduce the successes of previous teams, and ideally could innovate further.

That combination of knowledge of past performance and of how to achieve it allowed them to set targets that were 2 or 3 times greater than the results had achieved so far, and in each case, through reapplication of knowledge, they exceeded those targets and achieved top quartile performance.

So how do teams set performance targets?


In the class, the teams set their own targets, based on knowing the benchmark, and knowing they had the knowledge to reach the benchmark.

Then I asked them how targets are set at work, and how motivating these are. You could hear the groan go round the room. "Targets are set from the centre" "Nobody buys into them" "Targets are a joke" "We set our targets, then define the metrics later so we can beat the target" "Targets are political". Such a contrast from the motivation in the exercise, where the motivation was internal and the targets were self-selected.

Knowledge and Performance are so closely linked, that we often say that if you don't manage performance, you can't manage knowledge.

If people are not motivated to perform and improve, how can they be motivated to learn? And if nobody wants to learn, then KM is a waste of time. Although many of the participants were from companies which already had KM programs, and were introducing the tools and techniques, they were really struggling with motivation issues.

Is it possible to motivate in the same way that we did during the exercise? Yes it is, and you can see that clearly in the Shell Technical Limit process I have blogged about before. Here teams have access to the performance data from the past, have access to all the knowledge they need, and work out for themselves how they are going to innovate beyond the best of what has been achieved to date (it is taken for granted that they can match the best historic performance. After all, that has been proven to be possible- that's "in the bag"). They set their own targets, and of course they are heavily motivated, through performance bonuses, when they beat the targets.

It was a very interesting discussion, contrasting the success in the exercise with the struggles at work, with motivation and target setting coming out as a key factor.

So when you are introducing KM, start first where the performance culture is well defined, and where people are already motivated to perform. 

If instead you choose a part of the business with no performance management, joke targets, and where people play political games with metrics, then you may very well struggle to develop a learning culture.

Thursday, 7 November 2019

How to find a KM analogue you can learn from

In Knoco, we very often have clients contact us and ask something like "do you have any examples of successful Knowledge Management in the Canadian farm machinery manufacturing business? The answer to such a detailed question is almost always No. 


 Although we have 20 years experience in working Knowledge Management, with over 130 different clients, we have not yet covered every variant of every industry in every country.  However the client is looking for similarities - for analogues - and maybe they don't have to narrow their field quite so closely.

The techniques of Knowledge management, and the details of the Knowledge Management framework, are largely independent of the content of the knowledge (just as  the techniques of Risk Management are largely independent of the nature of the risks).

However if you ARE a client in the Canadian farm machinery manufacturing business and you are looking for Knowledge Management analogues, then here are some of the things to consider.

Guidance for KM analogues.


Firstly there will be no perfect analogue - nothing you can copy and paste. Your Knowledge Management framework needs to be integrated with your business, and with the structures and systems you already have working for you. It needs to be tailored to fit, not bought off the peg.

Secondly, consider the nature of your business, and the nature of your important knowledge. Specifically, are you a Process company, a Product company, or a Customer company? Does your critical knowledge concern your processes, your product, or your customer base? The way KM addresses these three - the practices you use, the roles you develop - are different. Process based organisations such as the military and the oil sector approach KM one way, product based organisations such as the legal world and the aircraft manufacturers approach it a different way.

Thirdly, consider your size. Are you a one-office company? If so, you will manage knowledge in a very different way to a multinational. Communities of practice, for example, may be much less relevant to you, and much of your knowledge transfer should be face to face. If you operate a single hotel, or a single airport, then your KM needs will be very different from an owner of a hotel chain, or an operator of multiple airports, who will need to compare practices, and share knowledge, across multiple sites.

Fourthly, look at your demographics. Are you a company full of young but inexperienced people who need to learn together, and learn fast? Are you a company full of  ageing experienced staff, where knowledge retention is a big issue? Are you a start-up, needing to spread the knowledge currently held in the head of the founder?

Finally look at your national culture. Different nationalities have different approaches to elements such as leadership, tolerance of ambiguity, and individualism. Methods of Knowledge Management that work in Thailand may not work in the Netherlands, and vice versa. Cutting and Pasting from different national cultures is a risky business.

Can you have KM analogues at all?


You most certainly can have KM analogues, within the limits described here. All western-based project-focused multinationals manage knowledge in a similar way, for example; and that is a wide field to choose from (it is also the field that has published the most case studies).  Western engineering companies with ageing demographics are beginning to converge on similar strategies for Knowledge Retention. I suspect similar patterns to emerge in Eastern organisations as well, from conferences such as KM Asia and KM Singapore.

Yes, you can have analogues.

Don't look in too narrow a field, but look at your industry type, your company size, your demographics and your national culture, and maybe a Canadian farm machinery manufacturing business can learn from the KM practices of a Swedish pump manufacturer, or a Swiss chemicals company.

And somewhere in our 100 clients, we probably have an analogue for you


Wednesday, 6 November 2019

Why a conversation with experienced colleagues is better than re-using captured knowledge

There are some circumstances where re-using captured knowledge is helpful, but many more where a conversation with an experienced person is a better option.



I have referred a few times in this blog to a very interesting paper by Martine Haas and Morten Hansen, who look at success data from bid teams in an international service organisation to find out when collaboration actually helps performance.

They looked at the context of the teams and the types of bids they were addressing, and at two types of collaboration; how much they accessed and re-used documents from previous bids (which they called "codified knowledge"), and how much they sought advice from experienced colleagues outside the team ("personal knowledge"). They then looked at bid success rates, to give an objective measure of the VALUE of the knowledge to the team.

The results are shown in the graphs here, and summarised in the table below. The terms Haas and Hansen use as "high/low need to learn" refers to whether the bid teams were experienced (low need to learn) or inexperienced (high need to learn). Also "high/low need to differentiate" refers to whether the bid they are working on is standard (low need to differentiate) or non-standard (high need to differentiate).

They found that the value of reusing knowledge or of a conversation with experienced colleagues varied with the circumstances of the team and the bid.


Context
Re-use of codified knowledge
Conversation with experienced staff (personal knowledge)
Experienced team, standard contextHarmfulHarmful
Experienced team, non-standard contextHarmfulHelpful
Inexperienced team, standard contextHelpfulHelpful
Inexperienced team, non-standard contextHarmfulHelpful


What we can see from these results is that re-using codified knowledge is actually harmful to success in 3 out of 4 cases, while a conversation with an expert is helpful in 3 out of 4 cases. 

This is a message to all of us working in KM - that codified knowledge alone will not deliver the full value from KM, and that conversations are also needed if we are to make the most of corporate knowledge.

Conversation and content are the two sides of KM, and Haas and Hansen's results show that conversation is the more useful of the two in many contexts. 







Tuesday, 5 November 2019

The 4 legs on the KM table (reprise)

A popular post from the archives - the 4 legs on the KM table

Image from wikimedia commons
It's very easy to develop an unbalanced perspective on Knowledge Management, especially when we work closely with the topic, but it is something that we should strive to avoid.

I was listening to someone describe their Knowledge management Framework recently. They described their portal, they described the roles that support the portal, they described the processes that support the portal, and they described the governance elements they had developed around the portal.

As I listened, I reflected that they had the elements of KM, but had a one-sided perspective.

Let me explain what I mean.

The 4 legs on the table


There are 4 enablers that support Knowledge Management, like 4 legs that support a table. These are
All of these elements are mutually supportive.

Yes, the roles support the portal, but to an equal extent the portal supports the roles. Yes, the processes support the portal, but to an equal extent the portal supports the processes, as do the roles, as does the governance.

Like the 4 legs on a table, the 4 elements of KM are all equally important. No single element is dominant - they all support KM, and they support Knowledge Management in supporting the business.

If you find one of these enablers is becoming dominant in your thinking for any reason, then your table is at risk of becoming wobbly and unstable. If any of these elements is missing completely, your table will fall.

Balance your perspective.
Focus on all four enablers, to an equal extent, and your Knowledge Management table will stand firm and secure in support of the business.


Blog Archive