This guest post is written by Nate Nash, a friend and management consultant who is leading the enterprise wiki rollout at a large, publicly traded professional services firm.

The GrenadeLauncher at right is most likely a wiki adoption antipattern! Thanks Nate for an information packed and insightful article!

First off, thanks to Stewart for asking us to guest blog on ikiw.org. We are humbled, honored, and will try our best not to embarrass ourselves. Alrighty then…onto the (questionable) wiki wisdom!

For those of you just tuning in, Jay and I are on the tailend of managing/championing a Wiki deployment to 17,000 users within a publicly traded professional services firm. We literally started the effort in our basement and after an exhaustive pilot, hundreds of demos and discussions, and more bourbon-soaked wiki markup than I care to admit, we are proud to say our Wiki is hearkening MC Hammer.

Wikipatterns was a key resource for us in convincing the masses that we in fact deserved laudatory praise for our “crazy read/write web thingy” (direct user quote), as opposed to a Fedexed pink slip. In light of Stewart’s request to blog about Wiki adoption, I thought I would throw out a concept to not only help wiki adoption, but increase general usability, and ultimately catalyze the Enterprise 2.0 mindshift. This might be an adoption pattern. This might be a general guideline. This might be utter idiocy. Either way, I hope to stimulate dialog.

WikiSEO – Simply put, guide your users to develop content that is inherently able to be found, not sent or stored. Your wiki will respond and should be treated like the Internet. It is not email. It is not your hard drive. If your user community is wiki pages in the same way they sent or stored MS Word documents, the adoption path is a steep one.  As content grows and grows, discovery is key to both you and the community at large. Especially if you have a Wiki of wikis brewing…

Your users are probably used to creating content that would be stored at the end of a defined path (maybe a folder called “Brilliance”), that everyone (or probably no one) knew to look within. Instead of repeating the same mistakes of the KM taxonomy trolls (born in the hills of SharePointistan), and bending the Wiki into a hierarchy, make your content able to be found via search. Moreover spend your time making your content as discoverable as possible, and training your users to be SEO pros. Stored brilliance is paramount to “my fish was this big!!”. High-level guidelines on how we did this below:

• Speak English (or your language of choice) – Folks heart acronyms. We really do. I am not sure whether this is because we think it is cool, or because we like typing less letters, or because saying AJAX just makes us feel warm inside. Either way, don’t name your pages things like “BPR doc” or “OPSEC RFI”. Don’t use uncommon abbreviations when composing pages. This may sound overly simplified (OMG!) but if I had a nickel for every time I have seen one of my fellow users name a page “TO2″ or “CONOPS – DOA”, and then wonder why no one could find their content, I could buy Larry Ellison’s boat. Well…maybe just the captain’s chair, but either way drop the acronyms and abbreviations. Your search engine (and your users) will thank you.
• Link like it is your job – Links make for better search results by providing important context. Also, if your Wiki’s search engine nods to Google for its rank algorithm, more links = more accurate search results = better discovery. Links also let other people know that you see them, find their contributions valuable, and sort of want to give them a virtual pat on the back for creating content. As an extra bonus, encouraging people to link content will force them to look beyond their cube, team, project, subject matter expertise, whatever. Links are good. Links are like ice cream. Everyone loves ice cream. And links are fat free. Sweet.
• Tagtastic – I love a good folksonomy like I love a good jar of peanut butter. (Mmmmm…so tasty.) If your wiki supports tagging/labeling, train users on why it is important and useful. It will not only help the search, it will help people get over the lack of navigation.

So…before you comment below on how these ideas will/won’t work, let me throw a little context your way about our implementation:

1. We implemented a platform with a Wiki of wikis capability. Therefore our “Wiki” is composed of many smaller “wikis” with various purposes, ends, and committed users. Thus, we encourage the marketing people to make their content discoverable by the purchasing people. This leads to a need for oversimplification of content (like no acronyms) so that we can foster innovation and contribution from non-traditional sources. The interns can’t be brilliant if they can’t find the content. (The fabled open enterprise, if you will.)
2. We have a lot of people, doing a lot of vastly different things. 17,000 people is small beans for a public wiki devoted to a single purpose. But 17,000 people with 17,000 different business purposes enabled by a Wiki is tough work.  Search is the only viable means by which that amount of disparate corporate knowledge can be rationalized. Thus, aiding that search is a priority.
3. Our legacy corporate collaboration environment was pretty 1.0. Maybe even .85. Upload/download folder-based document management systems were about the extent of “collaborative technologies” available. The concept of linking and tagging was not inherent to our users. Thus, we had to harp on the basics.

Again, thanks to Stewart for inviting us to guest blog and I hope there was something interesting in here for the ikiw.org readers.  On that note, I will close with one of my favorite lyrics…”Always remember, take care of your shoes. ” – (not MC Hammer)