Introducing The Content Health Practices
The Content Health Practice consistent of eight techniques:
- Article structure
- Article lifecycle
- Content Health
- Managing KCS article quality
- Creating Evolve Loop Articles
- New versus Known Analysis
- Self-Service Success, and
- Assessing the value of articles
Let’s look at the first technique KCS Article Structure.
Knowledge Article Structure
Content Health begins with the Content Structure. A well-defined structure is a fundamental element of capturing knowledge value. With KCS, the support organization’s experience, or knowledge, is captured in the form of KCS articles. KCS articles are transferable units of content that integrate the situation with information, analysis, and a resolution to form a standardized structure. KCS is a modular approach to knowledge. Ideally, KCS articles should be know longer than one page in length. A given customer situation may use multiple KCS articles to reach resolution. KCS articles often contain links to other more formal or comprehensive information.
Content Health begins with the Content Structure.
Findable and Usable Knowledge
We need to start this process by establishing a good format or template for our KCS articles, the right structure ensures that KCS articles in the knowledge base are findable and usable by the intended audience. Identifying the intended audience is important because the audience defines the context for the KCS article. Ideally, the target audience should be involved in creating and giving feedback on the KCS articles.
The audience defines the context for the KCS article
One of the key goals of KCS is to capture the context of the issue: the description of the needs and experiences of the customer in his or her own terms. To achieve both broad reuse and relevance, the reusable context for a given situation is contained within the KCS article and does not require an outside reference. The complete context is also available via links to the cases that have reused the content.
Structured For Reuse
KCS recommends that Knowledge Articles be presented in an easily skimmed way so that readers can quickly gauge relevance.
The proposed KCS structure contains these basic elements:
• Issue (problem or question): Capturing the situation in the customer’s words—trying to understand; what are they trying to do, or what is not working?
• Environment: What product(s) (hardware, software, network, including the platform, model and revision level) does the user have? Has anything been changed recently, such as upgrades, additions, deletions? The environment description should be as precise as possible, with standard ways to document product names and versions.
• Resolution: Contains the steps required to resolve or answer the problem.
• Cause: Describes the underlying cause of the problem. The cause is also central to providing actionable product feedback to development and product management. Many times the cause is not known, and that is useful information to know.
• Metadata: This is the Organizational, historical, and categorization data that shows whether content is in the right general domain, as well as state, and usage information that helps would-be users understand how often a KCS article has been reused (this can indicate a level of confidence in the article) and finally its stage in the development life cycle.
This format and these content elements can work for procedures as well, not just product issues, questions and problems.
Don’t Capture This Information In Knowledge Articles
Typical case or incident records might also contain information that is customer-specific, such as entitlements and customer contact details. This information is only necessary for each specific support request generated in the support process, and is typically retained in the incident management system; it should not be included in the KCS article. The KCS article contains the reusable parts of the experience, not customer-specific or proprietary information.
A Word Of Advice For Managers
Managers should note that structuring KCS article content requires explicit work to be performed that has not traditionally been part of the problem-solving process. There is an initial learning curve and start-up investment as content is created and the processes are mastered. Coaching is crucial at this stage. However, once reuse becomes possible and Solve Loop practices become second nature, this extra work disappears. The time invested to get “over the hump” will be more than compensated for by the time saved in the improved problem-solving process and increased reuse.
A simple, high-level categorization of content can really help with findability, maintenance, reporting and other processes. Generally, categorizing content with a high-level area or product groups does not take any extra time during capture and does not cut important results out of searches. KCS recommends some specific metadata to enhance a KCS article’s structure and support reuse.
Some examples are
- Date created,
- Date last modified,
- Number of times used,
- Last modified by Person and Team, and
- Life cycle state (which will be discussed further in the next technique).
In addition, there are some specialty pieces of information that enable reuse by other engineers and customers, and some specific meta-data can even help accumulate management metrics. Organizations should feel free to add custom or optional fields to suit their industries or regulatory requirements, but a word of caution—sometimes people go too far, over-structuring knowledge with metadata. They try to put knowledge into buckets, especially to facilitate reporting. Unfortunately, this approach sometimes camouflages the knowledge because of the labels or categories chosen. These manually classified labels have proven to have poor searchability — they do not correspond to the way customers describe their problems.
Predefined buckets also may limit a team’s ability to detect patterns of use and linkages, an ability that becomes more critical as a knowledge base grows. The good news is that tools have improved tremendously. Over the last five years, automated classification and search tools have made it much easier to organize content based on what that content is, rather than forcing it into predefined buckets.
Content as shown in KCS Version 5.3 Knowledge-Centered Support Practices Guide (2012) S3 [9.1-7,10]. KCS v5.3 was written and edited by Melissa George, David Kay, Greg Oxton, Rick Joslin, Jennifer MacIntosh, and Kelly Murray.
The entire suite of KCS topics is available in one location for FREE via my KCS video book/training course. These are designed to guide interested people through the entire KCS concepts and practices, as well as provide evidence of understanding for those involved in a Knowledge Centered Support program of work or implementation. All you need to is register!