Using a throwaway wiki to get I.T. and management buy-in

So how do you get your organisation to think seriously about implementing an Enterprise Wiki? Why not take it upon yourself to take the first step?

Using a throwaway test wiki is a proven wiki adoption technique also known as Flying Under the Radar (FUR), or the Wiki Ninja technique.

Jakob Nielsen recently posted the results of his research into Social Networking on Intranets and how large companies are coping with the buzz around Enterprise 2.0 adoption.

He makes an interesting point about the most successful initiatives:

[...] in our studies, successful social media initiatives at many companies emerged from underground, grassroots efforts. This might be surprising, as companies often keep a tight rein on technology initiatives and force all employees into a standard desktop build, right down to a mandated version of the Web browser. Underground adoption of off-the-shelf Web 2.0 tools seems a little out of character, but users are more likely than executives to see the tools' value and translate that value to an internal use.

...He goes on to explain that his research into organsiations such as Sun Microsystems, BT, IBM and AXA UK has thrown up the following points that are of particular interest for those of us striving to encourage adoption of social software within large organisations:

1. Underground efforts yield big results
2. Frontline workers are driving the vision

In this post I'd like to encourage the use of these guerrilla tactics in order to introduce the concept of a Wiki to your organisation. We'll be looking at how to implement one without stepping on the toes of your management or IT team, and some practical uses of a Wiki in an enterprise environment.

What is a throwaway test wiki?

If you're interested in introducing team wiki collaboration into your company but are finding it hard to convince others of the usefulness of a wiki, or lack experience in how a wiki might be used in practice you should try setting up a throwaway test wiki.

The basic idea is to:

• set a wiki up "under the radar" (i.e. no IT dept or executive involvement) using one of the many free or low cost on-line services
• test it's practical use with a small team and project (or even just part of a project)
• get other team members familiar with the concept of a wiki
• use the experience to provide a case for wiki adoption to senior management
• be able to throw the wiki away (after exporting any experience or knowledge you want to keep)

The concept of the wiki being throwaway is important for 2 reasons:

1. It encourages experiment; it doesn't matter if you try something and it ends up not working because you're going to throw it away anyway
2. If your I.T. dept find out that you've been storing project information outside of the normal channels you can reassure them that you are making regular copies of the definitive version of the information contained on your test wiki and storing it in the normal way.

Setting up your throwaway test wiki

We'll suggest some wiki services in a later post (if you have any ideas, please do comment), but you're looking for a free-to-register hosted wiki service that will allow you to:

• Add several team members to a workspace
• Create wiki pages that your team can collaborate on
• See document history (check how easy it is to see the differences between each document revision)
• Export, or at least copy-and paste the content of your pages back into the work-flow that your organisation regularly uses

What are you going to use it for?

First, a caveat: Be sensitive to your organisation's information policy. Ask yourself if the information your team will be working on is too sensitive to have a copy of it stored outside your company's network. Pick a scenario that is suitably safe!

I'm going to suggest that you try collaborating on a document that requires several people's input. For a Noko project, for example, we set up pages for initial project requirements and the specification document. From there several people can collaborate on the document, or make comments for others to review. So something like a project spec, or a piece of documentation would be a good bet - anything that several people need input on and may well get updated over an extended period of time.

During the project, rather than discussing changes to spec over email, update the project spec wiki page and drop an email to all the team members if you need to notify them of the change (or get them to subscribe to the RSS feed of that wiki page). You may also find your free hosted wiki offers to email your team for you each time you make a change.

Choose the wiki content carefully. Ideally you want to ensure everyone on your team can edit the wiki page, that it's appropriate for them to do so, and you don't need to keep registering new users who are outside your core team. For instance, if you run a development team and want to use the wiki to prepare meeting agendas / notes then using it for your development meetings that involve your close team members would be fine. However if you start using it for a high-level project meeting you might find it inconvenient to start giving lots of other people access to your test wiki to whom you are not so close.

Encourage your team to use the wiki for any other documents that they wish to collaborate on.

Team rules

1. If required, take a regular version of the wiki content and save it outside of the wiki in the way your company expects you to save that information. This is obviously something you wouldn't need to do if you had an official company wiki, but you're covering yourselves here. Internally you may as well keep the project appearing as normal as possible. You're using the wiki as an experiment on the side, not a replacement (yet!). If you explain it this way to your IT department before you start, and tell them you won't need any support from them, and you're going to throw it away afterwards in order to come to them and ask for advice on a corporate wiki they will likely love you forever!
2. Experiment! You're going to throw the wiki away afterwards so encourage your team to experiment with any sort of collaborative document, even if it ends up not working. Set up a page on the wiki that lists the scenarios that your team have tried, whether they did or didn't work, and get the team to contribute their findings to that page.

Using a throwaway wiki to get I.T. and Management buy-in

Once you have your Wiki in place and have proved it's worth as a tool you are in a much better position to explain the benefits to others using practical use examples that are relevant to your own organisation. It's time to take the Wiki higher up the ladder to sell the concept with a view to, at the very least, promote discussion, or in a perfect scenario have your organisation begin the process of discovering how a Wiki can be of use before implementing their chosen Enterprise Wiki.You may even be able to use the Import function of the new Wiki to import your work from your throwaway Wiki project.

If you have already implemented a Wiki in this way, please let me know how it went and if you have any insights to add.

Good luck!