Home > KCS v6 Practices Guide > Section 2 The KCS Practices > The Evolve Loop > Practice 5: Content Health > Technique 5.5: Archiving Old Articles

Technique 5.5: Archiving Old Articles

Age and Size Shouldn't Really Matter

One of the by-products of the KCS Practices is improved success with search. If we are only finding relevant articles when we search, we don't have to worry about how big the knowledge base is or if it contains "old stuff." If it is not relevant, old stuff should not show up in our search results. In fact, we could make the case that on those rare occasions when we need the old stuff, the value of the seldom-used, old articles is higher than the set of frequently used articles, since the knowledge about the frequently used articles also exists in the knowledge workers' heads. Imagine a situation arises about an old issue, requiring knowledge that people have long forgotten or those who knew it have left the organization. Having access to the older, seldom-referenced knowledge can be of tremendous value.  But only if it shows up when it is relevant. 

 

symptom.jpgHowever, findability is a common problem as organizations grow their knowledge. Archiving old articles treats the symptoms of findability, not the cause. Relevance is the key. Relevant search results are enabled by a combination of: context, structure, rich environment statements, and search technology.  KCS addresses the first three - the content factors- but it does not address search technology. While search technology can help, it can not overcome deficiencies in our content. If we are having findability problems, the first place to look for opportunities to improve our search success is to review our context, structure, and the richness of our environment statements.  More information about the role technology plays in KCS is covered in the Process Integration section.

 

Some have tried to improve relevance by reducing the number of KCS articles in the knowledge base. This reduction will compromise the completeness of the knowledge. The greatest value from the knowledge base comes from it being a complete collection of the organization's experience and our ability to quickly find what we need when we need it. 

 

This is not to say that knowledge base cleanup and maintenance should never be done. There is definitely a need for ongoing knowledge base maintenance, but it should be done in a way that improves the findability of what we collectively know, not by reducing what we collectively know. Maintaining a knowledge base is like tending to a garden: it requires constant weeding. We have to be sure we can distinguish the weeds from the flowering plants, some of which may only occasionally produce beautiful flowers.  The "reuse is review" and the "flag it or fix it" Solve Loop activities play an important role keeping our knowledge up to date as we interact with the knowledge base. We have to compliment that with a knowledge base maintenance strategy that looks at the collection knowledge in a given domain.  This is an important part of the Knowledge Domain Analysis process and is typically done by the Knowledge Domain Experts (KDEs). 

Viewing 1 of 1 comments: view all
In principle, age and size shouldn't matter. In practice, I think it does a great deal. We give our clients advice that contradicts this (with a disclaimer that we're contradicting the Practices Guide) based on our experience.

It's a nearly universal complaint of KB users that there's too much old, out-of-date content in knowledge bases, and it makes it hard to find what they're looking for. Obviously, this can be mitigated by good Solve and Evolve loop quality practices, but "cruft" inevitably builds up over time. As good as some search engines are, they're not able to distinguish among a cluster of articles that use many of the same words, but where some are current and some are obsolete.

This is even more true of SaaS, where a very small constellation of versions may be supported in the customer base.

We recommend that we take advantage of the "Demand Driven" principle of KCS to archive (not delete) content that hasn't been linked / reused more than N times in M months, and hasn't been viewed by more than X end-users in Y months. (N, M, X, and Y will all vary based on the pace and nature of the knowledge domain, and may vary widely across knowledge domains in a company.)

It's true; we'll likely archive knowledge that would have been valuable once in a blue moon. But the tradeoff is that users will perceive higher quality, more relevant search results, which will make them more likely to follow the solve loop, seek to understand what we collectively know, and avoid duplicates.
Posted 13:49, 6 Jun 2016
Viewing 1 of 1 comments: view all
You must to post a comment.
Last modified
07:46, 2 Feb 2017

Tags

This page has no custom tags.

Classifications

This page has no classifications.