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. 2023 Update: Some information may be deprecated but still useful for historical purposes. In these cases, deletion isn't recommended, but it's important to identify the content as deprecated. You may rename the wiki title as [Deprecated]Title for instance. If the amount of deprecated information is too big and users are struggling to find useful information, you may consider use non-indexed (in Confluence, archived) spaces for deprecated content.

• 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. 2023 Update: Nowadays wikis offer a great deal of integration with different repos such as Google Drive or even native support for hosting documents. In such cases, the Wiki should work as a Hub for documents stored elsewhere.

• 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 opinion conflicts, 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.

Answer 4

I would like to summarize the ideas that I have learnt from the other answers into an effcient, potent compound.

Appointing active maintainers

The key seems to be assigning "owners" (active maintainers with elevated authoring privileges) to different subsections. Specific departments could appoint their own elevated maintainers.

• Owners could merge duplicated pages within the scope of their own departments; perhaps while keeping in touch with the original authors of those pages.
• Cleaning up / managing keywords and keyword aliases could also be their task.
• Owners could scan for outdated content and either update them themselves, or could delegate the updating to peers in the same department.
  • Optimally, it should be peers who self-initiate the content-updates. The owner is just an extra pair of eyes who, after familiarizing themselves with the volume of information, would develop a sense (or methods) for pointing out potentially neglected parts.
• Keeping up order and preventing relapsing into chaos again seems to necessitate that non-owners have less-than-ultimate privileges.
  • While managing content within pages would be everyones privilege, renaming, merging, deleting (and in a daring experiment, possibly even creating?) pages could be tied to an approval or to following suggestions from the assigned maintainers.

Reining in redundancy

In summary, the aim here is not "eliminating" redundancy. This suggestion is about replacing a worse kind of redundancy with a more manageable one.

Departments seem to organize their subsections primarily to be consumed internally. Now, for something new, departments should establish a new document format: a simplified, shortened, tasks-oriented variant (of select existing documents) that is aimed at users working in other departments.

This would allow info to remain in the scope of the responsible department. When a product gets an update, then the corresponding owner would know to update both the canonical and the simplified document variants with the new info.

These guest-oriented documents would rely on suggestions from "guest users" from other departments: they should communicate their needs and suggest the content that should be included for them. The owner from the host-department could approve / implement these suggestions, and later both ensure that all "guest personas" remain supported by the content, and update information within whenever the subject of the documentation itself changes.

Inter-departmental collaboration

First of all, content-maintainers from all departments should come together to study and (hopefully) agree on organization patterns that they would subsequently follow in their subsections as best as they can, allowing the entire wiki to uphold consistent organization patterns — a pillar of usability.

Regarding the sections that involve several departments: these could be sorted out by letting the corresponding owners actively organize the work among themselves, first agreeing on who's responsible for what parts exactly.

Allocating time

The initial part of the tidy-up:

• the familiarization with the contents,
• identifying patterns,
• coming up with reorganization opportunities and verifying them with involved peers, and
• implementing the reorganization

could demand a dramatic level of involvement from the appointed maintainers. In this short initial period their workload would need a bold adjustment to accommodate this intense effort.

Regular maintenance activities also demand sustained efforts, only on a significantly smaller scale. The need to allocate suitable time for the tasks remains necessary.

It's worth reiterating that the overall efficiency of maintaining the wiki will rely on the contribution of all team-members: while maintainers should serve by sort of directing the traffic, the heavy lifting should still be done by normal users contributing the mass of the content.

Enduring changes

People losing their current bookmarks and suddenly getting lost in the reorganized system can be modeled as a persona whose needs need to be addressed.

• The tidy-up operation and its expected benefits need to be communicated company-wide.
• There could be a new page established with the organization chart of the newly appointed subsection owners, so in the first weeks of the re-adjustment phase, hopelessly lost people would know who to turn to for assistance.
• Perhaps, instead of relying on page redirects, old pages (whose content got merged into other prevailing documents) could be kept, but their content could be reduced to just a message about the migration of the information and the link to the new location. This would allow people to get a better grip on the situation and update their (mental and actual) bookmarks. These old pages could also be stripped of their assigned keywords and perhaps other metadata, so that they stop polluting search results.
• People should be taught that in the new system they can rely on the content owners' collaboration and it's not necessary any more to keep their own redundant copies of information.
  • They may choose to maintain their own personal copies, notes, bookmarks, but now they will know where to look when their unofficial copies get out of sync.

Answer 5

Wikis, by definition, are collaborative structures. So, the first rule is that you can only maintain a wiki if there is ongoing engagement with collaborators. In practice, this often means that you need someone (often with a job title related to knowledge management) to oversee the material and keep things current. This is commonly referred to as "gardening" or "wiki gardening."

In my organization, we are just starting to explore using wikis for knowledge management (as opposed to the "Sharepoint" model of dumping files into a file system and relying on "search" and institutional memory). I am the person planting the garden and will, at least initially, maintain the wiki.

In this case, the document is maintain standards across several different organizations within the company, each with its own logic - with a goal towards harmonizing procedures where possible and/or understanding why things need to flow differently in different organizations. Towards that end, I am setting up a User Group (aka "Community of Practice") of interested practitioners in the various organizations and the goal is to meet regularly. Meetings will generally consist of presentations, round-robin style, from the different organizations on how they use this toolset, what their challenges are, what works, etc.

We are also pushing for including that knowledge evaluation as part of the retrospective (the company is using SAFe in a growing number of departments, so Retros will occur every few months per department - a good amount of time to encapsulate not just overall process, but "have we captured what we do and what we need to know? Where are there gaps? What can we do better."

[It is worth re-noting that maintaining a wiki is a collaborative activity, and works best when done in an organization where collaborative is the rule - part of maintaining your wiki may involve helping create and/or maintain that collaborative culture. But, hey, someone has to break ground and prepare the garden for its first planting, and then keep it going. It isn't just about dumping seeds or seedlings.]

In theory, here is a good process and involves key organizing points (also part of many Agile frameworks):

1. Ask the people doing the work what needs to be documented and how. Create/groom an overall backlog/wish list for the wiki (in the same way that we create backlogs for products)
2. Set specific goals (in SAFe terms, "plan a Program Increment")
3. Execute the PI
4. Demonstrate what you did, then evaluate (Retrospective).

Most of this effort will be used to create the software used by the company; a small amount of effort will be used to document what we did and how we are doing it across the various departments/applications/organizations, and then, most important, that Retrospective - was timely information easy for people to find? Is it current? What can the departments learn from each other? What changes make sense?

Wash, rinse, repeat. And, in between look at the rhythms of how what you need to document changes, and garden appropriately.