How to start with Wiki Culture

30 Oct 2013 5 min read

Here is the fifth article of our series of articles, entitled "How can the wiki culture change your business".

How to start

Applying the Wiki Culture in your enterprise is easier said than done. Many wikis have failed by being too rudimentary or when employees hadn't been explained how to successfully use the new tool.

There are a few steps and requirements that are needed to achieve Wiki Culture in your organization:

New Generation Wikis

First, from the tool perspective, it is important to chose a tool that is adapted for enterprises. The Wikipedia software for instance, is made for Wikipedia, not for companies.
It is important to have additional features that are necessary for the enterprise, for instance: a Wysiwyg editor, PDF export, rights, file attachments, structured data and many others.
Flat document editing in Wysiwyg can also use macros to embed any type of content with a relevant presentation (a Powerpoint presentation can be embedded in a page or a business intelligence report coming from an external database). 

It is particularly important to provide a semi-structured document approach that allows going beyond the flat text document and provides additional and convenient ways to navigate data.

Semi-structured Documents

Traditional documents are flat text documents with no structure. Unfortunately this does not allow you to navigate through content of the same type. Suppose you want to share project information. It is important to know if the project is active or not, who the project leader is, the size and the duration of the project. It will be interesting to link other pieces of information to these projects. If you use a flat document, you are not sure users will fill in the needed information and even if they do, as the information is buried in the document without structure, you won't be able to navigate using this information.
If you use a spreadsheet to list your projects, it is hard to have complete content, to link to other documents (like specifications, documentation). Additionally you won't get a history of the changes related to the information concerning one project, but the history of the whole spreadsheet file.

With semi-structured documents, users can define the proper structure for their documents, which makes it easy to fill in the project information, while not limiting flat content and still keeping a wiki-style history for all document changes. And thanks to the structured information it is possible to create a better navigation of the project information.

Semi-structured documents are key to a successful information organization inside an enterprise, which is still simple enough to allow users to participate to the design of the structure.

Which team and content to start with

When setting up a Wiki, you need to keep in mind that you will need to convince your users that the change is beneficial for them. Your tool will compete with their personal productivity tools.
Therefor you need to chose your initial team and initial content in a way that will maximize the perceived value for users.

For instance you can choose a team that is particularly motivated to work together, a team with little internal tensions. On the content side, you should choose some existing content that is important to that team, but that is not efficiently accessible, although users need to regularly access it. 

Empowering users

Giving users the possibility to create their own organization and their own structure is very important. Teams should be able to create their own workspace in which they get control on how the content is organized.
Using simple tools, users should be able to create custom data structures which mater to the team. These structures will ease the creation of content which will also be more organized when displayed to all consumers (inside or outside the team).

Initially only one team will start by creating their data structures, most other teams sticking to the standard content sharing features (files, wiki pages, links).
The first applications created that are complete and better organized will serve as an example for other teams. Other teams will ask questions about the early adopter team's application and will want to be taught how to achieve a similar result. 

You can provide some support to help these first experiences and encourage other users to be coaches so that they show newcomers how to efficiently use the tool. When some valuable applications are added, you can decide to invest more in them using custom development to improve the result.

Month after month, more content structures will show up that are directly created by the users themselves, users will help each other and learn from one another.

Ludovic Dubost
President & Founder

You may also be interested in: