Workplace wiki suggestions/advice?

In My Humble Opinion (IMHO)
#1

Does anyone have any experience using a wiki as a workplace reference? I’m in manufacturing/engineering. The factory has matured, and while we used to have general information about the process literally falling off the shelves, it’s now kept mainly in the back of everyone’s collective heads and as powerponts on personal drives. This makes it hard for the people moving up through the ranks to learn about the job.

I’m thinking about starting a wiki to keep this general info. Has anyone here done this? What worked and what didn’t? Can anyone suggest a good wiki program, or is there another structure that we should be looking at?

#2

My company uses this one: http://info.tiki.org/tiki-index.php

It is pretty good, I have no complaints. Wiki solutions are, it seems to me, fairly similar from one to the next. I’ve used at least 3 or 4 different ones over the years, and this seems as good as any.

#3

Thanks. I haven’t pitched it yet; we’ll see where it goes.

#4

Unfortunately, IME, this is going to be a hard row to hoe.

Choosing which wiki to use will be the easy part. If you have a document management solution at your workplace, you may want to see if it also supports content or wiki pages. Many good ones do. SharePoint document management system is widely used and it has a wiki feature that is reasonably good.

Your biggest obstacle will be adoption by your cow-orkers. Most people don’t have the time or interest in maintaining a knowledge base (which is really what you’re talking about). Additionally, a surprising number of people like having information in their heads. They feel it provides them with job security (it doesn’t but you’ll never convince them otherwise). So you’ll need to get your management to support and endorse this initiative. They will need to make it part of everyone’s evaluation criteria, i.e. all employees must document your business process in the official Knowledge Management Database by June of this year.

You’ll also have to come up with a sturcture that will house the various topics and subjects in a way that can easily be found - after all, what’s the point if it’s difficult to find? You’ll need to implement a change management startegy because information needs to be updated as business processes change. You’ll need to identify champions for each business unit who will herd people into posting new and relevant information. Did I mention mangement support?

As for structure, keep it as flat as possible. A breadth of topics is better than a deeply nested structure. It’s easier to find and retrieve. You’ll also need a librarian to support all the users who eff it up and need to move/fix/update/recover the shit they post.

Have I talked you out of it yet? :slight_smile:

#5

Quicksilver is wise.

I AM a librarian, and our library has a workplace wiki for policies and procedures. It is … less than optimal.

Some things to consider.

Do you want a wiki, where EVERYONE can edit (ie, vandalize/damage) posted process or policy information?
Or do you want an online repository of information that general rank and file workers can ACCESS but not ALTER?

If you want the latter, you do NOT want a wiki. Calling it a wiki, and using a wiki structure and template will frustrate the hell out of everyone involved. (speaking from experience here)

If a database is what you want, build a nice flat database with a passcode entry tied to each employee specifically. Categorize the info banks by job duty, and hire/appoint ONE PARTICULAR person, preferably a general overseer familiar with all departments, to make sure it is kept up-to-date on current practice. Whenever employee reviews come up, make each employee demonstrate that they can access the database and find specific process or policy information to pass their review.

If you actually DO want a wiki, all of the problems that Quicksilver pointed out are true, and unless you have a way to FORCE your staffers into transferring their various knowledges into the wiki, they’re not going to want to do it.

The best of a bad lot is to assign each department or job function group to submit their specific workplace duties to the wiki by a particular date, or start facing sanctions as a group/department. What will likely happen is that the department will have at least one person who doesn’t actively hate the idea of a wiki (or is the most tech-savvy, or the scapegoat of the group), and that person will become that department’s “contributor” to escape group punishment. Like before, assign a SINGLE person to be the wiki admin, but that person now has to build ties with the wiki contributor from each work group, and make sure that they keep their information complete, clear, and updated.

Seriously tho - just build an online database instead. So much better.

#6

I maintain a SharePoint wiki site for my team. Lasciel and Quicksilver make good points. It’s not the software, it’s getting people to use it.

My team will look there for info and now it’s usually the first place they look if they need something, but it took years of nagging them “did you check the wiki?” for that to be the norm. Also, I know that as the main contributor, if I stopped maintaining it, it would die. I add about 90% of the content and I also review and remove obsolete entries. Occasionally one of them will add a quick article or correct a typo.

#7

I, too, started a work wiki as a knowledge database. I arranged for a Co-Op to enter and verify all the basic information. And then I wrote some detailed entries on my own areas of expertise. And then had our manager tell everyone to go forth, and do likewise.

Six months later, when the server crashed and all was lost, the Co-Op and I were still the sole contributors. And all of my co-workers were still complaining about having to answer endless, petty calls about the sort of information they were supposed to have put into the wiki. By that point, I’d washed my hands of it, so the work wiki died an unlamented death.

And my co-workers still complain that something has to be done about all the endless, petty calls for information. sigh

Buy in from your co-workers is critical; if they’re not enthusiastic about writing and editing wiki articles, don’t bother.