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.
Very interesting!
I think just like with anything else you need someone in the office to really champion the project. Let’s face it no one really wants to change so they won’t unless pushed.
A whole generations of computer users, barely understand file & folder structure, so getting them to jump in to a wiki might be a downhill ride. Many won’t use, as they feel that their work, will be absorbed and any credit will go to someone else (most work places are not collective team environments, but individual competitive events). While many younger employees & managers might join in, I don’t think many older users will be very supportive.
Start small and just do it. Many people are fearful of change. Training helps. In response to Chris–please don’t segment by older and younger! I have recently realized that I am in the “older” age group, and highly resent it (grin).
Claire – I’m in the old group too, but many, only see benifit to what can be directly connected to themselves (what’s in it for me, to be considered valuable to the organisation).
Start by example. Put everything you do that you think can benefit others and place it in a wiki. We also put all our policies and procedures into the wiki with edit controls. I then asked my direct reports to edit certain pages in the wiki and give them deadlines. Ultimately, getting adoption for wikis requires “priming the pump”. There has to be meaningful content there for people to start using it and thereby editing/updating it.
I’m a boomer, but I’m one of the 2 who *started* our wiki! I think one problem is that people don’t think of it unless they need it, and if they don’t need it very often, they don’t even think of it then. It seems like it’s kind of walking a tightrope to keep something fresh in people’s minds without nagging them so much they tune out. I don’t think we’ve managed it yet.
What I say to participants in my social media educational workshops:
“Fear not! If you know how to work in Word, you know how to work in wiki. All of the same buttons you see at the top of a Word document (or similar software) are present in a wiki. So it’s really just moving your actions from Word to the web. Easy peasy.”