Technique 1.1: Capture Knowledge in the Moment
A major step toward KCS adoption embraces the distinctive, real-time way knowledge is created and shared. Rather than being documented after the fact, KCS articles are created as part of the interaction and immediately made visible to others. The capture process is integral to the Solve Loop: from the first description of the request to the final resolution, the article is built along the way. Even if a resolution is not yet known, the KCS article is made visible to others, especially others working in the same product area. In this way, knowledge becomes a by-product of interaction instead of an onerous and time-consuming additional step. If we are creating articles after the request is resolved, we have missed vital information - and we are not doing KCS!
The integration of the knowledge base into the request-response process (search early, search often) greatly reduces the likelihood that we are working on issues that are already resolved or are in the process of being resolved. Searching is a form of capture.
Context is as important as content!
The just-in-time theme in KCS is one of the things that differentiate it from a knowledge engineering approach. A knowledge-engineering process is characterized by subject matter experts (or technical writers) who write articles disconnected from the request-resolve process. This kind of an "after the fact" process is expensive, slow, and lacks the critical element of "context of use." The only way we have found to effectively capture context is in the moment of use; context cannot be recreated after the fact. Once we know the answer, it is hard to ask the question in a way that reflects not knowing the answer. Context is as important as content.
A research project on diagnostic skills was conducted with a medical doctor and an auto mechanic, both of whom were known to be very good at diagnosing issues in their respective fields. They were asked to write down their approach to diagnosing a problem. Then, the research team observed each of them diagnose issues in a real-life environment. Neither of them followed the procedure they wrote down. They both took cues from the situation and tapped into tacit knowledge to improvise a diagnostic process. They could not access that tacit knowledge used in a real situation without the context of that situation.
As Dave Snowden of The Cynefin Co says, "We don't know what we know until someone asks us."
Most of us cannot provide all the information we have or know until we are asked the right question.
Problem solving is a creative process. It relies on experience, instinct, context, and the successful processing of multiple variables or inputs at once. This implicit information and our ability to link it to tacit knowledge is difficult to explain and it cannot be accessed or extracted if we try to recreate it in the absence of demand.
Tacit information becomes explicit in conversations, often in response to a question or in the context of the need for information. Therefore, when resolving a request, we need to capture the information in the moment. We need to ensure that we capture the requestor's context - their perception of the issue - as well as tacit knowledge as it becomes explicit in the process of resolving the issue. This links what the responder knows with the requestors experience and creates a relevant and complete (findable and usable) picture of the issue.
Clarifying questions help to draw out and validate details that improve the success of interactions. Searching the knowledge base can reveal similar situations and prompt clarifying questions that can validate or eliminate known issues. Finding similar issues helps us remember what we know.
By capturing context-rich information from the beginning, the whole interaction process and article creation process becomes easier and more effective. When another requestor reports a similar issue, we will be better able to relate to the requestor's experience and find relevant KCS articles quickly.