So…sweet. Jay and I have the merit badge. Word of our badge (and sash?) have percolated through the firm and we now get calls to help existing clients with implementing their own wikis and similar enterprise 2.0 technologies. Inevitably, our clients ask for best practices, potential pitfalls, methodology, lessons learned, and (insert typical consulting artifact here). So, in the vein of decaying IP, I thought I would share some high points here:

Pitfalls
Implementing a wiki is the antithesis to traditional enterprise application deployment. Treat it like an HR or Financial system, and you are bound for failure. Typical mistakes include:

• Lack of willingness to move to the read/write web paradigm – It is not a new place to put work, it is a new way to do work.
• Treating your users like kids – Overactive security models, excessive taxonomy, and extreme management oversight will turn your wiki into nothing more than the magnificent, inflexible shell you originally created.
• Treating your users like geniuses – A blank slate with little guidance or seeding will work for only the hyper-creative. We paint lines on roads for a reason.
• Wiki panacea – A wiki will not solve all of your problems. It should not be positioned as all things to all people. Change is slow. Don’t try to eat the elephant.
• Managing to the possibility of failure, not success – If you are more focused on how the wiki will fail, instead of how it will succeed, you have already written your destiny. The cost of failure is relatively low. The value of success is immeasurable. (Really, it is – so don’t try and measure it.)
• Asking for permission – Encourage your users to proceed until apprehended. The best content comes from a user community free to express themselves, without fear of (overwhelming) retribution. Critical mass will be impossible to achieve unless people are willing to step forward on their own.

Best Practices
Begin your day by understanding that a wiki implementation is like surfing. Be prepared to react to the forces of nature, and shift direction easily. These implementations are “quasi-unplannable”. Best practices include:

• Start with a discreet, flexible, and relevant business process – If you do nothing but have meetings, keep the minutes in the wiki. If your do nothing but go to happy hours (please hire me immediately and) post bar reviews in the wiki.
• Identify a participating sponsor – Find a high-level, well-respected leader and implore him/her to begin using the wiki ASAP. Contributions from management will bolster the rank and file to participate.
• Spot pros early and recognize contributions – Keep an eye on updates and learn who is not only active, but qualified. Encourage them off and on line to continue and mentor others.
• Go viral – Adoption of a wiki is best achieved when predicated on a “want”, not a “mandate”. Avoid mass communications and anything that sounds non-exclusive. While this can be a slower method for implementation, the results are a much more entrenched and vibrant community.
• Drink your own kool-aid – If you are advocating use of the wiki for collaboration on a new policy or procedure, and still emailing attachments, you are sending the wrong signal.

These points were developed through a combination of the advice and guidance from Stewart Mader and our own implementation experiences. Stewart was instrumental in helping Jay and I navigate what I now believe are the potentially troubled waters of implementing an enterprise wiki. If you are even thinking about wikis, go buy his book. It might just save your life. Well…not really, but it is a great read nonetheless.

More later on why enterprise wikis are difficult to implement…

(Neither Jay nor I have been compensated in any way for this post.)

Bookmark It

Hide Sites