The Search for Common Causes
For this analysis, we are looking to create a cluster of all the articles that have common or similar causes and resolutions for the same environment.
Different requestors may experience the same problem in very different ways. Despite a common cause, users see diverse symptoms. This situation might be likely in a software environment, where different hardware and software combinations might cause the same application problem to appear in different ways—poor performance in one situation, system crash in another. Requestor perspective or configuration and environment variables might generate very different issue statements for the same cause.
Identifying Common Causes
Look for the same or very similar:
- Environments
- Resolutions
- Causes
When a cluster of common causes/resolutions is identified, the sum of the reuse counts and the value to the business for the collection of articles should be considered in prioritizing the issue. The Knowledge Domain Expert should also decide if the articles should be merged or linked. This exercise is a great opportunity to reduce duplicate articles that add no value, but the key criteria to consider here is findability for the audience that the article serves. While merging the articles has many advantages for the ongoing evolution of the article and aligns with the “one article, one fix” concept, situations can exist where it makes sense to have multiple articles for the same issue. That being said, multiple articles should only exist when there is a compelling reason.
If the issue statements or the environment are dramatically different because of the context of the requestor, merging the articles might decrease findability or introduce some unnecessary doubt in the requestor's mind as to the relevance of the article.
For example, if there is a browser-based app that runs in Chrome, Firefox, and Safari, the issue might appear in different ways in each of the browsers but the resolution is a settings change in the app itself. The resolution is the same no matter which browser the app is running in. As a requestor looking for a resolution, my confidence that I am looking a relevant article is higher if the article I find is specific to the browser I am using and the issue description relates to my experience. It may be tempting to try and cover all three situations in one article, but that makes the article lengthy, harder to find because it will contain content that is not relevant to how I would search for it, and if I am using Chrome, seeing information about Firefox and Safari makes me wonder if I'm in the right place.
When making these kinds of decisions it is always best to think about it from the audience's point of view. How do we get the requestor to the best resolution for their issue with the least amount of confusion and/or effort?
In this case, the articles should remain for each unique requestor context, but should be updated to be procedural. They should include ways to validate the situation, and the resolution field for each should point to the article that contains the resolution. As the resolution is used and improved, it is updated in one place. Whenever possible we want to avoid duplicating knowledge.
