How to organize knowledge within a wiki?

Question

Using wikis as a knowledge database becomes more popular since a few years. But now I realized that most of the knowledge is lost because:

• articles are out-dated
• there is more than one page for the same subject
• one cannot find the right page, because keywords are used everywhere

This is the actual setting at my workplace:

• each departement has it's own subsection for its products / services
• other departements keep summarized (redundant) instructions about using someelse's products
• but there are also some pages which concern more than one departement

How can I organize a wiki to keep it clean? How do You avoid those problems?

(This is not directly about project management, but I think the project manager must be part of the solution.)

Answer 1

Here in our project, we have around 20 ppl working in different continents, and having our knowledge database up to date is a key to our success. Some things I consider important to highlight, besides the ones pointed by @mfloryan:

• First of all, understand that maintain a Wiki takes time. it sounds obvious, but someone will eventually take some time to work actively on it. Suggestion: Pick up that 'organization-maniac' guy who is eager to help but don't know how to do it. Ask him to review the structure and suggest what could be done. Merge / delete topics can cause confusion to the people already used to use some links.

• If the information is getting redundant across the structure, is time to review the tree structure used. I believe a good index needs to be clear enough to explicitly show where an information is supposed to be.

• During team meetings, discuss actively about the wiki. What has been added? What was redundant? Was you believe should be removed? The culture of adding information into a common repository is important. The culture of get rid of outdated information updating it, is even more important.

• In case the information in one single page needs several scroll downs, think of break it into sub pages

• In case the information, even broken into small pieces is still big, maybe it's time to migrate it to a proper document. Here, we store presentations / spreadsheets / documents into SVN and then briefly talk about them in the wiki... pointing where in the SVN the document is. That's specially applicable to diagrams / UMLs that may not be presented as clear as in the diagram tool.

• You must define owners in your team to keep track of Wiki's health. They may be the only ones with 'removal' access or to mediate oppinion conflits, for instance. It all depends on the structure of the wiki, but owners are a must (thanks @SBWorks for highlight this item).

Hope it helps.

Answer 2

For me, the main question is about what knowledge you intend to store on the wiki.

It can only be useful if there are people who can actively contribute content and people who actively use that content. It also needs some sensible information architecture (to avoid duplication).

I would suggest you might consider

• giving everyone full access to the wiki (I assume that's the case)
• ensuring there are no alternative sources of the same information
• keeping the amount of the information to a minimum
• actively removing content when it gets out of date or becomes irrelevant
• having someone looking after the structure and maintenance of site (give them time to do it)
• automatically generating content if there are reference data sources (for example, machine names list from DNS configuration)
• on software projects, try to move as much information away from the wiki and closer to the code, idea in a executable format (that is, in tests) or combine the wiki and the testing platform using FitNesse

Answer 3

Avoid department-specific categories. Look at wikipedia, it's much larger than your company wiki and doesn't name pages as, say, /Animals/Mammals/Rare/Panda. By avoiding such categories you remove the confusion about where to put content.