If we want to succeed in Knowledge management, we need to learn from both successes and from failures. 

Murray Jennex’s 2005 book Case Studies in Knowledge Management contains an instructive failure study by Chan and Chau, from a Hong Kong-based enterprise with a production plant in mainland China.

The company decided to devise and launch a KM program with an aim to improve knowledge creation and sharing among employees to deliver quality products. They adopted a middle-up-down approach, using supervisors as the  KM Champions to promote KM throughout the organization, and started a pilot based around a new product series,

15 months later, nothing had changed. The KM initiative did not impact on organizational performance, revenue continued to decrease, and staff turnover rate stayed high.

The study points to the following failure factors.

1. Top management support was purely lip-service. They left KM entirely to the departments, without giving them the support, backing, prioritisation or resources that they needed. In consequence, staff did not see KM as a significant organisational program.

2. Management saw KM as “copy what other organisations are doing” rather than learning to improve from within. This “chasing the best” strategy failed, as “what others are doing” was not always relevant, suitable or congruent to the organisation.

3. There was no structure; no framework, no process. Reading between the lines, this seems to have been an exercise in IT Push. As the study says

“No specific and/or appropriate guidelines for such (Knowledge) sharing had been devised. As a result, instead of having discussions that were directly related to tasks, or least contributed to idea generation, frequent chats (e.g., gossiping) among employees and wandering around were found. Many employees were confused with what the sharing was all about. Some employees even perceived KM negatively as interfering with activities important to their daily tasks, creating resistance to participation in what was perceived to be a temporary fad.

4. Data retrieval was difficult as knowledge was not synthesised

The silo organizational structure of with disentangled databases for knowledge capture caused more harm than good. Some employees asserted that they did not have the incentive to access or utilize the departmental knowledge handbook and procedural guidance (available from databases) as it is a time-consuming endeavour to dig from the pile of information. Some employees found knowledge incomprehensible as it was presented and stored in various formats, with jargons and symbols that were neither standardized nor systematized across departments.

5. The use of monetary bonuses to incentivise sharing was counter-productive, as individuals competed against each other to get the money

6. An IT solution was applied to an oral culture. “It was found that IT adoption and acceptance remained low due to employee preference for face-to-face conversation and knowledge transfer instead of technology-based communication, and the general low computer literacy that intensified the fear of technology”

7. Once KM initiatives had been started, there was no ongoing support

8. The initiatives were all for “quick fixes” rather than a longer-term review of processes and procedures.

I would also add a 9th issue – 15 months is a short time for a KM program, even though this was a relatively small organisation.

With so many challenges, the KM effort was doomed. Any one of these issues could derail a KM program – all 8 together were fatal.

This study reinforces the critical role that senior managers play, the way that KM needs to be addressed and supported as a change management program and introduced as a framework, and the need to tailor this framework to the organisational culture, working habits, knowledge needs, structures, and long and short term goals.

Pay attention to these issues, and hopefully you will not fail.

Here is a sad story, about how trying to save costs in KM destroyed value.

The moral of the story is about hopw bring people together face to face and letting them experience the knowledge for themseves, in context, established the necessary credibility for re-use.

The organisation in question had an effective approach to knowledge sharing.  They would identifying those parts of the business which had knowledge to share (the “supplier” business units), and they would set up knowledge visits from the other business units to come and see for themselves what the supplier business unit had to offer.

The people who came on these learning visits were the operators, the foreman, and the knowledge workers.  They could watch how the supplier business unit did things, they could identify new knowledge and new practices that they could use, and they could see for themselves how things were done. They could also suggest, and sometimes demonstrate, better practices they used at their own sites, so that knowledge transfer was two-way.

This approach worked.  Because the people coming on the visits were the people who would apply the knowledge, and because they could see that knowledge in context, they could go home convinced that they had seen a new and better way to do things.  Seeing was believing.  Knowledge was transferred, best practices reapplied, and significant cost savings resulted.

Then management changed the system.

They believed that transferring knowledge in this way was expensive, as each knowledge transfer involved sending somebody to another country.  Cost pressure meant that there was a restriction on travel budgets, and they decided to do things a different way.  Instead of sending the operators, the foremen and the knowledge workers, they decided to send a few company experts instead.  The theory was that the experts would then come back and spread the knowledge around the other operating units, delivering knowledge transfer more cheaply.

What happened was that because the operators and knowledge workers had not personally seen the knowledge in use, the suggestions that the experts brought back lacked credibility.  The experts found it very difficult to get people to reuse knowledge which they had not personally seen in use.  Because they hadn’t seen, they didn’t believe, or at least they didn’t trust.  The rate of knowledge reuse dropped.

Eventually the entire system was cancelled.  Now the different operating units work in silos, with no sharing and reuse of best practice.

The moral of the story, of course, is that if you wish to transfer knowledge to somebody, then you should involve them first-hand in the transfer wherever possible, and bear the costs of this.  It’s very difficult for experts to transfer knowledge on someone else’s behalf.

Seeing is believing, and experiencing first-hand is important.  Certainly this may require an investment in travel, but the investment pays for itself in improved performance.  Trying to save some of the money risks losing all of the value, and the key people to involve in the knowledge transfer are the knowledge workers themselves.

An interesting study on a failed Knowledge Management project highlights 7 reasons for failure

Here is an interesting study of a failed KM approach in a Pharma organisation, by Ashley Braganza1 and Gerald Mollenkramer. It starts with the following vignette.

On a sunny morning in July 1999, Samuel Parsons, Head of Knowledge Management at PharmaCorp, convened his regular Monday team meeting. ‘Last Friday evening I was informed that Wilco Smith, Head of Pharma Global Order Handling Services, no longer wants KM. His only question now is how to off-board the KM staff.’ Thus came to an end a three-year initiative that at the outset was considered to be ‘the KM showcase for the firm’.

This has happened to too many organisations. We need to learn from failures such as this, and luckily that’s what the authors of the study try to do.  The authors draw 5 conclusions from the study – these largely echo my 7 reasons for KM failure. The 5 conclusions are as follows;

1. Avoid defining knowledge within functions or silo-oriented communities of practice; instead define knowledge at the level of business processes. Within the study Project, KM was operationalized through the functions, and each function would have its own IT interface to the knowledge repository. As a result the relevance stored content to others was not addressed, and also the technology infrastructure became too fragmented and complex for the IT domain to deliver.

2. Remember that knowledge is operationalized by people; hence, a knowledge management initiative must relate knowledge to people’s day jobs.  People lacked a clear context for specifying what knowledge was business-critical, so each knowledge-element was assigned implicitly equal weighting, and specific elements that are business critical got insufficient attention

3. Tacit knowledge resides within people and their behaviours; hence attempting to apply Information Technology to tacit knowledge is fraught with difficulty. Instead, it is explicit knowledge that is most susceptible to the application of Information Technology.  Pharma focused primarily upon explicit knowledge. This is a common feature of many knowledge management projects that yield poor results.

4. Knowledge is context-specific. It should be owned and maintained by people within the organization. Hence, external input to knowledge management initiatives must be carefully managed to ensure people within the organization are in control of the initiative at all times. Three different consulting firms were involved at different times, and the external consultants held key roles. This placed team members at a disadvantage when the consultants left.

5. Implementing knowledge management involves change in the organization. Understand the organization’s willingness to change and manage people’s expectations appropriately.People at all levels of the organization must feel part of the knowledge management initiative, and senior managers must create a space within which people from different functions can come together to forge knowledge across each business process

When lesson learning failed in the Australian Defence Force, they blamed the database. But was this all that was at fault?

Here’s an interesting 2011 article entitled “Defence lessons database turns off users”. I have copied some of the text below, to show that, even thought the lessons management software seems to have been very clumsy (which is what the title of the article suggests), there was much more than the software at fault.

 “A Department of Defence database designed to capture lessons learned from operations was abandoned by users who set up their own systems to replace it, according to a recent Audit report. The ADF Activity Analysis Data System’s (ADFAADS) was defeated by a “cultural bias” within Defence, the auditor found. Information became fragmented as users slowly abandoned the system”.

So although the article title is “defence lessons database turns off users”, the first paragraph says that it was “defeated by cultural bias”. There’s obviously something cultural at work here ……

“Although the auditor found the structure and design of the system conformed to ‘best practice’ for incident management systems, users found some features of the system difficult to use. Ultimately it was not perceived as ‘user‐friendly’, the auditor found. Convoluted search and business rules turned some users against the system”. 

….but it also sounds like a clumsy and cumbersome system

“In addition, Defence staff turnover meant that many were attempting to use ADFAADS with little support and training”.

…with no support and no training.

“An automatically-generated email was sent to ‘action officers’ listing outstanding issues in the system. At the time of audit, the email spanned 99 pages and was often disregarded, meaning no action was taken to clear the backlog”.

There needs to be a governance system to ensure actions are followed through, but sending a 99-page email? And with no support and follow-up?

 “It was common for issues to be sent on blindly as ‘resolved’ by frontline staff to clear them off ADFAADS, even though they remain unresolved, according to the auditor”.

Again, no governance. There needs to be a validation step for actions, and sign-off for “resolution” should not be developed to frontline staff.

 “Apart from a single directive issued by Defence in 2007, use of the database was not enforced and there were no sanctions against staff who avoided or misused it”.

There’s the kicker. Use of the lessons system was effectively optional, with no clear expectations, no link to reward or sanction, no performance management. It’s no wonder people stopped using it.

So it isn’t as simple as “database turned off users”. It’s a combination of

• Poor database
• Poor notification mechanism
• No support
• No training
• No incentives
• No governance
• No checking on actions

It’s quite possible that if the other items had been fixed, then people might have persevered with the clumsy database, and it’s even more likely that if they built a better database without fixing the other deficiencies, then people still would not use it.  A

What they needed was a lessons management system, not just a database.

So what was the outcome? According to the article,

…..establish a clear role and scope for future operational knowledge management repositories, and develop a clear plan for capturing and migrating relevant existing information ….. prepare a “user requirement” for an enterprise system to share lessons.

In other words – “build a better database and hope they use it” Sigh.

Is learning from failure the best way to learn, or the worst?

Classic Learning by Alan Levine on Flickr

I was driven to reflect on this when I read the following quote from Clay Shirkey;

“Learning from experience is the worst possible way to learn something. Learning from experience is one up from remembering. That’s not great. The best way to learn something is when someone else figures it out and tells you: “Don’t go in that swamp. There are alligators in there.”

Clay thinks that learning from (your own bad) experience is the worst possible way to learn, but perhaps  things are more complex. Here are a few assertions.

• If you fail, then it is a good thing to learn from it. Nobody could argue with that!
• It is a very good plan to learn from the failure of others in order to avoid failures of your own. This is Clay’s point; that learning only from your own failures is bad if, instead, you can learn from others. Let them fail, so you can proceed further than they did. 
• If you are trying something new, then plan for safe failure. If there is nobody else to learn from, then you may need to plan a fail-safe learning approach. Run some early stage prototypes or trials where failure will not hurt you, your project, or anyone else, and use these as learning opportunities. Do not wait for the big failures before you start learning.
• Learn from success as well. Learn from the people who have avoided all the alligators, not just from the people that got bitten. And if you succeed, then analyse why you succeeded and make sure you can repeat the success.
• Learning should come first, failure or success second. That is perhaps the worst thing about learning from experience – the experience has to come first. In learning from experience “the exam comes before the lesson.” Better to learn before experience, as well as during and after.  

It is possible for the members of a Community of Practice to lose trust in the community as an effective support mechanism. Here’s one story of how that happened.

The story is from one of Knoco’s Asian clients.

• This community started well, with 4 or 5 questions per week from community members. 

• The community facilitator forwarded these questions to community experts to answer, rather than sending them to the whole community and making use of the long tail of knowledge.  This may well have been a cultural issue, as her culture reveres experts.

• Sometimes the expert would answer on the community discussion forum, but most of the time they answered by telephone, or personal visit. Therefore the community members did not see the answer, and were not even aware the question had been answered.

• Often the expert did not have enough business context to answer the question (this is a complicated business), so when they did answer on the forum, the answer was vague and high-level. In a culture where experts are not questioned, nobody interrogated these vague answers to get more detail. 

• Often the questions themselves were asked with very little context or explanation, so it was not possible to give good answers. The community facilitator never “questioned the question” to find out what the real issue was.

• Where there was a discussion around the question, it very quickly went off-topic. Again the facilitator did not play an active role in conversation management.

• When the facilitator followed up, to see if the questioner was satisfied by the answer, the answer was usually No.

• A year later, the questions have dropped to 1 or 2 a month.

You will inevitably make mistakes in your Knowledge Management program. Make sure they are small ones, not fatal ones.

Mistakes by Ron Mader on Flickr

Knowledge Managers need to learn, learning requires experimentation, experiments often lead to mistakes, but mistakes can be costly and derail your program.  That’s a big dilemma for every Knowledge Manager.

Make small mistakes early, and avoid the large mistakes later.