4 myths of the Enterprise wiki

An article from 2009 gives us 3 reasons why wikis are not the easy route to KM that many believe. I have added a fourth

This comes from an article in pcworld based on a interview with Danish Analyst Dorthe Jespersen. Dorthe’s believes that the organisational culture can be a real barrier to the adoption of wikis, and the idea that wikis will allow knowledge to spontaneoulsy emerge, as on Wikipedia, is unfounded.

Her three myths are as follows

 Myth One: Wikis will motivate employees to contribute content. 
 Jespersen describes the “Empty wiki syndrome,” or when a wiki is deployed without a clear purpose or is too general in its focus, resulting in a site with almost no activity. It helps, said Jespersen, to appoint someone to manage the wiki, ensure there is structure like guidelines and a basic information architecture, and that it is launched with content already posted because “it’s very hard to just react to this empty space for the user.”

 Myth Two: Employees know how to contribute. 
 The concept of a wiki may be simple, but contributing content is not necessarily logical for casual users. Jespersen said some organizations prefer to refer to existing written policies around content creation that say, for instance, employees are responsible for the content they produce. But policies can be tricky considering the goal is to strike a balance between governance and structure and flexibility. Some wiki-specific policies might include guidelines around creating pages that are easy to read by having a table of contents if the page is long, or having a naming system for links to ensure consistency. 


 Myth Three: Wikis will always provide the information employees need. 
 Although searchability is often a selling point of wikis, Jespersen said the reality is wikis are difficult to search through, unlike a content management system. Given there is little structure built into wikis, “it is difficult to structure this information to make it findable the next day even.” Content on a wiki can grow faster than the organization can keep up, she said, therefore the wiki managers must perform regular searches and quality checks of the content. Overall, Jespersen suggested starting with a pilot so that the true purpose and scope of the wiki can be first ascertained before an enterprise-wide launch.

Underlying all of this is a fourth myth, which is still prevalent, and which I feel should be added to the list:

Myth Four: Wikipedia is a good model for in-house Wikis

Wikipedia is the archetypal bottom-up Wiki, drawing on the wisdom of the crowds, and is often taken as a model of bottom-up voluntary free-form knowledge sharing. However it is a poor model, for several reasons:

  1. Wikipedia is successful because it draws on a huge crowd – the population of the globe. even though the percetnage of Wiki contributors compared to teh global population is tiny, that doesnt matter because the global population is so large. A similat tiny percentage in an organisation would mean that a very small number of contributors provided the bulk of the content.
  2. That tiny percentage of Wikipedia contributors is a skewed population.  Wikipedia contributors are 80-90% male, more than 65 percent single, more than 85 percent without children, around 70 percent under the age of 30. This is the wisdomn of a subset of the crowd. You do not want this skewed viewpoint in an organisation. 
  3.  Editing wikipedia is not a case of “everyone writes what they like”. There is usually editorial overview or moderation of most pages other then the fairly niche ones. A similar form of editorial oversight is needed in organisations as well.
  4. If you want more advice, see NASA’s 6 wiki rules
  5. This video….

View Original Source (nickmilton.com) Here.

Knowledge Assets – the "Knowledge First" format

The way we write reports, especially scientific reports, is not the way we should write Knowledge Assets in a Wiki.

Image from MaxPixel

I am consulting with a firm which is moving much of its current knowledge into wiki format, on order to take it out of the document library and to turn it into a resource that is in the public domain, searchable, hyperlinked, and constantly updated.

The problem is that many of the knowledge owners are scientists, and their default knowledge format is very much based on scientific reports. Many of their first-attempt wiki pages are composed as follows:
  • List of projects:
    • Project title
    • Project outline
    • Project objectives
    • Project results
    • Project conclusions
The conclusions are where the knowledge is found, and presenting it in this way means that the reader must scroll to the bottom of the page every time to find the knowledge, and that the reader must read every project to get a full picture. Also the knowledge is not updateable, as it is linkedin every case to a project.
We are now moving the content into a “Knowledge First” structure, as follows:
  • Here is what we currently know about this topic (knowledge summary or conclusions);
  • This knowledge is based on the following projects:
    • Link to first project, with full details;
    • Link to second project, with full details etc;
  • Here are the things we still don’t know, abut are trying to find out.
The links to projects could be hyperlinks to sections further down the page, to separate project summary pages, or even to the project reports in the document management system.

This less like the way knowledge is presented in scientific reports, and more like the way it is presented in newspapers; starting with the headline, then the introductory paragraph which summarises the whole story, and then “read on for more detail”. It is a reader-driven format, aiming to give the reader what they need to know in the most efficient way.

By presenting the material in this way, the reader can find the knowledge quickly, and then zoom in to the level of knowledge they need.  Also any update to the knowledge happens at the top of the page, in clear view, and any old, invalid conclusions can be overwritten.

Format your knowledge assets and wiki pages with the user in mind, and think “Newspaper format” rather then “Scientific Report”.

View Original Source Here.

Skip to toolbar