Corporate wiki deployment pitfalls
This is actually a repost (and remake from a bit of knowledge learned from the comments on the original blog post and throughout the deployment of yet another corporate wiki) of something I wrote on Safira’s wiki (you can find the link on the side bar), it’s more of an experiment to post it here as well…
So how do we go about to implement a corporate wiki?
ok, let’s brain storm a bit here…
First and far most Mediawiki has some serious input problems. It somehow resembles the way you input stuff on Latex, but without the permanent brain damage, It drives less tech-savvy users away and a wiki should be able to be edited by everyone, not just the people who are inclined to learn it’s Dante-like markup language.
To-Do: install a proper wysiwyg on your wiki. TinyMCE and fckeditor are good choices. As a simple workaround (but not nearly as good as the previously mentioned) you have a very cool greasemonkey script you can painlessly install called wiked.
And if you don’t? well… people will still edit it, they won’t like it, but they will. Commitment will be slow and painful. Reminiscent of the “whippings will continue until moral improves” motto.
Then there’s the desert. We are used to waltz into wikipedia or KDE TechBase and have the wiki populated with articles, it thrives with an active community, discussions and trolls…your corporate wiki is as fruitful as a 70 year old lady with the hots.
To-Do: small task force to populate the wiki before the whole team/corporation/client even has a glimpse of it.
And if you don’t? be ready to answear “what for?” questions, low level of commits (and commitment) and desertion from the intended end user. And if you are planning a wiki for a team that already has fine documentation, you can rest assured your team will continue to use that documentation (because it’s there!) and be spiffy about the wiki.
Limbo syndrome. So we have wonderful documentation (gotta love those templates!) and we have over 50 task procedures, niched in a fetal position in those documents. And then there’s a wiki…it’s got 15 of those documents, and the new ones someone added to the wiki but didn’t bother to write the doc for it…(figures, you’ve been pushing the wiki pretty hard, right?) information is scattered, some are up-to-date on the wiki, some on the documentation, some doesn’t exist but should…damn.
To-Do: several ways to go about this: you can use the task force to migrate every single document to the wiki, churn on the documentation and go full blown wiki on everybody. it’s do-able. You can try and maintain both silos of information until you are ready to yourself commit to the wiki (I strongly advise you to have this well though out and planned. if you are feeling ground…well…don’t! wikis are about first impressions and you never have a second go at those.) Make a decision and stick with it…it’s either go or no go…there’s no middle ground.
And if you don’t? imagine if the 10 commandments were scattered around….hyea, that’s the deal. “what do you mean I can’t covet the other guy’s wife??? the version I checked doesn’t mention any of that!”
Ongoing task: keeping your user based interested. Because a wiki without continuity is simply casted away into oblivion.
To-Do: make another blog post about it.
And If I Don’t: I’m a wanker.
This is a very shy attempt to some common pitfalls in the bootstraping process of deployment of corporate wiki. Feel free to comment and add your experiences. I hope to eventually create a page for the subject alone, a silo of all things “corporate wiki”.
May 1, 2008 at 10:28 am
From my own experience implementing a corporate wiki, I agree that it must be a very well-thought process (because corporate wikis are processes, not products). We also created a task-force to pre-populate the wiki before going wild and it resulted very well. We’re now trying to instill wiki in the company’s culture: “don’t email - wiki it”, “don’t ask in the hallway, ask in the wiki”, etc. So far, the adoption has been great: new articles every day, lots of comments, etc.
I disagree with the wysiwyg editor though. It may be nice to have an office-like toolbar in the first days, but it will slow you down in the long run - your users will be begging for wiki markup in no time.
There is some nice info on wiki adoption at http://www.wikipatterns.com/display/wikipatterns/Wikipatterns
May 2, 2008 at 10:33 am
One of the cool things I managed to do with our corporate wiki was the layover of shift information (I manage a team of system operators), the front page of the wiki states every thing the next guy on shift needs to know to maintain business continuity. That alone killed a bunch of excel files and emails scattered in network shares and mailboxes.
But as in every team the member’s “at ease” with technology varies, and a few of them had never edit a wiki before. needless to say I need *every* operator to edit at least the front page on very regular basis.
fckEditor has the pretty office-like-buttons and wysiwyg editor, but it also has a nice “wiki” button that sends you back to the regular wiki editor.
I’d say 8 out of 10 users, so far, keep away from the regular wiki editor. But I believe you are right…used to be 1/10 (me!)
May 16, 2008 at 6:00 am
Considerations in Deploying an Enterprise vs. an Internet Wiki
There is a difference between an enterprise or internally facing wiki (inside a firewall) and that of an Internet based or external wiki (outside a firewall). While the platform can remain the same and the basic purpose of collaboration is the same, it is their application purpose and the types of data collected and maintained on these systems which is different. Enterprise wikis contain team and project type information. This information usually consists of information such as team member, colanders, project statuses, inventories, and processes. Enterprise wiki contain large portions of information for a limited or closed set of people. An Internet based wiki is a wiki which provides information about an organizations good or services to a much larger user base. Internet wikis serve much more in an information sharing, education, and marketing capacity and less in a project management and process documentation capacity than that of an Internet wiki.
Because there are some differences in these two types of wikis, there are also a number of other items that must be considered when building an Internet wiki versus that of an enterprise wiki. The main factors you will want to address in an Internet based wiki will be:
• Ease of use
• Speed (User Response)
• Scalability
• Security
• Content Moderation
• Skins (Look and Feel)
• Navigation
• Metadata
It is not that these items are not important in an enterprise wiki, they are extremely important but there are a number of items which take priority in an enterprise system such as:
• Flexibility
• Plug-ins/Extensions/Adaptors
• Integration (mashups)
• Email integration
• RSS feeds
• Content change notification
• Training
• Job function application
• APIs
Again the reason for the differences here is because most people will use the Internet based wiki as a repository for viewing and collecting information on products, technologies/systems and services. The user base will most likely have about a 1-2% user contribution rate, where as in an enterprise wiki it would not be unreasonable to have an 80-90% contribution rate meaning that 80-90% of the users have contributed at least once. So with an Internet wiki the more users you have the higher qualify information you will have. This isn’t necessarily the case with an enterprise wiki where the quality of information will largely be a result of a concept understanding peer review, benefits of adoption, and mainly education.
With an Internet based wiki you will want to focus on the skins to make sure they adhere to your organizations branding standards. Internet wikis also have the potential for explosive growth as well as vandalism items which are much less of a concern in an enterprise wiki. If an enterprise wiki has scalability or navigation issues you can tell the user base to hold-on changes are on their way. On an Internet based wiki system your users simply don’t come back if they find the site aesthetically unappealing, unreliable, or no responsive enough. Therefore with an Internet wiki system you will want your site to have a very professional and appealing look and feel so that no matter what is contributed it is well presented. This will make visitors less hesitant to contribute to your company’s public collaboration space. You will also want to have a process for moderating content. Removing liable and unseemly content will be important in maintaining an environment that appeals to the greatest number of contributors and promotes participation.
Enterprise wikis are slightly different in that factors that contribute to the greatest adoptions and collaboration are benefit to a person’s role, education, and a clear contribution strategy. What is meant by this is that people are often willing to contribute but they will say they don’t know where to put something. Having clear information architecture, a method for easily navigating it and educating the users on the basics of the information architecture will greatly drive adoption.
An enterprise wiki will also need to be much more flexible because it will be used in a much wider capacity than that of an Internet based wiki. For any one organization the wiki might be used to keep track of customers, part number, manufactures, suppliers, shipping, operations, training, and other function required by and organization. So one will want to look at watch features a particular wiki has and in addition how that wiki can be expanded in capabilities this is usually done through plug-ins. Different wikis call them different things such extensions, modules or adaptors. Whatever they are call their purpose is to expand the capabilities of the wiki.
Since on an Internet wiki some of the main concerns are speed, reliability, and security you will not want to just start adding plug-ins without carefully considering each and everyone. Each plug-in generally expands the command options or feature set therefore that code much be processed before a page can be displayed. The more plug-ins you add the more code that must be processed per-page therefore adding vast amounts of unnecessary will not only slow down the response to the user with each line of new code you must consider the security implications.
Craig Tobias
Senior Solutions Architect
Cisco Systems
May 17, 2008 at 7:29 pm
Loved the comparison between Interwiki and Intrawiki (you heard those two words here first, folks!…ok, maybe.) and I do agree.
The training bullet is really what I was trying to assess with the use of real WYSIWYG editors, you added the plugins and extensions that take that to the next level.
Right now my challenge is the mashup bit you mentioned. I would really like our wiki to interact seamlessly with other software, namely alarm systems that are already in place. (if a dslam is down, if we know some core bit of the network is having issues, it would be very nice to dynamically display that on the front page so that the guy picking up the shift would instantly be aware of that).
I wonder about the email integration, though… because one of my goals with the wiki was to cut on excessive email interaction between team members. Perhaps a gateway for non-team members who don’t have access to the wiki?
Thanks for that highly informative and though out comment, Craig.