Jay and I jointly share the experience of deploying an enterprise wiki platform to a largish, publicly-traded, professional services firm. It was (still is) an interesting experience and quite frankly a lot more difficult than one might think. Sure, it doesn’t have the technical hurdles associated with something like an ERP implementation, but due to a few key factors like content creation paradigm shift (thin vs. thick client), origin of idea (business users vs. IT department), and viral adoption (structured vs. social), the project proved to require just as much time.
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.)
8 responses so far ↓
1 The Rootpad » Blog Archive » Linky goodness for 04-03-2008 // Mar 4, 2008 at 6:22 am
[...] A Banana – installing a wiki Guidance on how to encourage wiki development within the enterprise (tags: @work wikis) [...]
2 Sage Advice on Wiki Adoption: Keys to Success // May 1, 2008 at 10:32 am
[...] Nate Nash, a friend who works for, “a largish, publicly-traded, professional services firm” has shared some of the best advice from his experience leading wiki adoption in his organization. [...]
3 Twan van Elk » Blog Archive » Wiki-implementatie // May 14, 2008 at 12:00 pm
[...] Meer info: E2.OH [...]
4 Knowledge on Demand-Blog! » Blog Archive » Wiki: Dos and Don’ts // May 28, 2008 at 7:19 am
[...] ein kurzweiliger Blog-Artikel von Nate Nash zum Thema Wiki-Einführung. Was sollte man vermeiden, was wird schief gehen, wie klappt’s besser? Und das ganze – wie [...]
5 Insight Can Be Orchestrated // Jun 2, 2008 at 5:58 pm
[...] social networking tools like Sonar connect employees around themes and competencies. Wikis like Confluence allow staff from differing business domains to quickly see what each other are working on. Tie it [...]
6 A Banana: Erfahrungen aus der Wiki-Einführung | Tim Schlotfeldt und Bildungsberatung // Jun 6, 2008 at 8:32 am
[...] Weiterlesen bei e2.oh — Investigations Into Enterprise 2.0: A Banana. [...]
7 Enterprise 2.0 Adoption: Business Case, Overcoming Barriers // Jun 10, 2008 at 7:55 pm
[...] wiki adoption, many of which are the same barriers to adoption of the larger Enterprise 2.0 idea. Nate Nash & Jay Hariani recently wrote about their work internally at BearingPoint. Jon Mell outlines his 9 principles [...]
8 E2.0 & Your Workforce: Reach Out To Gen Y // Jun 13, 2008 at 6:35 pm
[...] computing software continued to heat up. Technology is a key enabler – BearingPoint’s own firm-wide wiki is a good example – but keeping a close eye on the workforce issues tied up in Enterprise 2.0 is [...]
Leave a Comment