The main reasons for KM failure

From our global survey, the reasons why 18 organisations gave up on KM, and how to stop this happening to you.

One of the questions in our 2014 and 2017 Global Survey of Knowledge Management asked about the current status of KM in the respondents' organisations, and for those 18 respondents who answered "We tried KM but gave up", we asked a supplementary question. 

This question asked them to identify (from a list of 6 options) the reasons why they had given up, choosing as many as were relevant, and adding additional factors which were not on the list.

The frequency of their selections is shown here and listed below.

1. Internal reorganisation was the most common reason, mentioned by 12 respondents out of the 18. I explain in a separate post how to make your KM strategy reorganisation-proof. Knowledge Management is a long term program in a short term world, and needs attention to delivering Proof of Concept exercises, and application of what the Army call a two-pronged approach, so that value is delivered early on through solving business problems, and the KM program proves its worth well enough and early enough to make a case for surviving reorganisation.
2. Cultural barriers was number two mentioned by just under half of the respondents. There will always be cultural barriers (see my post on how to address the cultural barriers). If they were too strong, then your Knowledge Management program was lacking something; either high enough support, or a careful enough change program.
3. Lack of involvement from staff. This often comes when you make KM an optional activity, and rely on initiative and goodwill for people to become involved. This is not a good implementation approach!
4. Technology did not deliver as expected. However technology is not the solver bullet, and n ever will deliver benefits on its own. That's why you need the complete KM Framework, including roles and accountabilities, processes, technology, and governance. 
5. KM did not deliver the expected benefits. I am not sure what was at the root of these two responses. KM, in my experience, when applied to business issues, delivers real value, However it can take a couple of years for that value to be realised. 
6. KM was taking too long to deliver. See number 1 above.

In addition, the respondents added the following reasons for failure. 

• Too much focus on technology platforms and not enough on incentives and cultural elements, 
• The Company was sold to government, which had no interest whatsoever, 
• No customer demand reported 
• New Top Management - Not interested in KM 
• Replaced with Business Process Management
• Lack of executive buy-in / drive 

There are some well-known failure reasons here, which every Knowledge Manager should prepare against, and the most common is Internal Reorganisation, leading to the loss of your support.

A study of KM failure from HK/China

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.

When "cutting corners" in KM destroys value

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

The moral of the story is about how bringing people together face to face and letting them experience the knowledge for themselves, in context, established the necessary credibility for re-use, and that once this was withdrawn, the trust and the re-use were lost.

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.

7 reasons for KM failure in a Pharma company

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

A case study of a failed learning system

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 worst way to learn?

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.  

Learning from failure has an important place in KM, but don't rely on making all the failures yourself. 

A story of how a community lost trust

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.

As far as the community members were aware through observing interactions on the forum, the questions seemed either to receive no answer (as the real discussion happened offline), or to receive worthless answers.  The users lost trust in the community forum as a way to get questions answered effectively, and have almost stopped asking. 

One way to revitalise this community will be to set up a series of face to face meetings, so that the members regain trust in each other as knowledgeable individuals, then ask the members to help design an effective online interaction. This will almost certainly involve asking the community and not the experts, and making much more use of the facilitator to get the questions clarified, to make sure the answers are posted online, to probe into the details of vague answer, and to keep the discussions on topic.

This sort of discussion is needed at community kick-off, so the community can be set up as an effective problem-solving body, and so that the members trust that their questions will be answered quickly and well.

If the members do not trust that the community will answer their questions, they will soon stop asking.

Make small mistakes

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.

You cannot afford to make a big mistake. Too often we see failed KM programs which have started with grand plans and expensive software purchase, failed to deliver, and set back the cause of KM in the organisation for many years.  After a big expensive flop, KM will have a tarnished reputation and management will be resultant to spend any more money.  This can be a fatal KM mistake, and impossible to recover from.

Therefore implementing Knowledge Management should be a series of smaller steps and smaller experiments, where failure will not be fatal. Follow the approach below.

1. Do your research. Find out what is involved in Knowledge Management. Understand what your organisation needs, and the type of KM framework which will support this. Conduct an assessment, review the culture, develop a strategy - all of this before you start to make any changes at all.
2. See what others are doing. Research the world leaders in KM. Find a consultant who has worked with them, and who can share the details.
3. Start with small experiments; proof-of-concept trials and pilots where you introduce a minimum viable KM framework. The proof of concept trials should be small enough that failure doesn't matter; these are your chance to learn as you go, and to experiment. The Knowledge Management pilots can be a little larger, and should be set up to solve specific business problems, but can be a simplified version of the final Knowledge Management framework. Learn from the trials and pilots, until your final KM framework is bullet-proof.
4. Roll out the framework.

Make all your mistakes in Stage 3 (and if you have been diligent in Stages 1 and 2, these mistakes should be few and minor). This is a far better approach than starting with step 4 and making your mistakes there. 

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

101 reasons projects fail

Thanks to Ian Fry for pointing out this excellent site on project mistakes, and what we can learn from them.

Failure as compost, by Cambodia4kids on Flickr

The site is called "Why projects fail" and offers the following resources:

• A blog of case studies 
• A list of 101 common reasons for project failure, with the most common ones highlighted (such as Failure to establish a governance structure, Failure to identify or engage the stakeholders, Failure to communicate, Failure to address scope volatility or creep, and so on)
• A catalogue of catastrophe; a list of major failed projects such as the airport on St Helena where it is too windy to land, the Los Angeles school iPad debacle, and the disastrous Denver Airport baggage handling system
• An index of lessons
• An analysis of classic mistakes

The main learning from this site is that implementing large projects in complex environments is uncertain and risky, and requires attention to many details, a lot of which are strongly influenced by human behaviours.

As knowledge managers, perhaps the most interesting analysis is of decision making. 9 of the 101 reasons for failure are related to decision making, and the first two are directly relevant to KM.

1.Key decisions (strategic, structural or architectural type decisions) are made by people who lack the subject matter expertise to be making the decision 
2.When making critical decisions expert advice is either ignored or simply never solicited 
3.Lack of “situational awareness” results in ineffective decisions being made
4.Failure to bring closure to a critical decision results in wheel-spin and inaction over extended periods of time
5.Team avoids the difficult decisions because some stakeholders maybe unhappy with the outcome
6.Group decisions are made at the lowest common denominator rather than facilitating group decision making towards the best possible answer
7.Key decisions are made without identifying or considering alternatives (aka “First Option Adoption“)
8.Decision fragments are left unanswered (parts of the who, why, when, where and how components of a decision are made, but others are never finalized) resulting in confusion
9.Failure to establish clear ownership of decisions or the process by which key decisions will be made results in indecision and confusion.

KM's role in avoiding project failure

Part of the purpose of Knowledge Management is to ensure that decision makers at all levels have access to the knowledge they need to make correct decisions, and so avoid the commonly known reasons for failure. We can help our organisations learning through introducing effective retrospectives and lesson learned systems that really work, and through periodic lesson analysis to create our own lists of common reasons for failure and our own knowledge asset on how to make projects successful.

Jack Welch on learning from failure.

For many years, I have used a story to illustrate how good managers approach learning from failure. Now Jack Welch, the star of the story, has told it himself.

Jack Welch by Rain Rannu on Flickr

In my apocryphal version of the story, Jack was called into his boss after a dreadful million-dollar business mistake. The conversation went something like this:

Boss - "Why do you think you are here, Jack?"
JW - "I expect I am here so you can fire me"
Boss - "I just spent a million dollars on your education - why would I fire you now?"

Here is the official version from the great man himself, published recently in LinkedIn Pulse

One of us (Jack) actually learned the lesson we’re discussing in this column [about breaking bad news to your boss] very early in his career when, as a plastics engineer at GE, he blew up a factory in Pittsfield, MA. 

Very fortunately, no one was injured, but the roof was obliterated and every window on the top floor of the facility was shattered. Immediately, word came from headquarters: “Come in for a meeting.” Or, as the heart-pounding, inner translation understood it to mean: “Come in to get canned.” Instead, something amazing happened. 

Group Executive Charlie Reed, a brilliant scientist with a professorial bent, had personnel development as his agenda. With gentle determination, he applied the questioning Socratic method to carefully explore all the reasons for the explosion, the ways it might have been prevented, and just as important, what would have to change in the laboratory for such a thing to never happen again. His approach to the disaster in his office – imagine, a blown up factory! – made a lasting and powerful impression. 

Look, you cannot be in business and avoid messy or downright unsuccessful situations forever. To paraphrase, “junk” happens. Just remember, when it does, you’ll be all the better if you own up to it fast, and come to your boss prepared to stick around for a good, long conversation about the road up, out, and forward.

We see two great cultural behaviours in this story, both of them providing cornerstones for organisational learning and knowledge management.

First is an openness to admit and explore mistakes, even million-dollar mistakes involving destroyed factories.

The second is to use every such mistake as an opportunity not for punishment, but for learning and improvement. What Jack describes as the Socratic Method is often formalised as the After Action review - an approach to discussing

• What actually happened?
• Why did it happen?
• What have we learned?
• How do we ensure it never happens again, anywhere in the organisation?

When Jack Welch later rose to be a CEO himself, he did an excellent job of summarising the business vision for Knowledge Management, when he made this statement in the GE 1996 annual report.

“Our behaviour is driven by a fundamental core belief; the desire and the ability of an organisation to continuously learn from any source, and to rapidly convert this learning into action, is it’s ultimate competitive advantage”

I wonder whether that early experience in Pittsfield set the seed for this powerful vision of the ultimate advantage of the learning organisation.

Longford Refinery Disaster - operator error or KM failure?

This book, about the explosion at Esso’s Longford refinery in Australia, is a sobering report of a fatal disaster, and also can be interpreted as a story of an inneffective Knowledge Supply Chain.  It illustrates the potentially appalling consequences of the failure to supply operators with the knowledge they need to operate in a high risk environment.

Image from amazon

"Operator error" might be a first pass conclusion when something goes wrong, but very often you need to look deeper, and understand why the operator made an error.

Did they have all the knowledge they needed to make decisions? Did they have training? Did they have access to expertise?

The story of the Longford refinery disaster explores this question. The disaster is described in Wikipedia as follows;

During the morning of Friday 25 September 1998, a pump supplying heated lean oil to heat exchanger GP905 in Gas Plant No. 1 went offline for four hours, due to an increase in flow from the Marlin Gas Field which caused an overflow of condensate in the absorber. A heat exchanger is a vessel that allows the transfer of heat from a hot stream to a cold stream, and so does not operate at a single temperature, but experiences a range of temperatures throughout the vessel. Temperatures throughout GP905 normally ranged from 60 °C to 230 °C (140 °F to 446 °F). Investigators estimated that, due to the failure of the lean oil pump, parts of GP905 experienced temperatures as low as −48 °C (−54 °F). Ice had formed on the unit, and it was decided to resume pumping heated lean oil in to thaw it.

When the lean oil pump resumed operation, it pumped oil into the heat exchanger at 230 °C (446 °F) - the temperature differential caused a brittle fracture in the exchanger (GP905) at 12.26pm. About 10 metric tonnes of hydrocarbon vapour were immediately vented from the rupture. A vapour cloud formed and drifted downwind. When it reached a set of heaters 170 metres away, it ignited. This caused a deflagration (a burning vapour cloud). The flame front burnt its way through the vapour cloud, without causing an explosion. When the flamefront reached the rupture in the heat exchanger, a fierce jet fire developed that lasted for two days ......

Peter Wilson and John Lowery were killed in the accident and eight others were injured.....Esso blamed the accident on worker negligence, in particular Jim Ward, one of the panel workers on duty on the day of the explosion.  The findings of the Royal Commission, however, cleared Ward of any negligence or wrong-doing. Instead, the Commission found Esso fully responsible for the accident:

So what might cause apparent "worker negligence" (aka operator error) in cases like this?

The disaster happened when hot oil was pumped into the cold exchanger, which was the wrong thing to do, but why did the operators do this? The book mentions what it calls "latent conditions" which can cause operators to make poor decisions, such as "poor design, gaps in supervision, undetected manufacturing defects or maintenance failures, unworkable procedures, clumsy automation, shortalls in training, less than adequate tools and equipment (which) may be present for many years before they combine with local circumstances and activate failures to penetrate the system's many layers of defences".

If an operator does not have the correct training, or the correct procedures, then you could argue that they do not have the knowledge to make the correct decision, and so may end up making mistakes not through error or negligence, but through ignorance. 

If they do not have the knowledge they need to make an effective decision, then this could be seen to be a failure of the knowledge management system, for not providing the operators with the knowledge they need to avoid the error, to make the correct decision, or to take the necessary preventative action when things go wrong.

In knowledge management terms, the investigative commission found these three contributory factors (again, according to Wikipedia), which talk to a lack of knowledge on behalf of the operators, lack of access to more skilled knowledge, and lack of communication of knowledge - all of them potential KM failures

• inadequate training of personnel in normal operating procedures of a hazardous process;
• the relocation of plant engineers to Melbourne had reduced the quality of supervision at the plant;
• poor communication between shifts meant that the pump shutdown was not communicated to the following shift.

The following quote from the book is a statement from the operator himself, and you can hear from the language he uses that this was way outside his experience and knowledge base.

"Things happened on that day that no one had seen at Longford before. A steel cylinder sprang a leak that let liquid hydrocarbon spill onto the ground. A dribble at first, but then, over the course of the morning it developed into a cascade ... Ice formed on pipework that normally was too hot to touch. Pumps that never stopped, ceased flowing and refused to start. Storage tank liquid levels that were normally stable plummeted ... I was in Control Room One when the first explosion ripped apart a 14-tonne steel vessel, 25 metres from where I was standing. It sent shards of steel, dust, debris and liquid hydrocarbon into the atmosphere".

In a situation like this, where the wrong operational decision can be lethal and operator error through ignorance cannot be allowed, effective knowledge management and an effective knowledge supply chain (in the sense of ensuring that people have access to the knowledge they need, at the time they need it, in order to make correct decisions) is not just a nice-to-have; it's a life saver.

What happened to a community when facilitation stopped

Here is a cautionary tale about the importance of Community of Practice facilitation, and what happens when the facilitator is removed.

The story comes from Tom Humbarger, who was the community facilitator for a professional community from January 2007 until he was made redundant in July 2008.

During Tom's active role the community grew from zero to 4,000 members but as the picture above (of the number of weekly visits to the community site) shows, things changed once he was no longer playing the facilitator role. Once he was no longer in place

• Membership growth dropped by more than 63% on a week to week basis. 
• The number of visits to the community forum dropped by 60% 
• The number of pages viewed per visit dropped by 22% 
• The time on site decreased by 33%

The community of practice limped on for a few more months, but performance was lacklustre.

Tom's story, and the graph above. demonstrate clearly the value that a facilitator brings to a community of practice. 

NASA's view of the "common KM mistakes"

This video, from Edward Rogers of NASA, explans what he sees as the common mistakes in implementing KM. All of these stem from one reason, which is that KM people too often fail to learn from the experience of the past.

Compare these with our 7 most common reasons KM programs fail


Edward's 5 most common reasons for failure are

1. Attempting to implement a KM system in a hurry, by "buying a KM program". KM at NASA has been a 10 year proposition.
2. "Gaming" KM; trying to manipulate people though tricks and incentives
3. Applying a KM framework "off the shelf" rather than tailoring it to your own context
4. Selling KM with an unrealistic revenue target (but also see his video on quantifying the value of KM pilot projects)
5. Letting IT and the CIO handle KM, which ends up with a data and information system, not a KM system

Learning from Failure, learning from Success

---

Trial and error, or trial and success? Which is the better learning mechanism? 

Crossroads by Chris Potter on Flickr and stockmonkeys.com

A thought provoking piece here, makes the argument that people learn much better from their mistakes, as a result of the emotional charge and the emotional scars that failure brings.

On the other hand, a well-argued article in  Business Insider suggests that success is a better teacher, because a fail mode only tells you one option not to try; it does not tell you how to succeed.

Which is correct, and what is the implication for Knowledge Management?

Personally I tend slightly more towards the "learn from success" argument.

I believe that on a corporate level, or as a society, we collectively make the biggest learning steps when we finally succeed. Think of Edison and his light filament; when did he do the most learning? When he tried each of the 99 options that didn’t work, or when he found the one that did?

Now you can argue that he learned from both, but now let’s look at transferring that knowledge. If you were a light bulb maker, which of these two statements would be of most value to you?

1. You can’t make a light bulb filament out of cat hair 
2. You can make a light bulb filament out of tungsten 

The implication for Knowledge Management

The implication for Knowledge Management is this:

You need to learn from both success and failure, but you need to learn much more carefully from success, because success is what you want others to replicate.

It is learning from the successes that are most valuable for others, so that is where the most KM effort needs to be applied.

As an example, let's look at the typical systems set up to learn from safety incidents. Most of these systems have detailed root cause analysis when there is a near miss or an incident, and the lessons from these are sent around the organisation so others can learn from this safety failure.

However it is far more important to learn from the factory or plant that never has an accident, and never has a near miss. That is the factory everyone needs to emulate, which means they need to carefully understand WHY they are so safe, and then learn from this.

We know that it is human nature to learn best from mistakes, but we don’t want to be at the mercy of human nature. We don’t want people to have to screw up in order to learn. We don’t want failures and screw ups if we can possibly avoid it, because mistakes and screwups can cost money, they can cost lives (in certain cases), and they can cost careers if they are big enough.

Learning in a KM Framework

The ideal situation, in any mature KM or lesson-learning framework, is that you learn as a matter of course, whether you deliver failure, success or a mixture of both (and it usually is a mixture).

Learning, as in lesson identification meetings such as After Action reviews and Retrospects, should be a routine exercise, regardless of success or failure. Address both, learn from both, and give particular attention to understanding the causes of success.

Fail fast and fail often is a good mantra, so long as it leads to success, and it is the success that is the greatest learning opportunity.

Why does Knowledge Management fail? (and how to avoid this happening)

---

In a previous blog post, I mention 7 common reasons why Knowledge Management fails. Now we can add to this another source of data.

One of the earliest questions in our 2014 Global Survey of Knowledge Management asked about the current status of KM in the respondents' organisations, and for all those who answered "We tried KM but gave up", we asked a supplementary question. 

In this question the Respondents from the 13 companies which had abandoned Knowledge Management were asked to identify the factors behind this decision, choosing as many as were relevant, and adding additional factors which were not on the list.

The frequency of their selections is shown here and listed below.

1. Internal reorganisation. I explain in a separate post how to make your KM strategy reorganisation-proof. Knowledge Management is a long term program in a short term world, and needs attention to delivering Proof of Concept exercises, and application of what the Army call a two-pronged approach, so that value is delivered early on through solving business problems, and the KM program proves its worth well enough and early enough to make a case for surviving reorganisation.
2. Cultural barriers. There will always be cultural barriers (see my post on cultural barriers and how to break them). If they were too strong, then your Knowledge Management program was lacking something; either high enough support, or a careful enough change program.
3. Lack of involvement from staff. This often comes when you make KM an optional activity, and rely on initiative and goodwill for people to become involved. This is not a good implementation approach!
4. Technology did not deliver as expected. However technology is not the solver bullet, and n ever will deliver benefits on its own. That's why you need the complete KM Framework, including roles and accountabilities, processes, technology, and governance. 
5. KM did not deliver the expected benefits. I am not sure what was at the root of these two responses. KM, in my experience, when applied to business issues, delivers real value, However it can take a couple of years for that value to be realised. 
6. KM was taking too long to deliver. See number 1 above.

In addition, the respondents added the following reasons for failure. 

• Too much focus on technology platforms and not enough on incentives and cultural elements, 
• The Company was sold to government, which had no interest whatsoever, 
• No push or support from the Executive Committee 
• No customer demand reported 
• New Top Management - Not interested in KM

There are some well-known failure reasons here, which every Knowledge Manager should prepare against.

Why KM fails - case study from Hong Kong

---

If we want to succeed in Knowledge management, we need to learn from both successes and from failures. The 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.

Don't just focus on the tool - failure of Best Practice Replication at Engico

---

Yesterday I blogged about the success of Best Practice Replication (BPR) at Ford.

BPR was such a simple idea, and Ford licences the software to other companies, so why should it not work everywhere?

And yet it didn't work everywhere.

Here, to balance the success story, is an interesting case study of how BPR completely failed at Engico, and how that failure persevered for 4 years. For me the most interesting sentence in the whole article is this one

"Under certain circumstances, failure can reinforce belief; one merely needs a good reason to explain the failure".

Here's what happened.

• In 1999, Engico read about BPR and said "we want that." BPR was seen as addressing varius problems related to silo working and resolution of common problems

• They attempted to licence the Ford BPR system. 

• Negotiations failed and they decided to build their own system

• The new system was launched, on a new platform rather than the existing Lotus Note platform, and supported by plans for communities of practice.

• For the innovators, the launch was almost ideological. "For them the “idea of BPT as such” was so powerful, so positive and so strong, that they fully believed “soon, everybody will be using the BPT process because it is so clearly the right thing to do”. Now, all that needed to be done was to launch the process".

• The engineers in the factories were not interested in voluntarily submitting best practices. "Their focus  lies firmly with their own organization…their own work with improvement. And they have their network, and they have their meetings via telephone…and they meet once or twice a year in this network. And they are probably satisfied"

• A German factory submitted several best practices, and then waited to see if others joined in. When they didn't, the German factory refused to submit any more. "Why should I waste my time on distributing my stuff, if I don’t get anything in return? Show me first of all that the others are submitting something."

• The users blamed several things - they lack of involvement in the design process, the difficulty of assigning value to practice improvements, and problems with the IT (which was unfamiliar, hard to use, and ran into connectivity and network problems).

• So the innovators decided to fix the technology, and in 2001 removed the IT tool for rework. At the same time the underlying IT platform was being revised.

• By 2002 there was a new version, but this had become more complex, and still did not work.

• Work continued. Deadlines slipped.

• "After struggling for nearly three years to get the BPT process underway by attempting to convince the process development managers out in the divisions to establish new communities, by obtaining a commitment from managers who had already established communities, by solving the technical difficulties, and by persuading the members of the existing communities to describe and submit their best practices through the system, to no avail, the innovators acknowledged towards the end of 2003 that the BPT project was a failure".

I think we can see several reasons for failure here. 

• The BPR approach did not help the workers by providing them with solutions, but added more burden. 
• The tool was rolled out as "the right thing to do" rather than a work aid. 
• The tool was seen as the solution
• The tool was too new - new platform, new technology, new processes. 
• When the tool was not met with the correct behaviours, the solution was "change the tool" rather than change the behaviours (probably because changing the tool was seen as the easier thing to do, and because of the ideological belief described above).
• Engico persevered with the tool for 4 years before giving up. The author describes this as "A Surviving Failure" (ie a failure that continues to survive) and sees the cause for this as the innovators' strong belief in "the technologies inherent goodness". He says

"The innovators were disappointed, but they did not give up. As is often the case in KM projects and innovation projects in general, they put the blame on the intended users and others who did not understand the tremendous benefits of using the new technology and/or technical problems. And when the technology resisted, when they encountered technical problems with the IT infrastructure – especially with the CoolSnake Intranet platform – the innovators argued that once the problems were solved, the BPT process would work, because the “idea of BPT as such was good” and in any case “had nothing to do with the IT system”. The BPT innovators were certain that once their machine worked, everybody would be convinced of its goodness. But, the machine did not work and therefore could not “convince anyone because of its good working order".

Knowledge Transfer, seeing is believing

---

I heard a sad but instructive story this week.  The moral of the story is about the credibility of knowledge, and how seeing knowledge for yourself, in context, establishes the necessary credibility for re-use.

This organisation 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.  It’s very difficult for experts to transfer knowledge on someone else’s behalf.  Seeing is believing, and seeing 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.

The risk of hanging on to knowledge - the Wright brothers and Wing Warping

This is a story about the Winners' Curse - the observation that Leaders make poor Learners, often because they are unwilling to let go of the knowledge that made them leaders in the first place. The story is taken from the excellent book Profiles in Folly.

The Wright brothers are not a couple that you would expect to encounter in a book about Folly. Their development of the first powered flight reads like a manual in Knowledge Management. They created a Knowledge Management plan at the start of their "project", realising that there were three key areas of knowledge which they needed to develop before they could expect success - how to generate lift, how to power the aircraft, and how to control the flight.

They conscientiously did their Learning Before Doing - Wilbur's letter to the Smithsonian reads like the letter of a Knowledge Manager

“I am an enthusiast, but not a crank in the sense that I have some pet theories as to the proper construction of a flying machine. I wish to avail myself of all that is already known and then if possible add my mite to help on the future worker who will attain final success.” Wilbur Wright

They did meticulous research into lift, building the worlds first wind tunnel in order to devise the optimum wing profile, thereby inventing the science of aeronautics. They transferred that research into the design of the power system and the propeller, realising that the propeller was just a wing, oriented sideways. Finally they addressed the "Breakthrough concept", solving the problem of controlled flight through a solution known as "Wing Warping", which they tested extensively on unpowered gliders. They had addressed the three key areas of knowledge, and their maiden flight was almost a formality (as Wilbur wrote at the time, "“There is now no question of final success.”).

The rest is history. The first powered flight, the first patents on a viable flying machine, and a start at pole position in the aviation industry. Fame and fortune looked assured.

So where did it go wrong?

One key to the Wright brothers' initial success, and the one they were quickest to patent, had been Wing Warping. However steering an aeroplane by Wing Warping was very difficult to learn and very tricky to master, and it was far too easy to lose control. Already a better means of control was being developed by other inventors - the use of wing ailerons - hinged flaps at the trailing edge of the wings. According to the author of "Profiles in Folly" -

"The United States entered World War 1 with woefully obsolete aircraft. The Wrights stubbornly refused to abandon the wing-warping system, even after it repeatedly proved fatal. On September 17, 1908, Lt Thomas Selfridge became the first military pilot to die in a crash ..... more than 20 other aviators were killed in crashes almost certainly caused by a loss of control linked to wing warping.......Yet even after the Wrights clung to wing warping, even after they were manufacturing aircraft full-time through their own company, they stubbornly defended in court their patent right to the aileron system, discouraging others from using it for fear of suffering lawsuit. 

"The Wrights, who had made the greatest breakthrough in the development of aviation, then hobbled that development before finally abandoning the field altogether".

The Wright brothers suffered from winners curse. Having won the race, they clung to the knowledge they had developed, even as it became obsolete as better solutions were developed, and eventually sold their company and retired. First learner advantage only remains an advantage, if the learner continues to learn. If the leader doesn't continue to learn, they don't continue to lead.

(In a postscript, the author of Profiles in Folly points out that Wing Warping has returned as a viable technology in the 21st century (see for example the Active Aeroelastic Wing), but only because it relies on multiple servo motors controlled by advanced microprocessors, rather than Orville and Wilbur's pulleys and string.)

Why KM failed - Pharma organisation.

---

Here is an interesting study of a failed KM approach in a Pharma organisation. 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.
2. Remember that knowledge is operationalized by people; hence, a knowledge management initiative must relate knowledge to people’s day jobs. 
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. 
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. 
5. Implementing knowledge management involves change in the organization. Understand the organization’s willingness to change and manage people’s expectations appropriately.