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.)

  • 1
    First determine who will be using it and what information they are looking for. Then organize your wiki to make it easy for them to find it. – shawnhcorey Dec 22 '16 at 19:17

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.

  • 3
    And the wiki needs a clear owner or group of owners. Someone has to have approve/reject control for people who differ in opinion – SBWorks Jul 7 '11 at 5:59
  • @SBWorks, indeed, forgot this item, thanks! We do have these people in the team, just forgot to mention. – Tiago Cardoso Jul 7 '11 at 12:11
  • @TiagoCardoso, How does this scale? How would a single guy be able to do the organization when the contents are spread throughout multiple international teams? – Pacerier Mar 3 '16 at 5:25

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
  • +1 for a good set of suggestions, especially the one about maintaining the wiki. – tehnyit Jul 8 '11 at 22:13

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.

  • 2
    Wikipedia leverages Google search. If your wiki is not going to be hosted publicly, following Wikipedia's organization will be a very bad idea. In fact, even if it is hosted publicly, Google wouldn't be spidering your wiki as often as it does Wikipedia. Have you actually tried categorically browsing through Wikipedia pages using Wikipedia's interface alone? It's possible, but it's a complete mess; Wikipedia pages can't be found without Google. It's like trying to find a file in a single-folder that has a million files. – Pacerier Mar 4 '16 at 11:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.