A few days ago, a colleague asked for help with a predicament common in Gov 2.0 circles: how to educate her colleagues, managers, and clients to rely more on a project wiki and less on e-mail? (Broadly defined, a “wiki” can be as simple as a folder or set of folders on a shared hard drive or as complex as a SharePoint “component” designed to look and feel like Wikipedia.) For example, how do you get someone to check the wiki for a document rather than e-mailing someone else for it? Then, once user A has the document and needs feedback on it, how do you get her to distribute a link to the wiki rather than distributing the document itself?
The first thing you might do is survey your team. Why do some people live and die by the wiki, while others shun it? What’s helpful, what can be improved, what alternatives would users recommend? These findings can facilitate several next steps.
1. “It doesn’t work.”
To the extent possible, you should tweak the wiki to fix any technical glitches and simplify any cumbersome processes. Such frustrations are very real, and anything you can do to minimize them will make you a hero. (Whoever invents the version of iShare, eShare, or SharePoint that allows you to download documents from a smartphone, no doubt will make a killing.)
2. “It’s extra work.”
When was the last time you communicated the wiki’s purpose and benefits to the team? Holding a meeting presents two opportunities: it allows users to vent directly to management, and it allows management to say, We hear you; here’s what we’re doing about it; here’s how you can help; and, most important, here’s why we’re using the wiki in the first place. Plus, in the future, when the temptation arises for a user to e-mail someone a question, feelings of guilt may prompt the user to visit the wiki first to see if she can learn the answer herself.
3. “I don’t want to.”
If necessary, a project’s senior leaders may want issue a directive to use e-mail only after checking the wiki. Of course, these leaders should be following their own advice, and be wiki-ing themselves. “Because the boss said so” is a powerful motivator; “if the boss can do so, so can I” is even better.
4. “I don’t know how to use it.”
Every complex initiative should have an FAQ document. Sample questions for a wiki: Where do I go to find X? If I’m inactive for X minutes, does the wiki log me off? What functions don’t work (well) using Firefox rather than Internet Explorer?
5. “Nobody uses it.”
In the end, nothing succeeds like peer pressure. The more people you convince, the greater your chance of success.
Finally, don’t discount the possibility that a wiki isn’t right for your project. Plenty of tools exist to accomplish even the most discrete tasks. As consultants, it behooves us to remember that what a client wants is not necessarily best, and that the end is more important than the means.