Friday, 2 October 2015

Wikis - to edit, or not to edit?

There are two main approaches to Wikis as a Knowledge Management component - providing page editors who act as validators or gatekeepers, or allowing free editing.

In the first case, the contents of the wiki page can be edited by only a few people, while others can suggest edits, or comment on existing content, by using the comments facility.  

In the second case, everyone has editing rights, and the assumption is that if enough people edit, the wiki is self-correcting and that errors and opinions will not last in the long term.

The second model is often quoted as the Wikipedia model, although even Wikipedia is not so simple to edit. Although everyone can make minor edits, the protocol is to discuss major edits in the article discussion/talk page prior to publishing, and even on Wikipedia there are locked pages that only approved people can edit.

How to decide which model to take

Before we look at each model, we need to consider that knowledge in an organisation generally has three levels of validity.

1. Mandatory, or “Must Do” knowledge. This is the level of company standards, and everybody reading this particular guidance document realises that they need to follow exactly what’s written. If there is a major problem, they need to get in touch with the process owner and discuss it with them, but that the default should be to follow this documentation exactly.

 2. Advisory, or “Should Do” knowledge. This is the level of best practices, and everybody reading this particular process documentation realises that this is current best way to approach this particular process, based on existing company knowledge. However there is always a drive to improve on best practice, and if somebody can find an even better way, then that’s great. So Advisory process is advised, but not compulsory. However if people ignore advisory knowledge and things go wrong, some awkward questions may be asked.

 3. Suggested, or “Could Do”. This is the level of good ideas or good practices that others in the organisation have used, which the reader should feel free to reuse or re-adapt to his or her own context. These good ideas can still save the reader a lot of time and effort, but there is no real requirement to copy them.

Level three is the chit-chat level of knowledge, in social media, discussion forums or meetings, where ideas and opinions are kicked around and solidified over time. There is a validation step to move from level 3 to level 2 (validation by SMEs or a Community of Practice), and another validation step (validation by the company) to move from level 2 to level 1. 

Where wikis come into the picture

The question is - what knowledge do you want to host on your Wiki? Level 3, or level 2?

The KM4Dev community use their wiki mainly as level 3 - as they say

"This wiki is both a working area for the Knowledge Management for Development (KM4Dev) community and a way for us to make our joint work accessible to a wider audience"
Wikis in places like Shell, Pfizer and Conoco use the wiki for level 2. Level 1 knowledge is held in the discussion forums and lessons management systems, and the wiki page editor promotes content to the wiki once it is considered "valid". They make reference to level 1 knowledge by linking to official procedure documents and standards.

Wikipedia, without making this explicit, is primarily for level 2 knowledge. The article discussion/talk pages are where the level 3 interchange happens, and the promotion of major edits to the main page is by "editorial consensus".


If you are using your wiki for level 3 knowledge, then allow everyone to edit.

If you are using your wiki for level 2, then a) introduce a validation step, and b) decide where your level 3 conversations will take place. 

Thursday, 1 October 2015

Quantified success story #93 - lives saved through Knowledge Managament

The video below is a KM success story from the Customer Service wing of KM

Ths story is told by Linda Yeardly of eGain customer support software. It describes how rapid access to high quality knowledge allowed a new member of a Gas Utility customer service team to make a call that probably saved many lives.

Wednesday, 30 September 2015

The Genesis of a KM program

Knowledge Management programs do not come from nowhere. There is usually a set of circumstances which combine to bring KM to the forefront.

This is the story of the set of circumstances that combined to kick off KM at BP in the 1990s, taken from Gorelick et al. These circumstances include

  • A structural need for knowledge sharing
  • A successful proof of concept
  • Inspiration from outside, and
  • A compelling business case

In 1995 a significant organizational change occurred in BP’s structure. It went from a traditional hierarchy to a federal organization. The federal structure had a small central core with large semi-autonomous business units outside the core. The leadership in the central core provides enterprise-wide vision, and everyone is expected to consider themselves as being under the “same flag”. However, for each unit in the federation, separate performance contracts are negotiated that drive strategy and operating tactics... A crucial path to success is asking for help and reusing knowledge from elsewhere in the federation. 
Virtual Teamworking 
To encourage the cross-business-unit teamwork and open communication essential to the federal structure, the Virtual Teamworking (VT) project was initiated. This project aimed to allow the creation of virtual teams, with geographically separated members, brought together by desktop video-conferencing. 
The model for this initiative was to address People, Process and Technology issues simultaneously. Thus the project deliverables were a technological solution plus a coaching process, that facilitated people connecting from disparate locations using PC video conferencing. Kent Greenes was selected to lead this initiative. 
An important message that ‘the VT project was more than technology’ was sent when the VT project did not report into the information technology organization, but rather to the BP Group Chief Executive, part of the small central core of the federal structure. VT was expected to create a more enabling technology in the new flattened organization....
The value of the VT project was confirmed at a meeting Kent had with Sir John Browne (BP CEO) to report the results of the VT initiative.  Browne was “grinning from ear to ear” as he said that his idea had created the ability to align and engage people in a way that couldn’t happen before. It encouraged transferring of experience that led to commitment, and from commitment came delivered results. 
 Information to Knowledge 
In February 1996, the VT team realized that the virtual teams they were supporting were not working with only data and information. They were seeing interactions about knowledge. It became evident that the “real value”was sharing know how and experience - tacit knowledge....
In the third quarter of 1996 the Technology Advisory Board of BP senior scientists, R&D etc., external professors and industry experts met for one of the two or three colloquia BP delivers annually. This colloquium was focused on the enabling use of IT. A memorable event was Dr. John Henderson's (Boston University) rousing speech to the group on knowledge and leadership. Among the stories Henderson told was this story from the US Army – a compelling story that provided BP with a vision of what KM could make possible.... The IT Colloquium ignited the KM fire at BP by legitimizing Knowledge Management....
The Genesis of the KM Team 
After the IT Colloquium, a task force was formed with 5-10 executives, members from each business stream and thought-leaders from business units as well as central functions such as HR, IT and organizational learning. This task force was charged with assessing the state of Knowledge Management in BP and making recommendations... 
The task force concluded that the BP environment had many factors conducive for Knowledge Management, such as a team structure, the IT infrastructure with the Common Operating Environment (COE) and results-based behavior orientation. However, there was a lack of ability to capture what had worked, and training and development was recognized as not being the place to embed and generate learning about knowledge processes. The task force concluded that there were good things happening, but that a major knowledge effort was needed.... (and) recommended that a dedicated Knowledge Management team be sanctioned, containing core team members from the existing VT team. 
The task force presented its recommendations to the Managing Directors. The presentation was very persuasive. A half billion dollars annual saving was the anticipated “big prize” for BP, if they found a way to better leverage know-how. The KM initiative did not have to be built from the ground up. The new team would build on what had been developed in the VT project. They would focus on raising awareness and piloting to leverage the “good stuff” happening within BP. The goal was to embed Knowledge Management within the businesses. 
The steering committee approved all the task force recommendations with one exception. One member raised a concern about the KM effort being a central function. Keeping with the principles of the federal structure he believed that the business streams should own the Knowledge Management function. Kent agreed that ultimately it should not be a corporate unit or be organized to live forever. He vividly remembers saying; “I won’t let it become a corporate thing. We will revisit the existence of a KM Team year by year”. 
Within a week a decision was made to establish a central KM team with Kent leading it, reporting to a corporate Managing Director. Kent believed that this was a way to ‘join VT and KM at the hip’, to keep going with what had started to change the business and provide a lever for further improving performance.

Tuesday, 29 September 2015

The verbs of Knowledge Management

I posted recently an analysis of KM definitions, concentrating on the nouns. Here is an analysis of the verbs.

The idea to look at the verbs was suggested by "the other" Nick Milton in the comments to my previous blog post. I took a collection of 65 KM definitions and did a quick word count. 

Here are the results for each verb

Use                                23 appearances
Create                            17
Share                             15
Leverage                       11
Apply                            11
Improve                         11
Access                           10
Manage                           9
Capture                           7
Store                               6
Integrate                         6
Organize                         5
Generate                         5
Analyze                          5
Gather                             4
Transfer                          4
Retrieve                          4
Enhance                          4
Develop                          4

Verbs appearing 3 times - Facilitate, Optimize, Increase, review, Put, Promote
Verbs appearing 2 times - Distribute, Disseminate, Retain, Save, Acquire, Get, Exploit, Accumulate, Collect, Connect
Verbs appearing once - Guard, Grow, Expand, Cultivate, Elicit, Diffuse, Maintain, Understand, Represent, Spark, Comprehend, Formalize

What does this tell us?

It tells us that we, as a collective industry, are far less certain about what we actually do with knowledge, than we are about the knowledge itself. While I had 7 main nouns in my previous analysis, here I have over 50 verbs.  However there are some synonyms here - acquire, get, gather, collect, capture, elicit, are all to some extent synonyms.  We can therefore look at synonym clusters

Verbs associated with the application of knowledge appear 55 times
Retrieve, apply, use, access, review, exploit, understand, comprehend

Verbs associated with the improvement of knowledge, or of the KM process, appear 53 times
Leverage, manage, facilitate, grow, optimise, develop, enhance, expand, integrate, analyse, cultivate, formalise, represent, increase, improve

Sharing verbs appear 29 times
Transfer, distribute, share, diffuse, connect, promote, disseminate

Getting Verbs appear 23 times
Gather, capture, generate, capture, acquire,, get, elicit, collect

Creating verbs appear 22 times
Create, generate

Storing verbs appear 12 times
Store, guard, maintain, accumulate, retain, put, save, organize

So now we have 6 verb clusters, to go with our 7 nouns. At the moment, it seems possible to perm any combination of these into any KM definition you want, but the most generic definition from an analysis of all existing definitions seems to be

"Knowledge Management is the means of Improving the way Knowledge is Created, Acquired, Stored, Shared and Applied".

Simple, boring, but good enough.

Monday, 28 September 2015

4 cases where you don't need knowledge management

I have argued strongly in the past for Knowledge Management to be business-driven, and to be introduced as a solution to specific business needs; for Knowledge Management to be a strategic business support tool. But what if there is no business need? 

  • What if the company is working in a mode of “It works – let’s not mess with it”?
  • What if the inefficiencies of having no KM are a cost the company can well afford to bear?
  • What if knowledge is not a competitive advantage?

In cases like this, Knowledge Management can be a distraction.

Here are a few cases where KM is not necessary

When you have a structural monopoly that will not change

Imagine you are the sole player in a field, with no competitive pressure. This is a great position to be in - no matter what you do, your business is assured. There is no need to learn, no need for change, and no need to manage your knowledge. You can make as many mistakes as you like.  This is a nice position to be in, but difficult to imagine in any non-communist countries.

When your entire staff are manual workers

If you have no knowledge workers in the organisation, then you have no need of knowledge management.  I must admit, it is difficult to think of an organisation like this - maybe a company that does mobile carwashes in supermarket carparks, perhaps? Even then there might be a knowledge worker or two in the organisation somewhere.

When your company is very small and unlikely to grow

If your company is small enough to work in a single office, if you talk together all the time, and if your document filing is very good, you may do enough informal knowledge sharing not to need to formalise it. 

When you are an individual, making a living based on skill

A concert violinist, for example, is unlikely to need knowledge management, beyond having a good mentor and teacher. Musical performance, or solo sport performance is more a question of skill than of knowledge.

I am sure you can challenge each of these cases, and you may be able to suggest other cases where KM is not needed.

For most other organisations, which is to say almost every other organisation in the world, where knowledge is an asset and where there are knowledge workers in the organisation, then  Knowledge Management is a value-adding discipline.

Friday, 25 September 2015

When Downsizing becomes Dumbsizing

Downsizing is a popular response to commercial pressures on a company, If they want to improve the look of their balance sheet quickly, they reduce their payroll costs. But all too often, downsizing leads to dumbsizing. 

Losing people is an attractive short term option to the finance department - its quick, you can cut a lot of cost, and you (in theory) end up with a leaner and meaner organisation.

However when the people you lose hold most of your organisational knowledge (which often happens when you cut higher paid jobs), you lend up with a leaner, meaner and dumber organisation.

This is known as dumbsizing.

This article contains a couple of good examples of dumbsizing, including this one

Circuit City downsized 3400 of its highest paid (and probably most effective) sales associates in an attempt to gain sustainable cost reductions. The remaining smaller, less skilled sales force provided competitors such as Best Buy with an opportunity to gain market share. Once in this spiral, Circuit City could not prevent the hemorrhage of clients and revenues. The company filed for bankruptcy in 2008 and finally ceased trading in 2009.

Terminal dumbsizing.

Employee downsizing, when applied indiscriminately, runs the risk of undermining sustainable competitive advantage through deteriorating quality, productivity and effectiveness as a result of knowledge loss.  In many cases, the only way for the companies to recover is to hire back the people they fired at a premium cost, as in this example.

Charles Schwab Corp. provides us with a crisis-induced reaction in the aftermath of the dot-com crisis at the beginning of the new millennium. After two rounds of employee downsizing, the company offered a US$7500 bonus for any previously downsized employee rehired by the firm within 18 months of the layoffs.....  A survey by the American Management Association (AMA) revealed that about one-third of companies that lay people off subsequently rehire some of them as contractors because they still need their skills.

The problem comes when organisations look only at the cost of the people, and not at the value of the knowledge resources they hold. Downsizing is not considered in the light of the organisational knowledge management strategy (assuming they have one), the risk of critical knowledge loss is not considered and managed, and core capability declines as a result.

The company becomes dumb and dumber, and (like the Circuit City example above) may become no longer viable.

Thursday, 24 September 2015

FAQs in KM - a form of pseudo-dialogue

I have often posted here about the power of dialogue in knowledge sharing. But how can you have dialogue with written knowledge?

Dialogue is a form of conversation in which the participants are trying to reach mutual understanding. It is a process of exchange of views and of knowledge, of both sides asking questions and of listening to the answers. It is a combination of listening, advocacy, reasoning and consensus-seeking. Dialogue means "talking it through."

It is hard to imagine effective knowledge exchange without some form of dialogue. What really differentiates dialogue from other forms of communication such as debate, argument or briefing is that both parties are seeking to understand, and asking questions.

And when you ask a question, your mind is open to the answer.

That's not true when you are debating or arguing, or even listening to a briefing, The very act of questioning opens the mind.

So what about written knowledge, where you can't engage in dialogue?

Enter the FAQ - the Frequently Asked Questions list.

You see these everywhere (see for example our Knowledge Management FAQ). They are popular ways of offering knowledge, by producing a list of questions (sometimes "frequently asked", sometimes "most important" questions) and providing the answers. Some people argue that they should be caled "Frequently Given Answers".

FAQs are like pseudo-dialogue. 

Although you cannot question a document or a webpage, the FAQ provides the next best thing. It allows the learner to scan the list of questions to find the ones they would have asked in a conversation. Although reading the answer to a listed question is not as mind-opening as asking the question directly, it is a step in the right direction. They give the reader at least one small way of influencing the way they learn, and finding teh answer they are most interested in.

In fact the FAQ list has an advantage over face to face dialogue, as they provide the learner with questions they might not have thought of asking, and therefore answers to the things they didn't know that they didn't know.

There are some cases where dialogue is not needed and FAQ is not appropriate, for example when the context of the knowledge is very clear, or the nature of the knowledge is limited. See for example this blog post from the government digital service.

If you are in doubt about whether to package your knowledge asset as an FAQ or a set of instructions, then ask yourself this question....

Will people come to your knowledge asset be told, or to find out?

If the former, then give them instructions. If the latter, then use an FAQ.

Blog Archive