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."
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.