Using Wikis for Internal Documentation

Documenting your organizational procedures can be a big help, but this information often languishes in obscurity and goes slowly out of date. Jeremy Wallace talks about how wikis - easily editable websites - can help.

Most organizations have (or at least should have!) internal documentation that outlines procedures, best practices, and tips to help make everyone’s job easier. For instance, an organization might write up:

  •  How to add a new constituent to the tracking database, or how to send an email newsletter
  •  The steps to follow to request office supplies, or to get ready for a new staff member
  •  The thought process that went into a complex set of decisions
  •  A list of local take-out restaurants, or good hotels for guests

This type of documentation helps train those new to the organization or to a role, saves staff time in the long run, and can save your skin if you (like many nonprofits) have a lot of employee turnover.

Unfortunately, creating this documentation is seldom a coveted task. It often goes unwritten—or once it’s written, it languishes in obscurity and slowly goes out of date.

But what if you could share the work of documentation across all those that need to use it, and slowly build up a central repository of how-tos over time? What if your staff could easily make updates as soon as they discovered something out-of-date?

Wikis can help. A wiki is a collaborative website that allows any authorized user not only to view information online, but also to easily edit the text of each page. Wikipedia is likely the best known example of a wiki, but many organizations and companies are also them to manage internal information. For more about the basics of wikis, see TechSoup’s article Exploring the World of Wikis

Wikis have a number of advantages. Because they are flexible and easy to edit, you can create information in the format that is most likely to be used and updated. And as with any online application, your staff can access them from anywhere they have an internet connection.

Though you will probably want to keep your employee manual—and anything else that lays down official organizational rules—in a form that is not so easy to update, a wiki can be a great help in creating and maintaining less sensitive information. In this article, I’ll take a look at the strengths and weaknesses of wikis for documentation, and some of the things to consider as you look for one that can help your organization.

Why a Wiki?

Like any other type of software package, wikis have both strengths and weaknesses. First off, because wikis are web tools, they have all of the advantages and disadvantages of any other web application: you can use them anywhere in the world, but only if you’re connected to the internet (or at least to your internal network, if your wiki is for office use only).

Because wikis are online, distribution is a snap. There's no need to update printed employee guides, or ask employees to delete out-of-date files from their own computer. As soon as you update the wiki, everyone, everywhere in the organization, will have access to the latest information. It's also easy to search this online information - instead of having to figure out which printed document or Word file contains the needed information, staff can search across all the wiki documentation at once.

Wikis are also flexible. Staff members can add a new page—or a new how-to—at any time. Navigation can be a simple list of available pages, a more complicated hierarchical structure, a complex cross-referencing—or all of the above. But flexibility poses challenges, too: a wiki can gradually turn into an unfriendly tangle of links, as staff add new pages and topics. So it’s important to define a workable structure at the outset—and encourage staff to stick to it.

A wiki is just a web site, and most people will be comfortable consuming the information—just click a link, and read. But unlike a typical website, most wikis allow any reader to edit the page they're reading. With one click, they can navigate to an “edit” view of the page, update the text, and click to publish it. This can be a huge advantage in making small updates—if it’s easy to make a small fix, staff are more likely to just go ahead and do it.

Although techies generally find wikis easy to use, others may take a little while to warm up to them. The ease of formatting the text varies from one wiki tool to another. Some allow text formatting with a familiar graphic interface, while others require arcane text tags (for instance, asterisks to indicate bullet points, or surrounding text with _ characters for underlining). There can be psychological hurdles as well. We are so used to viewing web pages as things edited by someone else, or via a complex process, that it can take a little while for staff to get used to the idea that the web page they’re viewing now is a little more like a word processing document.

Which Wiki Will We Want?

There are dozens of affordable, widely used wiki platforms - these tools are often called wiki engines. They range from free, open-source tools like MediaWiki (the engine behind Wikipedia) to commercial, enterprise-ready solutions such as Confluence. With so many wiki engines out there, how will you decide which one to use?

Start by spending some time considering how your wiki will be used, and by whom. Will your users be highly tech savvy, or just barely comfortable with computers? Will you be opening your wiki to the general public or will this be something for internal use? Will some sections of the wiki be more locked down than others? What is your budget? (Many wikis are free. Some cost over $1,000!) Do you have someone on staff capable of maintaining a complex web application or will you want an outsider to take care of these tasks? Is it important that staff are able to print out sections of the wiki as one continuous document?

Once you have the answers to those questions, you can start the process of comparing wikis. What should you look for? Obviously, your specific needs may vary, but there are a few key things to consider.

Hosted or Installed

If, like many small non-profits, your organization is starved for people with technology expertise, you’ll most likely want to use a hosted solution. With a hosted application, also known as Software-As-a-Service, the company that makes the wiki engine will keep their software and your text on their own servers, and you will simply access it like any other web site. Some hosted plans are free and some cost as much as $50 per month.

If, on the other hand, you have someone on staff with sufficient web technology skills, and with enough time to manage one more web application, you may want to download the software and install it on your own server. Many of the wikis you can install are free, but some cost over $1,000.

Tools for Editing

As I briefly discussed above, wikis generally let you edit the information on web pages in one of two ways. Some allow you to use a WYSIWYG editor like that in Microsoft Word, which allows you to click a button to make text bold or italics. With this type of editor, your view of the text while you're editing is more or less the same look as what the all the readers will see.

Without a WYSIWYG editor, you’ll instead need to use what’s called a markup language. A markup language allows you to do some fancy formatting of your wiki pages, using only a text editor. This involves tricks like creating bulleted lists by putting an asterisk at the start of each line, typing h1., h2., or h3. to format different levels of headings, and surround text you want underlined with _ characters.

An in-between solution is an editor with shortcut buttons like a WYSIWYG editor, which generates markup language. You can still click a button to make text bold, but instead of seeing the text instantly become bold on the page, the selected text is marked off *with asterisks, like this*. This can allow beginners to edit pages while helping them learn the basic markups.

Though most markup languages are fairly simple, and the best ones are extremely easy to use, not everyone will be comfortable learning something like this just to document the way their organization files its purchase orders. Most wiki engines either have a WYSIWYG editor built in, or one that can be added on. Almost all wikis will let you use a markup language. If your user base will be on the less technical side of things, prioritize a WYSIWYG editor in the list of features you look for in a wiki engine.

Files or Database

Some wikis store each page as a separate text file, while others store them as records in a database. If you are using an installed wiki engine on your own server, a file-based wiki may make backups easier—you can simply make a copy of the directory that holds those files and you’ll be all set. But a wiki that uses a database to store your content will make some key activities (like renaming a page after it has been created) a lot easier.

Subscribing to Changes

Email notification—the ability for a user to sign up to receive a message every time the contents of a page (or even an entire space) are changed - can be a powerful feature, but not all wikis offer it. Some wikis also offer an RSS feed of changes, for those that prefer to receive information to a feedreader like Google News or Bloglines rather than to their email inbox. Either of these notification methods can be particularly useful to allow nervous documentation owners to review every change, if they want.

No, Really: Which Wiki Will We Want?

Well, I can’t say that I’ve spent significant time using more than a handful of wiki engines, but I'm familiar with MediaWiki , DokuWiki, PhpWiki, and Confluence . For my needs, Confluence is the clear winner—it’s got an extremely clean look, is absolutely packed with features, stores content in a database of your choosing, and has a dead-simple markup language. Confluence costs $1,200 for an installed version or $50/month if they host it, but non-profits can get it for free.

One thing the other three offer that Confluence does not, though, is open source code - the ability to freely update or distribute the code in most any way you like. Though you can get your hands on their code if you actually pay for Confluence, you cannot re-use the code in any way other than modifying your version or contributing macros and bug fixes to the Confluence community. The other three all use versions of the popular GPL open-source license and are supported by large, active communities of open-source developers and users.

 

All four of these wikis require expertise and access to a server to install. To get started quickly and with minimal technology overhead, a hosted solution may be better. Two popular hosted wikis are PBWiki and Wikispaces, both of which have a free version with some limits. An upgraded Wikispaces account is available to nonprofits through Techsoup Stock . Google has recently released Google Sites as part of its Google Apps suite, based on the Jotspot hosted wiki service that they acquired. If your organization is already using the free nonprofit edition of Google Apps, Google Sites is an easy way to get started with a wiki that will be integrated into your other Google Apps services.

Don't forget to consider the software you already have, either: if you're using a higher-end content management system to manage your website, like Plone or Drupal, these systems may also offer strong, wiki-style collaborative documentation features.

 

For more wikis, and much more information, WikiMatrix.org will let you compare a hundred or more different wiki engines. Each wiki is rated on over 100 features. As with any software application, different wikis will be more or less appropriate for different uses.

Getting Started

Once you’ve chosen a wiki engine, you still have a little work to do before you can start writing your pages.

If you want, you can certainly make your wiki open to all comers, like Wikipedia and WikiHow. However, your organization’s procedures, while likely not top secret, are probably something you’d like to keep reasonably private. It’s easy enough to lock down any wiki in its entirety. The real security question to ask yourself, though, is how granular you’ll want your security controls to be. Do you need to be able to lock down individual pages? Do you need security groups, which will enable you to change security settings for a bunch of users at once?

It’s important to define who will create and maintain the wiki information – your documentation. You can, of course, have one person at your organization create all of the content. However, that would ignore the strongest offering a wiki has: the ability for a group of people to collaborate on the creation of content. Letting a larger group create content doesn’t just spread the work out among more bodies— it also allows you to take advantage of more brainpower.

Although it’s a good idea to have as many staff members contributing content as possible, it’s best to choose one person to oversee the organization of the wiki as it grows. This will be an ongoing, active role—your original outline will be a good start, but because wikis allow many to contribute, things will tend to stray from the plan from time to time. The person who does this work, trimming one branch of content, planting the seeds for what will turn into groups of pages on particular topics, is called the wiki gardener . Really!

The last thing to do before opening the floodgates to the whole organization is to ask a small group of people to create as many pages as they can—seeding your wiki with a few dozen truly useful pages will go a long way toward convincing the rest of the team that your new wiki is an important place for both gathering and sharing knowledge.

In Summary

While there are certain challenges you’ll face in using a wiki to document your organization’s practices, there are also huge advantages, both technical and psychological. With careful selection of the proper wiki engine and some good planning, a wiki can help bring teams together, get new team members up to speed more efficiently, encourage staff to contribute to the community of your organization, and preserve critical organizational knowledge.

Done right, an organizational wiki will become the first place your employees turn when they have a question about how to perform a task, or when they have information – whether an update, a quick tip, or a how-to guide – they want to share.

 

Jeremy Wallace has worked with both non-profits and technology since 1995, mostly focusing on databases, though lately he's gotten the impression that the internet might just take off,and he has started helping non-profits with their web needs. He has worked for TIAA-CREF, the Fund for the City of New York, the Center for Family Life in Sunset Park, the Education Trust, and many non-profits as an employee or contractor. Jeremy is currently a project manager at PICnet, is the Director of Operations at Writopia Lab, and still keeps his consultancy alive at ABCDataworks.

Many thanks as well to Jon Stahl of ONE/ Northwest, Thomas Taylor of the Greater Philadelphia Cultural Alliance , Clark Williams-Derry of  Sightline, and Laura Quinn of Idealware, who also contributed to this article.


 

 

License: 
Copyright Idealware. Licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License

Comments

media wiki for internal documetation

This is an exelent idea. 
I moved ito an organization about nine years ago that was using media wikis for both Admins and "public" or normal users on a closed loop classified network.  This is a great way to make a serchable refrence recouce that is quik and easy to update.  We use is extensively for our administrators to share how they fixed a problem, and to just take notes on a how to configure stuff.  This also works well for creating a set of documentation for stuff that the users should be able to fix on their own.  It is very easy to document as you go, to keep information availble to your team and workforce.  Informatioin is power, make it accesable. 

 

 

 

 

Wiki at work

 

Normal
0

false
false
false

EN-US
X-NONE
X-NONE

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}

After reading your overview of how wikis can assist working groups, I am convinced wikis are a  workplace  must. The inherent attributes of wikis enable organizations to keep relevant and catalog progress instantaneously. Specifically, when you mentioned employee manuals, I immediately thought of our standard operating procedures and how wikis would enable real-time maintenance. There are constant policy changes and updated memorandums for  record in our line of work and continuity is a constant challenge. What exists is a dropbox of files added by multiple users over time. It is absent of any current central reference. Users waste time and effort seaching through the plethora of files. Having read your brief introduction to the world of wikis, I am inspired to propose converting our overcrowded and out-of-date shared portal to a workplace wiki.  Whereby users edit one congruent wiki rather than dropping files into a drive, I am looking forward to a more reliable, up-datable central reference.