4 Weeks Of Introducing A Wiki Into An Organisation

I have a great new job. Well it's not really my official job, but I do it anyway - I'm trying to get a wiki adopted by our organisation. We're a small consultancy, about 50 people, most of them not in the digerati age bracket. People you'd find working in an office, going about their day to day jobs. About 15 full time staff and 35 consultants "out there". For the past 4 weeks, I've had quite a ride getting confluence approved, installed and most importantly - used! While I wouldn't dare to declare the operation a total success yet, I wanted to share this month with you and the things I've learned about how to introduce a wiki and a few tricks here and there that helped me getting an at least semi-loyal following into the wiki world. I should probably wait another 4 weeks and write another one of these (hey I might!).

Like in many other organisations our internal information flow is gooey, sticky stuff. We use shared drives and email - needless to say both suck. The shared drives aren't accessible to the consultants in the field and even to the internal staff they prove of limited use. The main gripe people have is that they aren't searchable and some have found local workarounds of the likes of google desktop or Microsoft Desktop search indexing the shared drive contents. Of course that makes stuff a little easier to find but we still have the versioning problem and much more the accessibility - people without a VPN connection can't get to things from outside the office. People share information by emailing word, excel and pdf documents around the office. "Read that document? Which version? Bob's version? Who's Bob?" (sound familiar?)

I decided on the wiki because I knew we could do better. I knew that because I have seen it work. Now how was I going to superimpose a new way of working to 50 unsuspecting guinea pigs?

Lesson #1 - Pick a target
No matter what you think, you are not going to change the world overnight. The same goes for a team, even if it's not a big one. My strategy for adoption was going to be one by one. The first "one" was a new project that just had emerged. After installing the wiki I basically walked into the customer kick off meeting and pulled out the confluence meeting agenda page before anyone could really say hi. I said that I realized everyone's time was precious and that we wouldn't have a chance of doing this everyday. Then I pointed at the agenda page, changed a few things, did a 1 minute edit and left a bunch of business cards on the table, remarking that everyone should email me if they wanted in, while promising project content to be available there. I got 2 minutes of airtime before I felt I was about to be "taken down" and I rolled the presentation up. Earned some weird looks but got 4 customer emails within 2 days. Success!

The other one by one target were going to be my workmates. Pick one person, give them a walkthrough, show them what's out there, create an account and ask them to help me change things and maintain common information. With confluence you also get personal spaces, and after I realized that every future convert I was talking to was especially interested in the people directory, I made a habit of setting up personal spaces with real pictures of people as I walked my new users through what confluence does. With every new face in the people directory, the "ah" effect of looking at it from a newcomers perspective seemed to be bigger. I always took new snapshots with my Mac, not using CV pictures, they just look more real and as if the people were actually in the wiki. Mental note: casual pictures are good for an informal information space. We now have around 10-12 picture profiles and people start putting up personal content such as baby pictures, dogs and their sailing yachts! Personal spaces proved to be a real killer as they helped spread the wiki through the existing social network.


Lesson #2 - Make your entry barriers low
But if that may sound like early success - my job is far from being over. How does this wiki notation work? Do i make a page or a space? Who can see this information? Is this secure? What do I put where? The confusion going on about a new medium like this wasn't going to be settled easily. Aiming low was always going to be one of my goals, yet I had no idea how low I would go - introducing a wiki proved to be quite a limbo dance competition ;) One of the first things I've learned is that it has to work instantly - and because people aren't happy editing pretty polished things that look ready, I made a point of going to the test space first and demo. "yes you can change things and that's cool". It earned me some points on things being easy, but I sensed a general feeling of "inappropriateness" in my target audience when it came to changing what other people have put up. This one was not going to be an easy one. A few things I have learned about wikis(confluence) and entry barriers in particular:

a) Use Wysiwig editing and don't show wiki markup too soon. The "digerati" folk will figure it out soon enough, the rest *don't want to see it*. "Eek we have to program".

b) Set up a space email address people can mail. Something people do naturally is email - even your non users (which of course you have created accounts for anyway) will cc a project email and make things available to the group without knowing how it worked.

c) Set up WEBDAV - it is a total killer. In confluence you can save attachments to webdav if the proper plugin is installed. Make sure to map a windows web folder on everyone's desktop so they can save files into the wiki. Now this has proven to be the most useful entry barrier we have lowered. People can update wiki attachments without knowing it! Let your key people decide what content goes up and make sure the rest has the windows web folders mapped to the right place. Sooner or later everyone's going to build the mental bridge between the wiki page structure and the good old shared folder. It still feels like a shared drive yet it feeds into the new wiki crowd. You gotta *love* WEBDAV.

Lesson #3 - Seed content
By now we might have shared folder love and a few early adopters but we still need a reason to go to the wiki on a regular basis. Choose your seed content and your structure carefully, based on whom your target audience is. Don't do too much or the wiki will look like your personal little empire. don't change and reorganize everything people contribute, it will make them feel insecure about doing it again - even if it wasn't in what you think is the right place. Also choose some exclusive content that is layed out nicely which will only appear in the wiki. In our case I put social events pictures up there and asked someone else to email a notice to everyone that they had found them there. Within 1 day, I got 10 emails requesting login accounts. Exclusive content works!

Another thing we did is convert the internal phone list from excel to a confluence page. Within a few days people started updating it because it was easy (could be done in wysiwyg). Seed content needs to be useful and make life significantly easier.

Lesson #4 Show them the future
Even though not everyone might be comfortable with it at first people want to go on a journey. Have sexy pages, do advanced formatting or macros of the likes of IM status pages, google maps and calendars. They spice things up and allow people to go "wow". If they see the unexpected, they are more likely to give things a try and come up with stuff of their own that could actually be really useful to the team. You need to excite your key people, they will become your ambassadors.

So far we have reached out to about 30% of our staff, I've won a few key people but we haven't reached critical mass yet. I hope we will make it. Let me know your wiki adoption stories, I'll post a follow up next month.