The Search for Common Issues
Identifying Common Issues
For this analysis, we are looking to identify a cluster of articles that have the same or similar titles and issue statements for a given environment. So we are only looking at the title, issue, and environment statement fields in the articles.
Group articles that describe the same or very similar issues. Issues may be stated in different ways, and we are looking to identify all the articles that are about the same thing.
Two things emerge as we look at our groups of articles that document the same or similar issue.
First, we will see that we have some duplicate articles for some of the issues. Can these be merged?
Second, we often find that a single issue (or a set of common issues) can emerge for multiple, diverse causes - each of which has a different resolution. For example, “Car Won't Start” could have many possible causes: the car might be out of gas, it might need a new battery, or the battery is not being charged by the alternator (more on this example later). The issue or symptom experienced by the requestor is insufficient to identify the correct resolution. Additional information is needed, possibly requiring diagnostic steps to identify the distinguishing characteristics of the situation in order to provide the correct resolution.
First, we will discuss how to deal with duplicate articles, then we will cover how to create hub articles and resolution paths that deal with generic issues that have multiple possible causes. In both cases there will be opportunities to merge duplicate articles.
Merging Articles
In dealing with duplicate articles there are a couple of considerations.
For simple duplicate articles, we want to consider the following in deciding to merge the articles:
- Are the cause and resolution in each of the suspected duplicate articles really the same?
- Do these articles serve different audiences? If so, having two versions of the article might make sense. Would merging these articles diminish the findability for the intended audiences?
For more complex issues, we may need to build a hub article or create a resolution path. This process will also identify articles that should be merged and/or put in an archive state. Designing and building a hub article or resolution path is discussed below.
For the articles that we have identified as duplicates and candidates for merging, we want to merge the relevant information into the oldest article (the active article) and put the others in an archive or obsolete state. We keep the oldest article as the active one and merge the relevant information, metadata, and links from the newer article(s) into the oldest because we want to preserve a complete history for the issue. Some knowledge management tools have a merge function that make it easy to copy useful content from one article to another and will take care of merging the links and metadata. If a merge function is not available, we may have to manually update the active article with links and metadata, or link the obsoleted article(s) to the active article in order to preserve the history and enable accurate reporting.
Hub Article or Resolution Path?
Hub articles and resolution paths are built in the Evolve Loop. We distinguish experience-based articles (created in the workflow in the Solve Loop), from Evolve Loop or high-value articles which are typically created by a small team of people and facilitated by the KDE.
As a general rule of thumb, we want to have one article address one issue. An article should document one cause/resolution for a specific issue in an environment. An exception to this is the situation of a vague or generic issue that has multiple possible causes. This is where a hub article or a resolution path is valuable. While the structure of these types of articles is the same, the intent is different.
The goal in both of these approaches is to get the requestor or the knowledge worker to the correct resolution as quickly as possible.
- If the qualifying criteria for the correct resolution is simple - if condition A is true, then article X has the correct resolution - this can be done in a hub article.
- If many steps or qualifying questions are necessary to assess the situation in order to get to the correct resolution, then a resolution path should be created.
A Hub Article
Building a specific hub article is useful when there are simple qualifying conditions that distinguish one resolution from another. The hub article lists the qualifying questions/conditions that distinguish a specific resolution as the correct one, and for each condition there is a link to the article with the appropriate resolution. So, a hub article is a list of “if this is true, then this is the article with the correct resolution.” Hub articles act as a kind of article index. They do not contain resolutions, but rather point to articles that contain the resolution based on simple qualifying criteria.
Why have the resolution in a separate article? The hub article is helpful for those who do not know the qualifying condition that would indicate the correct resolution. If the requestor, based on past experience, knows the qualifying condition and does a search that includes that condition, the article with that specific resolution should be on the top of the search results. They don’t need the hub article. Additionally, if we have an article for each resolution, it enables us to do the analysis of frequently used resolutions and accurately identify opportunities for root cause analysis. 
The article with the specific answer or fix should be linked to the incident as the resolution article. We want to know how often each resolution has been used. If we link an article containing many resolutions to a request, we can not easily tell which resolution actually resolved the issue.
Two considerations for the sequencing of the qualifying questions in the hub article:
- If we can tell from historical data that the frequency of use of the resolutions is not equal, the qualifying questions should be in the order of the resolution most frequently used to the resolution least frequently used.
- Consider the requestor effort in implementing the resolution. If there are resolutions that require very low effort on the requestor's part, those are good candidates for the top of the list. High effort resolutions, like "re-install your operating system," should be at the bottom.
These are not absolutes; judgment on the part of the KDEs is required.
A Resolution Path
More complex, generic issues might require multiple steps to identify the correct resolution. In this case, a resolution path is the best approach. A resolution path is a collection of articles that are linked together. The goal is to get the requestor to the correct resolution as quickly as possible. The first article in the resolution path includes the most generic way a requestor would describe the issue and the first qualifying question that a responder would ask. Based on the answer to the first question, the article points to an article with the next qualifying question. In this way we identify all the criteria that would indicate which resolution article is appropriate.
A resolution path is essentially creating a decision tree with a sequence of articles, each article representing one step in the process, and the outcome of that step pointing to the next. However, one important difference between a resolution path and a typical decision tree is that in a resolution path you can enter the process based on what is already known. In a decision tree, we have to start at the beginning regardless of what qualifying conditions we already know.
Resolution paths are best designed by a small group of stakeholders including two to three subject matter experts (SMEs) and at least one person who represents the audience that would use the resolution path. The KDE facilitates the design process, and they may also play the role of a subject matter expert if appropriate.
The goal of the resolution path design team is to identify the optimal way to get from a very generic issue description, which has many possible causes/resolutions, to the appropriate resolution as quickly as possible.
Designing Resolution Paths
Look the group of articles that you created when identifying generic issues with multiple possible causes/resolutions. Identify all the ways this issue has been reported in the most generic way. These issue statements should be used to build the article that will be the point of entry for the most generic way the issue is described by the requestor.
Next, identify all the resolutions that have been documented in the numerous articles for this generic issue. As a general KCS guideline, we only want to include the resolutions that have solved requestor-reported issues. It is tempting to try and include all the imaginable resolutions, but if the resolution has not been used to respond to a requestor's issue, then it is not demand-driven and should not be included. There is an exceptions to this rule: if a resolution has been known to resolve a requestor's issue but a knowledge article doesn't exist (or isn't in the group of articles we are working with), then include that resolution in the list of all known resolutions to the issue. We want to avoid creating clutter in the knowledge base. Presumption creates clutter, demand-driven creation does not.
This is also an excellent time to identify duplicate resolution articles and merge them with the resolution article that is at the end of the resolution path. The same considerations for merging discussed above apply here.
To illustrate this we will use the example of a generic "Car Won't Start" issue. There are many possible causes for a car not to start.
On a large whiteboard or work area, identify the most generic issue/article at the top, and all the possible resolutions across the bottom.
The next step is to develop the optimal path of qualifying questions to get us from the most generic statement of the issue to the correct resolution, based on answers to qualifying questions. It is best to use sticky notes to work through this to capture the questions and sequence as this is always a dynamic discussion; it is iterative and a bit chaotic. A bit of chaos is good. The goal is for the team to agree on a flow or sequence that is good enough to test with the intended audience for the resolution path.
Create Resolution Path Articles
Next, create the resolution path articles. Each question in the path should be an article, and the answer to the question will direct the requestor to the next step until they reach the article that has the correct resolution.
The issue statement for these procedural articles is the qualifying question. The environment statements relate to the product, process, or policy. The resolution field may have directions on how to determine the answer to the question as well as the possible answers to the question, each with a link to the next article in the sequence.
For the purpose of linking articles to requests, the articles that define the qualifying questions are reference articles, and the final article in the path that has the corrective action is the resolution article. If we do not have a way to distinguish reference articles from resolution articles, only the resolution article should be linked. Future analysis of link rates can tell us what resolution is being used most often for this issue.
This may sound a bit overwhelming, but we have found that there are significantly fewer generic questions being asked than we assume. In part, this is because the same generic issue is often described in many different ways. If we make a list of the various types of generic issues posed for any given domain or product area, there are usually only five to seven generic issues that require a complex, multi-step diagnostic process to arrive at the correct resolution.