Why Aren't More of Us Using Wikis?

Ann All
Slide Show

Ann's Tips for Improving Wiki Adoption

Click through to see Ann's tips on how to get your employees to embrace this great collaboration tool.

In January I shared my New Year resolve to begin using our wiki more. Sadly, I haven't managed to stick with that resolution. Or many of my others, for that matter. I still don't have an organized house, and I'm not making it to the gym more than a few times (cough) a month.

 

I suppose there's some comfort in knowing that folks at other companies haven't taken to their wikis. At least I don't feel like an anti-collaboration loser. Change, even beneficial change, is a struggle for many people. Column 2 blogger Sandy Kemsley (who shared her thoughts on collaborative business process management with me in a recent interview) wrote about a presentation she attended in which Tim Hanlon from the Royal Bank of Canada (RBC) discussed his company's ongoing efforts to get its employees to use wikis.

 

RBC started in 2006 by enabling wiki functionality in its Microsoft SharePoint implementation. After less-than-successful use of SharePoint, in 2008-2009, it switched to a collaboration product from a company called Confluence and attempted to jump-start adoption by allowing any department to implement the Confluence software with no prior approval from IT. RBC now has 66 active instances of Confluence (paid version), mostly focused around projects. In total, there are about 1,000 to 1,500 active users. That number sounds impressively high, until you consider the potential user base of some 10,000 employees.

 


Though wikis are often positioned as an effective collaboration tool for geographically dispersed users, most of the folks who use RBC wikis are based in its head office. Few employees based in its branches use them. RBC doesn't offer external access to the wikis.

 

In her post, Kemsley reports a problem I've seen mentioned by other folks: a reluctance to change others' work. At RBC, users would e-mail suggested changes to members of the wiki team rather than making changes themselves. I don't think this is as much of an issue for users accustomed to more collaborative work. Travis Carmack, manager of the IT Business Edge operations team, was the driving force behind our wiki. He often used a wiki at a previous employer, where he was a member of the development team. Developers, he says, are comfortable with making changes to each other's work.

 

The wiki was introduced during a corporate downsizing when Travis' former employer cut a number of project manager jobs. Developers would refer business users to the wiki to see documentation and other work, so it became a valuable project management tool.

 

Kesha Laun, a quality assurance analyst at ITBE and our undisputed wiki "power user," thinks some early technical glitches, especially slow performance speed, soured many folks on our wiki. It's used primarily for documentation of internal applications and processes, which doesn't exactly make it a favored destination. Says Kesha:

People hate documentation. They feel like it's just something else they have to do.

The wiki also houses our holiday schedule, employee directory and other HR-related content, which Travis thought would help drive wiki use. When he came to ITBE and began looking for that kind of information, he'd be invariably told "It's on the S drive," where it's effectively hidden in huge lists of folders with cryptic names. Some examples: Powerball 2009 (dating back to days of team lottery play), standarddocuments (descriptive, no?) and Useful tools (ditto). I'm not knocking our S-drive organization, or lack thereof. I think it's pretty typical.

 

But HR content isn't the kind of information people refer to on a daily basis, which Travis thinks is vital to encourage wiki use. He says:

It's like hanging your keys on a hook by the door. You have to know the information is there, and it has to become a habit.

Another key to wiki use at his previous employer: It was mandated at first. Mandating use forces folks to get over their fear of change and reliance on ineffective collaboration tools like e-mail. Using a stick rather than a carrot might not be an approach every company wants to take, but Travis says it was effective. Though there was "lots of moaning and groaning" at first, the moaning stopped when people realized it helped them do their jobs better. Kemsley mentions this in her post, as well, noting that "it's important that wikis are not seen as just some extra thing that people need to do, but as a way of making their job easier."

 

Wikis can be an especially hard sell at small companies like ours, where folks are used to just grabbing a nearby coworker to ask a question. Mike Walton, our senior production administrator, has developed this approach:

When someone asks me a question, I just refer them to the wiki.

Travis wishes he'd focused more on basic wiki functionality when introducing the idea to different ITBE managers. Instead of promoting it as a place to contribute and share communal knowledge, he skipped ahead to the idea of adding possible plug-ins like calendars. A good approach would have been to come up with possible use cases for each department to illustrate the wiki's usefulness. We thought of a couple for editorial uses during a quick 10-minute discussion in our break room:

  • John Storts joined ITBE as an associate editor a few weeks ago and has been busy learning the ropes of his role, managing and moderating our Knowledge Network. Many of the Knowledge Network processes could be documented on the wiki, making it easier to bring on a new hire, not to mention training some of the rest of us in editorial so we can fill in for John when needed.
  • It's performance-review time at ITBE. Travis points out that each of us could be given access to a locked-down area of the wiki, open only to us, where we could keep an ongoing record of our achievements instead of trying to remember them right before our reviews.

 

I'll wrap by offering 10 tips on wiki adoption, culled from conversations with Travis and other ITBE coworkers, Sandy Kemsley's post and some of my previous posts on wikis, including one in which I cited Future Changes blogger Stewart Mader's clever "21 Days of Wiki Adoption" videos:

  • Run a pilot with a small team. They can then evangelize their experiences to other employees. Don't just recruit enthusiastic early adopters. Get a skeptic or two. It'll make a bigger impact on other users if the skeptics like it.
  • Consider appointing an individual or a small team to manage wikis. They can ensure the basic information architecture is sound and provide guidelines for creating content.
  • Don't launch with an empty wiki. Start with some content to put users more at ease.
  • Host a brainstorming session in which users are encouraged to suggest content that can be housed on wikis. This will help ensure information is useful and give users a sense of ownership.
  • Make wikis easy to find, putting them on an intranet or other online areas that naturally attract users.
  • Populate wikis with information useful to large numbers of users. Instead of sending meeting agendas in e-mail attachments, just e-mail a link to the agenda on the wiki. If folks need to make additions or changes to the agenda, it's much easier to do so on a wiki than in an e-mail message string. Meeting minutes are a natural, too, for the same reason.
  • Though referring to existing content policies might provide a framework for wikis, you might need to add wiki-specific guidelines such as providing a table of contents for lengthy pieces and using a consistent naming system for links.
  • Managers should perform regular quality checks to ensure information remains accessible and relevant to employees.
  • Have senior managers recognize wiki power users at an all-hands meeting or videoconference. Consider offering perks like gift cards to reward wiki use.
  • Host an event in which wiki users can discuss and demonstrate how they use wikis, spreading best practices and new ideas among different teams.


Add Comment      Leave a comment on this blog post
Apr 14, 2010 4:11 AM Bill Schirf Bill Schirf  says:

I've always thought a great place for Wiki use to start in a company would be at the "Internal Helpdesk".

Instead of housing static scripts for problem resolution (desktop issues, client-side application issues, etc.) the company could allow the feet-on-the-street desktop support techs, and the application developers, and the Desktop Image Architects, etc all contrubute to provide a better "self-help" helpdesk.

Resistance might come from the helpdesk itself, as they might view this as loosing power and authority... but this could be a HUGE cost savings as calls to the helpdesk would be dramatically reduced with users accessing "living scripts" created by the LOB experts, App experts, etc.  

End user groups could even contribute their own quick fixes, which the owners of that app could review before making it public.

Reply
Apr 22, 2010 4:42 AM Bas Zurburg Bas Zurburg  says:

Thanks for the tips on wikis. I have seen many wiki launch attempts, but they all failed. The most important reason for their failure was that they were launched un-managed.

A wiki needs to be managed heavily. And many companies don't want to pay for the effort. They expect the wiki will manage itself.

The wikis I have seen quickly transformed into a collection of outdated and lost content. But indeed the tips you mentioned were not followed.

I believe that without a team that manages and moderates a wiki, it will not make it on the long run. Companies need to invest in teams that manage the internal content.

Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.