Implementing a Department Wiki? A Writer Shares Some Dos and Don’ts (Guest Post)
June 30th, 2009 | Posted in blog 8 Comments »
This is a guest post by Cathy Wildhaber about her experience implementing a wiki in her department. Cathy is a technical writer in Kansas City. For the past 4 years, she has worked for a company that provides computer systems and services to financial organizations.
Ever take a look at some slick wiki technology and think “Wow, that’s really cool…I want one”? I did, and the results (an internal wiki for the documentation department where I work) were…less than stellar. Here’s how you can avoid my mistakes.
I had been working on a continuing education SharePoint site for the department. There was a wiki webpart available in SharePoint, and I became intrigued. What better way to help department members increase their knowledge about the profession than by harnessing our collective brainpower and talents! We could create collaborative summaries of training we’d attended! The intern could create a “new hire” section! We could have a knowledge base! How cool!
Wiki Dos (and Don’ts)
I immediately set up the webpart, learned how to create and edit pages, and provided a training session for my coworkers. I gushed about the endless possibilities, and then sat back and waited for the quality content to roll in. It didn’t.
Where had I gone wrong? Through the power of hindsight—and the research I should have done before I launched the wiki—I’ve come up with a few guidelines to follow next time. Perhaps you’ll find them helpful, as well.
Start with a clear purpose (a.k.a. Avoid the “if you build it, they will come” fallacy)
If you get starry-eyed over a wiki and then try to come up with ways you could use it, adoption is likely to be weak, as was the case in our department. If, however, you have a genuine process inefficiency or lack of resource that a wiki could help solve, you have a much better chance of success.
This phenomenon is best described by Mark Shead. He defines two types of technology users. Members of the first group identify a problem and then seek a technology to resolve it. Members of the second group, on the other hand, start with a cool new technology and then look for a way to incorporate it into their lives. When members of the first group adopt a technology, they are more likely to stick to it. Members of the second group often abandon the technology after a short time.
Prove how the wiki can benefit users
To embrace a wiki, users must first see how it will benefit them. Provide examples of how their real-world work could be moved to a wiki, and show how it could result in more efficient processes.
Ease existing fears about the wiki
People unfamiliar with wikis may fear that a platform in which any person can edit or delete any page will be chaotic. They may feel concern that a wiki could easily devolve into a free-for-all.
In a company wiki, the accountability for contributions and edits is much higher than in a major public wiki like Wikipedia—no one could leave anonymous spam. And while a small company wiki would likely not have the system of checks that Wikipedia employs, most small wiki communities tend to be naturally self-regulating. Chaotic editing and questions of ownership tend to be non-issues.
Provide proper training
If members don’t understand the broad concept of a wiki or the specifics of creating pages and setting up links, they won’t use it. Be sure to train users on what a wiki is (its purpose and what it’s good for) as well as on the wiki tool itself (how to create pages and set up links).
Don’t make it a chore
Don’t force the wiki upon department members. A lack of posts or edits by a particular member does not necessarily mean that the member is not finding value in the wiki.
Nurture your wiki
A wiki needs care and attention. Having an official “administrator” could imply that content is being policed, but you should ensure that someone performs a few maintenance functions:
- Introduction of a loose organization or structure (perhaps in the form of a home page that links to broad categories).
- Periodic checks to ensure that all pages can be found easily through links to a main page.
- Periodic checks to weed out any spam or mean-spirited contributions.
- Acknowledgement of good ideas, sorting of feedback, and implementation of suggestions.
Use metadata
To keep your wiki well-organized and usable, incorporate metadata. Metadata allows users to sort by category to quickly find what they’re looking for. Many wiki programs allow you to require that metadata be selected and allow you to define your own metadata. Other possibilities for metadata include content stages (can indicate whether the page is new, developing, or complete) or audience tags (can indicate whether the page is primarily for management, administration, or developers).
Broadcast updates
A system that notifies members when information has been added or changed will remind users that the wiki exists, and it will help ensure that the content is current, correct, and relevant. Notifications could come in the form of an RSS feed, or they can be as simple as an email alert. Users may prefer to receive a daily or weekly digest of changes, rather than notifications about every single change.
Encourage participation
A good way to encourage participation in the wiki is to enlist the help of a select few. You may select the most well-respected and established veterans of the department, or the enthusiastic early adopters of each new gadget, or the department members most willing to share their opinions. Often these individuals can pave the way for the rest. Recruit them to help get the wiki started; the rest of the group may well be more willing to participate after ground has been broken.
Sponsors
Tags: adoption, best practices, corporate, Wikis
If you liked this post, keep updated with new content: Subscribe to I'd Rather Be Writing.
Both comments and pings are currently closed.
0 Subscribers
Mark Baker (7)
Greg DeVore (4)
Jonatan Lundin (4)
bg (3)
Marcia Johnston (2)
mma (2)
Tammy P (2)
A Andrew (1)
Aldergrove drivin... (1)
B.J. Smith (1)
Great lessons learned!
I fell into the very same scenario at my company. SharePoint was just rolled out and I was enthusiastic about it’s wiki possibilities. You could say I was in the second group of Mark Shead’s characterisation. However, I did see the need for improving how my department colleagues across the globe share up-to-date information on product performance in our customer’s applications. So, in that sense, the wiki solution was perfect for building a knowledge base where all colleagues could share product performance and solutions resulting in all of us contributing and learning at the same time. I submitted the first wiki. To this day it is the only wiki.
One thing I learned was that my colleagues did not want to be put on the spot. They did not feel comfortable writing a wiki only for someone to critize it for it’s lack of technical depth or its inaccuracies. A wiki being changed was perceived as such.
As well as that, most colleagues preferred to continue the practice of writing a traditional weekly report. Writing a wiki was, in their minds, another form of a weekly. In other words duplication of work.
A word about the weekly. It is probably the most ineffective communications tool in existence. The practise is for each person to complete a standard template stating progress, problems, action status, etc for a given work week. This is then sent as an e-mail attachment to the manager. Never to be seen again.
I think you make some excellent points about how to encourage information sharing.
I tried creating a wiki and a blog on SharePoint. The team I work with was more receptive to the blog format. It was easier for them to post and the Categories function helped them keep on subject. It’s also easier to search. As the admin for the site, I like it because I can keep track of the blog posts and easily edit, add graphics, and hyperlinks. The Comments feature allows team members to develop an idea similar to a wiki.
I setup a wiki for the documentation department I work for about a year or so ago, and we’re still using it.
Some people started using it right away, either because they already knew how to use it (we went for MediaWiki in the end, also for a faster and less painful deployment) or because they immediately liked the idea.
Others were more cautious, but that’s because they are normally a bit suspicious or simply not used to try out new technologies, but they wrote a few pages.
In one year we didn’t produce hundreds of high-quality articles, but we definitely learned to use the wiki as a internal knowledge repository, which proved to be useful, in particular for problem solving: if someone came out with a solution for a common problem, I’d simply tell him to write it on the wiki to make sure others could easily find it (and they eventually did, in time of need).
Just on the training side of things…
A nice feature in OpenOffice Writer is its export to Meidawiki feature. If training a bunch of your lazy co-workers on how to use Mediawiki tags sounds like a chore, tell them to install Writer; once they’ve written their article, select File > Export and choose the MediaWiki (.txt) option. Then you just paste your tagged text into the Wiki. Sweet!
I introduced a wiki here at Quintiq 4 years ago using dokuwiki (I had a lot of rapidly changing C++ code documentation that made using a wiki that required a database impracticable).
To overcome the content problem, I converted all the existing documentation into wiki format and then started evangelizing. It was a slow and painful process getting a wide buy-in; some business units were quicker than others, but I guess the turning point was getting the customer support department to create ‘how to’ and error resolution topics, which they then took to with some enthusiasm.
We now have nearly 5,000 pages and 360 registered users, with the page count increasing at the rate of about 10 pages per day. It has been so successful that we clone some of the content to an external mirror (support.quintiq.com). It has almost completely replaced our extranet and most of our intranet and, touch wood, continues to go from strength to strength.
Yes, there are various pitfalls along the way, but with a some effort you can make it work … and if you do the results are astonishing.
The latest development was to nursemaid a project team through creating their own documentation in the wiki, which I then converted into a Robohelp context-sensitive online help application.
In the long(er) term, I am now working towards embedding wiki creation into our software so that documentation can be created by the development teams in parallel with the software development.
[...] Implementing a SharePoint Department Wiki? A Writer Shares Some Dos and Don’ts [...]
I agree to Ali,the development is not a game of kids for it there are lots of factors responsible from shear hard work to the consistency in the business process & the most important thing is the patience for the development !
In my department, we started out with Mediawiki and eventually switched over to Confluence, which has been great. I noticed that you assumed from the beginning that a wiki needs to be a community effort. In my dept, we controlled privileges and gave only certain people write access from the beginning. Our wiki is used our dept’s documentation database. In Confluence you can assign admins to each wiki space. In our setup, I’m the one guy who posts to my group’s wiki space. The original goal was uniformity of style and organization, and it’s worked well for us. With everything coming through one person (me) the wiki stays consistent. It was interesting to read your experience from a different approach.