By Francoise Tourniaire, founder, FT Works

Once the initial launch of the knowledge base is over, the main challenge is maintenance: making sure that obsolete or extraneous documents are weeded out, overlaps are identified and resolved, and confusing documents clarified. For an established knowledge base, the maintenance effort is typically much larger than either authoring or publishing. So where do we start?

Can the search engine conquer the maintenance monster?

The short answer is “maybe”. Most search engines don’t fare well with a poorly-maintained knowledge base. For many users, the consequences are familiar and painful:

The more sophisticated engines seamlessly integrate usage patterns into search results and do a wonderful job of hiding those old, obsolete, duplicate or irrelevant documents at the tail end of search results, effectively shielding them from users who aren’t specifically looking for them. If you’re lucky enough to have a sophisticated tool, you may simply leave every document in place and step back to let the search engine work its magic.

For everyone else, proceed to the next step.

Review for new releases

When new releases come along, it’s a good idea to review existing documents to see whether they are still relevant. However, this can be a huge task. If you have a dedicated team for knowledge management, you may be able to review each document for each new release. If not, try a sampling approach as described below.

Many support organizations have a version-focused way of organizing their knowledge base. In that view, documents that pertain to release “2.3” all have a “2.3” tag. When release “2.4” comes around, it is necessary to review all “2.3” documents to determine whether they still apply to the new release. However, a better approach should be considered. In many cases, documents created for “2.3” are relevant for “2.4”, so perhaps organizations can do without a version-focused system?

Implement an obsolescence process

Fancy word, simple idea: simply stamp an expiration date on each new document so you know when to pull it out for review. In typical support organizations which incorporate dynamic releases, a good default methodology is to review holistically every six months, but allow each author to choose a custom, situation-specific expiration date. For instance, one of my clients has had frequent sales promotions with defined expiration dates. The promotional documents were set to expire a couple of weeks after the promotions ended, just enough time to allow the support staff to tell customers of a particular program’s expiration date.

When the document reaches the obsolescence date, you can choose to remove it from published status entirely or simply put it into a special status which allows it to be easily reviewed for relevance. I like the status approach since it’s rarely the case that a document suddenly stops to be relevant just because it reached its expiration date. You should be able to add an expiration date in most knowledge base systems.

Dare to use partial reviews

Do you believe that each and every document must be reviewed in its entirety before posting? Then you may also believe that each and every “expired” document should be pulled from view and reviewed. That’s a fine approach if you have the resources needed to accomplish the reviews, but that is often not the case.

In many instances, reviewing a subset of the expired documents is sufficient. A great way to do that is to leverage usage data. Documents that are heavily used get priority for the reviews. Lightly-used documents may be allowed to languish. This is perfect if your search engine presents documents in order of popularity when returning results. If your search engine can’t do that, consider deleting the lightly-used, expired documents: few people should miss them!

Use reactive reviews

Does your organization give users a way to flag questionable documents? If not, I would strongly advise finding a way to implement this feature, at least for internal users. It’s a great, low-impact way to gather feedback from motivated users (internal users are usually very motivated.) If you institute a flagging mechanism make sure you actually take action on the flagged documents otherwise the users will quickly lose interest.

Exercise caution with translations

If you are translating documents, then each revision of the base document should trigger a review of the target documents. Unfortunately, it’s usually difficult to pinpoint the exact changes since few knowledge base tools have version control, so it may mean that a full review is required to find the changes.

Francoise Tourniaire is the founder and principal of FT Works, a consulting firm that helps technology companies create and grow their support operations. She’s the author of The Art of Software Support, a practical guide for support managers and executives. Along with David Kay she’s working on a new book about knowledge management to be published in early 2006. For more information, visit www.ftworks.com or call 650 559 9826.

Comments? Suggestions? We would like to hear from you. Please email the editor at sspanews@thesspa.com.

Download PDF