Disclaimer: I am no Wiki expert, the below article reflects my experiences of Wiki adoption within the enterprise.

Update October 2008: I just recorded a podcast where I talk about each of these tips. If you are interested, check out the Instantiate Aussie Tech Podcast – Episode #1

At my current work I’ve had the privilege to administer a Wiki which one of my good friends put in here a while ago. The Wiki we used was primarily for our small team within a very large organization (thousands of employees). It was setup for our team to collaborate, share thoughts and retain IP. Working in IT, most of the information we had on there was related to systems, projects or other techy kind of stuff. As someone who worked in production support, the Wiki was like stumbling across gold. It empowered us to respond to incidents quicker, document and retain knowledge of specific systems or processes.

I’ve been amazed at the growth patterns that I have observed with our corporate Wiki. Its essentially grown from 30 to 550 users in less than 12 months. Our user base has grown from just IT into all our business units. Its growing at an average rate of 18 new users per week, hundreds of page views per day, and averaging around 45 contributions (new content or edits of existing content) per day.

The other thing that stood out was our contribution percentage. The contribution percentage is a percentage figure that tells you given the total amount of users you have registered, how many actually contribute. I had read theories that suggested wiki growth is generally quite slow, and is initially built on a small number of people contributing. For example, the 90-9-1 Theory:

The 90-9-1 theory explains the percentage of a wiki’s participation, breaking it down as readers being the highest percent, with minor contributors composing the 9 percent and enthusiastic and active contributors composing 1 percent of the total participants in a wiki…..
…
When studied, it was found that user participation generally follows a 90-9-1 Rule:
* 90% of users are “lurkers” (i.e. they read or browse but don’t contribute)
* 9% of users contribute from time to time, but other priorities dominate their time
* 1% of users participate very often and account for most of the contributions
Source: Wikipatterns

Whilst this theory was valid for the first few months of our Wiki, I’ve come to find that is no longer the case. Around 40% of our total users contribute and 60% are, what you could call, ‘lurkers’. Out of the 40%, my estimates would be 20% of those users would participate very often and 20% on an irregular basis. Our Wiki statistics also help tell us something with regards to user contribution. If I look at our top wiki contributer stats – it changes every month with someone different.

You often hear how ‘Enterprise 2.0 Adoption‘ is generally much slower than the ‘Consumer 2.0′ adoption. Whilst that is defiantly true, there are many ways that you can speed Enterprise 2.0 adoption within your workplace. I had read lot about Wiki adoption techniques, and there are some great resources out there. One which I got lots of ideas from is Wiki Patterns. It is a great resource. Check it out. There are many other resources that can assist, which I will mention at the end of this article

So what’s worked for us? I’m not too sure if I can pin it down to just one or two key things. Many factors go into something like this getting off the ground. Below is my small list. It’s a summary of what I’ve seen and learned along the way of Wiki adoption:

1. Pick a good Wiki
The product has to be functionally good. Might not necessarily visually be the best, but functionally. Don’t think you have to spend too much time on this. A couple of things to note about good Wikis:

All good Wikis will let you ‘port’ your data into another product

All good Wikis have, to some degree, for ’self-serve’ support (You don’t want too much manual intervention in getting users contributing)

All good Wikis have API’s. A must if you plan to integrate it with other products, or want to do stuff with it. (Eg Write scripts to automate documentation of application builds)

Given that are many wikis out there that are extremely cheep and a lot are actually free – don’t spend too much time over analyzing Wikis, just ensure it has all the important stuff. Ensure it meets your basic functional requirements – as many wikis will have many ‘extra’ features you wont necessarily use. Just get what you need.

If I had to recommend you one for the enterprise, we use Confluence as our Wiki, by the guys at Atlassian. Its by far the best and most extensible Wiki software I have ever used. If you don’t believe me check out the others and try it yourself.

2. Let your Wiki ‘virally’ grow
Similar to the likes of Gmail, and its success, letting something grow virally can be a good thing.

It’s amazing what people do when they find out they can get something for free! We promoted the Wiki as a free service provided by our team. To get a new team started on the Wiki, we made the customer contact an administrator and request to get a space created for their team. Why didn’t we allow them to create spaces themselves? We did this because it allowed us to control at a very high-level the structure of the Wiki – so it was easier to find stuff. We followed a convention for setting up teams. Within a period of a few months, we would often get several requests of teams calling up or emailing saying ‘Hey, I heard you guys have a Wiki, and its free – can I use it?’. We would then setup a space for their team, and they would get started straight away.

We didn’t have a ‘formal process’ for doing it – it was just email or call us, and we will give it to you on the spot. The business love this. In my experience, we would often see the business hesitant on engaging IT. Why? Well lets face it, all the gates, processes, account managers, project managers are just overkill for what we are trying to do here. Keep it simple – or else it wont grow. Avoid formal process where possible!

3. Find and empower ‘Wiki Champions’ in each team
Don’t do it all yourself. If anyone shows a lot of interest – make them an administrator of the Wiki for their team’s space. We essentially created a quick and effective support and growth model for the Wiki. For each team that came to us wanting their own Wiki, we asked them to nominate one or two ‘Wiki Champions’ within each team. Here is a sample of the support setup we deployed:

These ‘champions’ were generally the people that were contacting us on the initial engagement, showing interest. The role the ‘Wiki Champions’ play is critical:

They promoted and ‘evangelized’ the Wiki to people within their team

They where the ‘Support Contact’ for their team.
For things like 1st and 2nd level support tasks. Such examples are users with some ‘how-to’ questions, or administering groups and permissions within their own wiki.

They contributed to the overall Wiki growth and adoption.
This was done with suggestions, requests for cretin plugins or extensions on the Wiki. So in-directly here you are empowering your end users to have a say in the direction of where the product is headed. You could say they were the ‘representatives’ of the Wiki from their Team or Department.

We also found that building relationships with these users also plays a Key part in IT’s role working side-by-side with the business to empower business users to meet their goals. Not only that, but it has been great for overall the relationship between IT and the business.

4. Start off as open as possible, worry about guidelines later
The frustrations of an worker in the enterprise. You need to find a document for something. So you go check out your DMS, and you know its in there somewhere – but you can’t find it. You don’t have the right permissions setup, you then contact someone else to grant you access, and the waiting game begins. Frustrating isn’t it?

Most of the Wikis I’ve played with, by default tend to be more ‘open’ than your traditional DMS. Try to keep it that way where possible. For example, every new team that came to us wanting a wiki – we created a space for them. This space, by default was open to the public. If they then wanted to secure off a page or a sub-set of pages, they would do this themselves. Its essentially working the other way around to a DMS. This has worked really well for us.

Now what other guidelines did we have? Well, only one more – we still wanted to encourage users to utilize our DMS where possible. We didn’t want to create a big divide between our DMS and the Wiki. To do so, we created a Wiki Macro that allowed our users to create a shortcut link to a formal document in our DMS. This encouraged a balance between the Wiki and our DMS.

Why bother with a DMS at all? Some would say that almost all things should be in the Wiki, rarely using the DMS (this too is my preference), but we are far from this. One step at a time, besides, thats another blog post for me – lets leave that one for later!

5. Refer people to the Wiki where you can
If you can’t use the Wiki practically in your job – no one can. Here are some really good tips to refer people to the Wiki;

Put your meeting Agenda, action items and minutes on the Wiki. Get people to update their action items on the Wiki page.

Use it as a starting point for all documentation. You might have a wiki page setup for a project. From there you could link to the key contacts, key documentation and project timelines etc. Or, you might have a wiki page for processes. From there you can link to various spreadsheets, forms and documents around your organisation.

Use it as your notepad – take notes there and share them with others

If you are a manager – next time before you send a bulk-email to your teams distribution list, why not post it as a Wiki or blog item? Then email everyone from the team a link to it

Get the idea? There are many more tips for this. Ill link to some good sites with tips at the end of the article.

In general, we have found our wiki to reduce our email communication by quite a bit. More often people will now collaborate over a wiki page instead of emails going back and forth. That way all history is tracked and it saves you on the emails!

6. Bottom up, not top down
I mentioned earlier how people came to us for requests. Almost all these people were in non-manager positions. The requests had come from the day-to-day workers. Very rarely did it come from the managers or directors of business units. Its the people that use it every day that want to drive it. Most people probably don’t want to be told to document because they have to. If workers have a need to collaborate and document, they will go and look for a solution that will allow them to do that. This one really speaks for itself. If you want to encourage people to document – put some incentives, like recognizing the top contributors. Less governance, bottom up – not top down.

7. Training should not be more than one hour demo
Two really bad signs when starting a Wiki:

Your end-users want to go on a training course for it.
That might mean that your Wiki is too hard to use. If a user can use MS word, they should be able to use your Wiki. Have a look why that might be the case.

Your end-users want someone to put things in the Wiki for them.
Don’t let this start happening. This will just encourage users to fork out requests to someone who will become a full-time ‘content manager’ – doing all the updates on behalf of the team. The idea is that everyone contributes. A good way to think of it is “If you can forward an email to someone asking them to put the attached document or test on the Wiki – why can’t you do it yourself?”. So encourage users to put content in the Wiki themselves, otherwise they never will.

Most of the Wiki training we did was roadshow in a 40 minute presentation what the Wiki can do, its features, and how to get started. I would say most teams that have started to use the Wiki, haven’t even requested a demo – they are happy to just run with it themselves. Usually the Wiki champion within each team will assist if an employee wants some training.

Conclusion
I’m not sure if you can pin down Wiki adoption to a few things. Its really a mixture of variables. The above reflects whats worked for us – whats worked for you? Are you just getting started? If you are, there are some great resources out there. Here are some that have helped me along the way:
- Wiki Patterns
- Atlassian Makers of the best Wiki software Confluence (No bias – I don’t work for these guys…. yet!)
- 21 days of Wiki adoption
- iWiki.org – Wiki consultants
- YouTube Presentation: Wiki Adoption