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.
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:
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: