A Top Initiative for 2004: Knowledge Creation
by Tom Sweeny, Director SSPA Research

Content Creation

As we get started with 2004 knowledge creation should be a top of mind issue for Support managers. Investments in tools, technologies, and process improvements will help to drive improvements in support efficiency and effectiveness. One of the best returns you can find, however, is in harnessing the intellectual capital of your technical staff (Support and other technical departments).

While your list of top initiatives for 2004 may be full, make sure you have room for enhancements to the way that you collect and leverage knowledge through the entire lifecycle of the product. Resources and practices that can be leveraged to develop this content are described below:

Pre Release

Engineering / QA – As the product is tested a number of issues and known problems will be discovered -- most will be considered to have a low impact on customer’s ability to use the product. These issues are often documented in a bug database.

The question is, are these issues worth converting to a formal support KB? The vast majority of issues are not worth the time or effort to convert to a formal support technical note, especially if support and customers have searchable access to the bug database.

Support Readiness Team - Most support organizations have a team responsible for working with Development and Quality Assurance to identify areas of a new product that will generate support cases either due to known product defects and/or new functionality. In these cases the support readiness team will develop technical notes to describe these issues.

Beta Team – Not all companies use customers for pre-release testing, but for those that do there is a wealth of important information about a new product that can be captured and documented.

The team responsible for supporting customers in pre-release testing should be capturing information about problems and questions. Even customers should be encouraged to share a lesson about installation, configuration and usability. Efforts to document topics prior to release should be focused on issues that will not be fixed prior to release.

Documentation Team – The team that is responsible for writing the product documentation (and help files) will likely have some great data about product usability. This does not need to be converted to a support KB format, but should be accessible and searchable by support and customers – ideally through the same KB interface and tool as the support KB.

Product Release

Support – Once the product is out the door, support will hear about the majority of issues. To achieve maximum impact from knowledge activities it is imperative to begin a process of identifying the top reported issues early and get them documented.

The volume of new issues and the speed in which these issues must be documented will often overwhelm the support organization. A dedicated team of support reps to analyze customer cases and document key issues is a worthy investment in time.

Consider reducing the scheduled incident response time (phone time) of some of your reps to help document these issues during the early stages of a new product release.

Engineering / QA – Issues will be escalated to development and valuable information about these cases will be discovered. Engineering and QA should be encouraged to document their knowledge of product issues. It is not always possible to get Development engineers to create KB content.

Assigning a support liaison to Development to keep track of open issues and document notable topics is an ideal way to expedite knowledge transfer from Development.

Customers – Customers are a great source of information and may be a valuable source of KB content. If your customers are willing to contribute content be prepared to manage this resource.

You may find that customers provide a wealth of useful data in support forums. Periodically scanning forums and user groups will provide an indication of top issues as well as some useful data to share within the support KB.

End of Life

Support – As the product approaches the end of its life-cycle KB content for that product should be updated to reflect the availability of new updates and releases as well as techniques and issues associated with upgrading. This can be accomplished by both the general support team as well as reps assigned to help launch the new product or release.

Content Engineering and Administration

There are a number of possible sources for new KB content and each should be exploited. The key to a successful KB is not quantity of content but quality. As new data is developed it must be evaluated for relevance and appropriateness for the intended audience.

Adding value to submitted content is in most cases a full time job by someone with writing skills and technical knowledge. The number of people needed to perform this function is dependent on the volume of new data to be edited and the size of the existing KB to be administered. Some of the editorial and administration activities that should be considered to maintain a quality support KB include:

Add or Modify – As new data is developed it should be evaluated against the existing collection of knowledge to determine if it is unique or similar to an existing KB article. New documents should be edited for clarity and added, articles about an existing topic should be used to modify or replace existing articles on that subject.

Delete – A periodic review of the KB should be conducted to determine if any articles are out of date or inaccurate due to new information. These notes should be removed when identified.

Consolidation – From time to time, a review of the KB will reveal a number of articles that are about similar topics. In some cases the ability to join multiple related topics will provide customers with a comprehensive article about a topic of interest.

Grammatical – Clearly written and well formatted documents make it easier for readers to understand the contents of a tech note. The individuals that create content may have technical expertise, but may not be strong writers. A reasonable investment of time and effort to enhance the support KB through grammatical review and editing may help increase the effectiveness of knowledge transfer.

Classification / Categorization – Some knowledge systems rely on a classification / categorization scheme for retrieval. Once a support KB article is added or modified a review of the classification is required to assure that it can be found when needed.

Linking and Cross References – In some cases technical articles will refer to other issues or activities described in another article, or relate to another on-line resource. The ability to provide a link to that note or file will provide added value for the reader.

Translation – As a final step in the editorial process technical information may be published in a number of languages. This is an important process for global support organizations, but a potentially costly and time consuming activity for support to perform in-house. This is an activity that may be well suited for outsourcing.

The Bottom Line

The value of reusable content is significant. As described in this document there are a number of possible sources for support KB content. Relying on sources outside of the support department is largely dependent on your products, your relationship with your customers and the relationship with the development organization.

The more sources that can be developed for support KB contribution, the better, provided the inflow of new content does not overwhelm the resources allocated to editorial and KB administration activities. Content creation activities must be constantly evaluated to make sure that support is tapping into the right knowledge sources.

To assure continued success of the support KB it is essential to make an investment in good editorial processes and KB administration practices. The bottom line is that up to date, quality information in a support KB will provide high returns.

If you have a question or comment please drop me a note at tsweeny@theSSPA.com.

Thank you,

Tom