Tip3: Populate it and they’ll come.

June 1st, 2010

Put content on the wiki; direct people to it using email.

This tip seems a bit counter-intuitive. I mean, that sentence originates from the "Build it and they will come", which has become somewhat of a sarcastic statement. And that also the way the authors meant it. You need great content, that's for sure, but you need to open people's eye to where that content is.

Email is your friend

We've said on many occasions that whatever get's emailed to more than one person, is a candidate to be put in the wiki. So why use mail as your friend? The big difference of course between mail and wiki pages is the push and the pull mechanism. An email is really pushed in the person's inbox whereas the wiki page needs to be navigated to. Because people like short and clear emails, concentrate the gist of what you want the recipient to do with it (understand, take action, remember,..) in the email body, but the background is pointed to by an wiki url.

Topics you can offload from an email to your wiki are: attachments, process descriptions, specifications, and so on. Things you would need to remember or that you want the team to remember.

Your cunning plan

You could of course make the wiki so content rich and so well structured that people can simply not ignore it. Once all the collective team knowledge is in a wiki and that wiki is well structured and easy search-able, you will find that no decision can be taken without consulting some of its pages. The cunning plan is to make the wiki the sole place where up to date information can be found. Archive folders that contain useless and outdated stuff, publish updates of once used files and network locations on wiki pages only. Soon you will see no one can ignore the wiki.

Baseball field from 'Field of Dreams'

The baseball field in the picture above comes from "Field of Dreams", a 1989 American drama sports film. In this film, Ray Kinsella (Kevin Costner) is a novice farmer who lives in rural Iowa with his wife, Annie (Amy Madigan), and their young daughter Karin (Gaby Hoffmann). While walking through his cornfield, Ray hears a voice whisper, "If you build it, he will come" (often misquoted as "If you build it, they will come"), and sees a vision of a baseball field.

Tip2: Throw out the rule book!

April 28th, 2010

Don’t start with a lot of structure and rules. Make a wiki available, then see how people use it, and grow accordingly. Follow the lead of the people using it – that’s at the heart of how social software works!

This tip goes to the heart of what the web2.0 movement is all about. Everybody is contributing. In this way, the result is better than what you would ever get when you tried to enforce it to your team or department.

It is not really the absence of rules that constitutes to the success of a wiki, but the freedom that people feel that they can take part in it when and how they want.

Why does 'absence' of too many rules gets teams on average to a better result? What motivates people to take the time to enter a new wiki page or to amend an existing one. In general because they feel that is something they ought to do.

Revisions, the feature you need but will rarely use

The single most important feature that explains why you don't need too many rules is the wiki's revisions system. Everything that was ever there, good or bad, is remembered. And is there for everyone to see. I have seen only on rare occasions that somebody had to revert to a previous version because somebody messed it up. People just need to understand that that feature is there. This understanding will keep them from spamming the wiki or getting engaged in some foolish escalating correction upon correction game.

The question of motivation comes back later, when we will try to understand what it is that makes people wanna come back to the wiki to make it better.

Page templates should help, not enforce

A word of caution about page templates. These templates are available when pages of a certain type are created. These should not be viewed as "fill in all the boxes on this form, or else it is invalid". Rather it should help new page authors structure the information on the page so that some kind of uniformity is reached. Rather use templates to assist on what kind of content is typically provided on a page of that nature.

I don't know where we are going, but we are getting there very fast

This is a slight exaggeration of course, but there is some truth in it. You may know where you start with a wiki, but you will need to have an open mind to see where people take the wiki. Don't try to limit the use of your wiki when it goes into a direction you did not anticipate. When the team decides that they need content on a topic, try to understand rather than to stop it.

Tip1: Grassroots approach

April 7th, 2010

Start bottom-up, to build the ownership.

Tip 1 in the article "Top 10 Organizational Wiki Tips (and how to use them)" on http://www.ikiw.org/2008/01/21/top-10-organizational-wiki-tips-and-how-to-use-them/ says "Grassroots is best. Start from the bottom-up so people build a sense of ownership of their wiki contributions."

Grassroots image, just for fun

There are many sides to this tip. Typically wiki usage has come from the tech community in a company. It's the project leader that throws some stuff on a wiki and some software developers begin to add content to it. With some luck (and the right company culture) you may get the unit managers and business people on it. Rarely you will get sales or account managers on it. (Those you typically won't get on any system.) I have recently come across someone who succeeded in introducing it up to the VP level. But he hastened to add it had took the company 6 years before reaching that level of adoption.

You don't need to start in the IT department

With WordonWiki, we can work on multiple targets. Any part of the organization that has some content to be shared like background information, business processes, policies and even modest knowledge bases can benefit from the virtues of a wiki. We can finally break away from the software development background. One of our successful implementations started from a sales support department. This company has a need to share the process information needed to get support the sales department in creating complex proposals. Only later the wiki was also used by the IT department.

One important topic you may not loose sight of, wherever you start from, is the "ownership". People need to feel they 'own' the wiki content. It are their attachments, word documents and other mails that finally can go to the wiki. 

How to increase wiki adoption?

As a teamleader or unit manager, these are some things you can do to get the wiki more easily adapted:

  • When you get an email from a team member with an attachment, asking for feedback, send the mail right back suggesting to add it in the wiki so everyone can give feedback.
  • When someone comes and ask how something should be done, refer to the wiki. If that particular piece of information is not there, propose to add it to the 'Processes' or 'Knowledge base' section.
  • If you got a team meeting and some team member asks a question about some topic that others seem to know from the top of their head, always ask: "Could you have found that in the wiki?". If so, tell the person to search for it next time. If not, ask the person who knew that particular bit of information to put it there.
  • Builders that are about to start constructing a house, always take a day or two to 'prepare the site'. Many things need to be set up that will make live so much simpler when the actual work starts. Projects with less tangible results would also be helped by this 'prepare the site' phase. A wiki can be one of the first actions you should take. It can be initially as simple as 1 page stating the project's high level goal and due date. Get people around a table, put on an overhead projector and start editing the wiki with everyone around the table. Build a list of topics you and your team members will need to think of. Quickly turn these links into new pages and start filling in with the details of the first level detailing

Please post replies below if you got other grassroots approaches that have helped you.

You can't be fired if you choose for these 10 wiki introduction rules

March 31st, 2010

The article "Top 10 Organizational Wiki Tips (and how to use them)" is already some time out there, but it has become somewhat of a special guidance to us.(See http://www.ikiw.org for more fine content on wikis)

In 10 points the do's and don'ts of introducing a wiki are clearly laid out. Introducing wikis can be darn hard, but also amazingly simple. If you don't do anything else, follow at least these rules. There are little other things that are not covered by them.

In the following set of articles to be published over the coming weeks, we'll be highlighting some of the pitfalls and advice we've learned the hard way.

Summarized the wiki tips revolve around following principles:

  • Lead by example. Relentlessly put content relevant for your organization in the wiki. Mail references to the wiki to everyone.
  • It's better to have an unstructured, unfinished page in the wiki about a topic than to have nothing at all. Mark text to be completed as 'to be completed...'
  • Know you are in for the long run, you'll get it up and running in a matter of months, not weeks.
  • Let the social aspect work, your wiki should not be something only you can write. Put incomplete sections in there that team members will need to complete. Give 'write' privileges as much as possible

Watch this space for more information in the coming weeks.

Attack the collaboration emails

March 11th, 2010

I've seen on many projects how email communication is still the number 1 choice when it comes to online communication. The gigabytes of requirements, specifications, meeting minutes, user documentation, test cases send in emails must be staggering.

Yet it is probably one of the least effective forms of communication. It can get lost, you never find it when you need it, you're never sure who has the last version. I have done my fair share of consolidating feedback from multiple sources on the same document, only to find out that after I finished, there was another feedback with revision marks in my inbox.

The wiki page == the document == its url == its history

The key thing that makes wikis what they are is the simple truth that there is no other instance of the wiki page than the one pointed to by it's url. So project team members and the organization's management can only mail a pointer to the thing, not the thing it self.

How to set up a wiki for a project?

The most basic partitioning you can do is divide your projects into areas, each with its specific features, audience and content. I have see following categories in the more successful project wikis:

  • Customer information
    All that is linked to the customer, contact persons, contracts, security guidelines.

  • Team information
    Who is who, skype id, msn-names, mobile numbers, flickr user name, whatever topic you are unlikely to find in the company address book.

  • Project requirements
    The heavy stuff: requirements, specification, PID (Project Initiation Document), ...

  • Test, Deploy and Build
    In case of a software development team, how to build the software, prerequisites, steps to go through, automated or manual tests that need to be checked of before shipping.

  • Meeting corner
    One page per meeting type works best. E.g. list the weekly team review meetings on a page with the same name. The do's and don'ts on this meeting are consolidated on the summary page.

The idea to put up the spaces like this is that each question that arises is sure to fall into one of these categories. I am sure you get the idea and can come up with what you would list there.

To get the ball rolling and to kick some *ss, what about following, let's say, less likely choices:

  • Famous quotes page
    Posted by anonymous, to embarrassing to tweet, yet to memorable to forget.

  • Team member's bio page
    In this way you'll be sure there's at least one page written by everyone on the team.

  • Team Propaganda Corner
    The rules the team decides on should be listed in slogans on this page. Learnings that the team came up with, crucial customer feedback nobody should forget, the team's quality or productivity dashboard indicators go here.

You'll never return to email...

...when this is set up. You will need to do some selling, hard, relentless and sustained dedication is what it takes to get the content ball rolling. We hope that the tips above will help you get started.

Some interesting links