• Most knowledge/content systems become “overweight” after the initial honeymoon period of 9 to 18 months.
  
• Companies who have adopted knowledge-based strategies are moving to a more sustainable model of knowledge management (KM) enabling the content to provide operational benefits.
  
• There’s a list of key symptoms that can be used to determine if content bloat exists.

To create a sustainable knowledge-based operational environment, you must integrate a “normalized” structure in the KM system either at the beginning of your initiative to prevent the problem, or as a knowledge makeover project to correct the problem when the symptoms appear.

What is a “normalized” structure?
Normalization is the process of reducing the components of the KM system to their most discrete elements and then configuring and structuring the elements to provide an optimal result. The main components include content, process, people, and technology. This article focuses on the normalization of knowledge content. A normalized structure includes:

• Information — the basic concept to be communicated.
  
• Logic — the relevance path connecting a perceived need to the appropriate information.
  
• Context — the relevance parameters connecting the appropriate information to the stakeholders.

In most KM systems, the focus is largely on the information (seeding it, reviewing it, categorizing it, etc.) and making it accessible, accurate, and presentable. That usually includes a concerted effort to develop context to help people segment information and make it easier to find and use. Context is part of the “tacit” knowledge (i.e. the expertise, perceptions, experiences, etc.) in people’s heads that makes specific knowledge meaningful.

Although there have been significant efforts to capture tacit knowledge by getting information out of peoples’ heads and into a knowledgebase, the effort typically falls short. Most people aren’t wired with the level of awareness that allows them to capture the customers’ context (i.e. using the customers’ language and defining their operational environment). If people could realize everything that influenced their thoughts while they were interacting or even what was being expressed by the people they were interacting with, we would, as a society, really be able to understand each other. But we can’t deliberately capture context well enough to sustain a system. We have to create the context by emerging it rather than by capturing it — and the way to emerge it is through the normalization process.

Can’t we just clean up and categorize?
Cleansing and categorizing the content has a short-lived benefit. It’s like restarting your KM initiative, which produces the honeymoon effect. There are initial gains because you’ve fixed a symptom like people not being able to find what they’re looking for. When you clean up the content, those people start finding more answers and solutions. Eventually though, the system regains its bloat because you didn’t address why you ended up with content that wasn’t useful and easy to find. You might think it’s because you didn’t do enough training, or enforce enough of a workflow, or have a standard to promote good content. What you need to realize is that the system that produced the training, workflow, management, and standard hasn’t changed.

A typical curve of performance looks something like this:

• Initial productivity Usually assessed by the average number of cases per Support Engineer, which varies between high and low complexity problem areas.
  
  
  
• Project Adoption Productivity goes down a bit during implementation.
  
• Ramp-up Benefits become apparent in pockets (i.e. some people in some areas) as Support Engineers start to use new or cleaned up knowledge.
  
• Plateau At the point when the content would normally be expected to reach maturity and deliver consistently high levels of benefit (normally a reduction of 55 % to 83% improvement in overall resolution time), the system instead starts to level out. It may continue to show pockets of benefit for a small percentage of the population.
  
• Degradation The majority of people create coping mechanisms or procedures (i.e. use of favorites and short-cuts instead of searches, linking to generic/similar content but not using it to help solve the problem, creating content which results in duplicates) because the right content is too hard to find.

This is particularly common in areas where people are tasked with solving complex issues. The problem isn’t poor-performing technology or the problem complexity. The problem is content is managed as separate content objects — not as a network of interrelated knowledge.

Normalization can be done in a way that integrates logic into the information. That enables the system to relate and differentiate relevance (i.e. the user can tell if what he sees is related to his need and what isn’t instead of having too much information marginally designated as relevant). In general, businesses haven’t done enough to integrate the necessary logic. The way people have primarily addressed the logic of a situation is to:

1. Embed the logic in the information as resolution or as diagnostic steps (this makes the info static).
   
2. Create separate things like templates for identifying a situation, troubleshooter web pages to walk someone through a logical procedure, and separate tools for applying tests or diagnosis.
   
3. Ask people directly when a situation needs to be analyzed.

These three approaches have limited value because they don’t reduce physical resource dependence and they create a fragmented workflow that doesn’t enable shared learning. When the logic of a situation isn’t integrated into the information access process, the user has one or more of the following experiences:

1. The user cannot find what he/she needs
They may not express what they are looking for correctly. Most people are used to keyword searches and don’t express their needs fully. It might also be that what they’re looking for isn’t there. Even though most KM tools show what the user is looking for and whether they found it, the tools can’t tell what the user should have been looking for.

2. The user finds something but they don’t know if it’s what they need
The user then either doesn’t give us feedback or they want to keep the issue open until they can prove to themselves that they got what they needed. In both instances, you incur costs because you can’t focus on what makes them happy or on new issues. The user doesn’t build the level of confidence that instills loyalty and commitment.

3. The user finds what they’re looking for and believe they have what they need
In 8 out of 10 support issues sampled out of several hundred, we found the same problem being resolved in different ways and many of them were wrong according to the experts. This means you think you resolved the issue, but the issue is simply masked and resurfaces or you create even more confusion and cost as people solve things in inefficient ways which often results in crises situations and compromised learning.

What content structures work?
In most environments, you can’t establish a one-to-one relationship between a customer need and a solution because the relationship between the two is too complex. For example:

• Error messages are ambiguous — In a lot of cases, the same error message is used to mean different things or different error messages could point to the same problem. Therefore, using error messages doesn’t clearly define the path toward resolution.
  
• Experiences vary — The way people describe a problem varies and one problem can lead to another. The result is no clear relationship between symptoms, problems, and causes.
  
• Words are not discerning — The same word can mean different things in different contexts. Sometimes the product is a part of the problem; sometimes it’s the environment, and sometimes the problem occurs as a result of two or more products interacting. Content is not relevant by words alone because the relationship of the words to the context has to be established.

There has to be a many-to-many relationship enabled that narrows the path toward the right knowledge, reconciles perceptions and verbiage, and doesn’t expect problems to neatly fall into one category or another.

These logic/resolution paths are created much like road systems. Like road systems, the paths don’t get everyone where they need to go (some people may need to go off-road to get there) but you have to ensure that at least 80% of the traffic gets to where they need to go quickly, confidently, and safely. You also must ensure the road is maintained and doesn’t create gridlock and accidents. The high level steps are:

1. Record the traffic patterns
Look at the level of demand for a geography/product area and collect a sample of critical mass and real-time load relevance. From that, you can determine what issues likely represent 80% of the traffic and project how much work would be involved in creating a normalized content structure and the projected level of impact you can expect.

2. Topology mapping
This is the overall relationship of environments, context, problems, and references used (i.e. where are people trying to go and where are they coming from). Developing the context frames and mapping can take as little as a day or more than a week depending on the complexity.

Intersections and merges
You can develop the content structures and form the logic paths from existing content. Each logic path can be comprised of a number of content objects and each typically has a significant level of redundancy with others so some of each path is reusable. The content objects aren’t hard-wired (i.e. hyperlinked or embedded) into the path. The logic is created by differentiating the defining parameters and the order in which they should be considered to determine if the user is going down the right path (an example of the path structure will be published in part 3 of this article).

Test drive
The resolution path must guide users in their thinking to reach their destination with meaningful road signs. Users should not have to redefine what they’re looking for and the correct path should be obvious. A test user should validate the path using all the interfaces that might be engaged. These usually include internal and external search tools. This effort is usually conducted over a four- to six-week period and should be done in two product areas to gain the necessary level of experience.

How’s it all work out?
Although dedicating two experts over a period of four weeks is demanding, it’s much less demanding than training dozens or hundreds of people to create useful content or address demand from users who are calling with problems that have been solved. Whether the content exists or needs to be created, the process can deliver dramatic results. Typically, we see these benefits:

• Time to closure reduced by over 50% .
  
• Even when the reason for a long closure time is customer confidence, the closure happens quickly because there’s confidence in the resolution process.
  
• Reduced escalations because the person using the content can understand why it’s relevant and where the process is going
  
• Increased relevance because the right paths emerge for users.
  
• Decreased bloat.

A normalized structure for your data can help speed you to faster problem resolution and happier customers. The next article in the series will provide more insights and directions for developing a path structure.

About the author
Livia Wilson is a principal with OutSights, Inc. (OSI), a management consultation firm. OSI helps organizations implement new customer service programs and specializes in system design to deliver services more profitably, effectively, and leverages knowledge to benefit customer support organizations and their customers. The ability to translate complex service struggles into service solutions is an unusual and desired skill. This competitive edge allows OSI to empower clients with new knowledge, making them feel significantly more comfortable with the numerous service environment activities they manage.

For more information about Knowledge Normalization services and how to get started, please contact OutSights associate Farrell Dessert at 913-651-6424 or email fdessert@outsights.com.