Back when I was first exposed to KCS, in 1998 or so, it was very principles-focused. Perhaps this is a polite way of saying, we hadn’t yet figured out very specific guidance to give support organizations, so we talked in generalities: “align to demand,” “migrate content towards the users,” and the like. It’s all good stuff, but not very actionable.
Starting with KCS v3.0 in 2003 and continuing today with KCS 5.0, we’ve made tremendous progress in documenting a body of practical advice for KCS adopters. But sometimes specific advice isn’t enough to cover the interesting situations our clients find themselves in: being an insurance company with content regulated by all 50 United States, for example, or hiring a new temporary workforce every year. At times like this, it’s important to seek guidance and inspiration from the principles.
Photo credit: iStockphoto.com
Here’s my take on the ten big ideas behind KCS:
- No incremental effort: it’s done in the workflow. The most fundamental principle is that “KCS isn’t something we do in addition to solving problems; it becomes the way we solve problems.” It’s fundamental, but still uncommon. Technology often gets in the way. And, sometimes individuals don’t really force themselves to capture, structure, reuse, and improve knowledge during the case. In the workflow is a little like touch typing, in that it’s pretty tempting to cheat while you’re learning, but if you take the time to really learn, the long-term benefit is tremendous.
- Structure: let go of the words. Technical writing isn’t the goal; the goal is streamlined, simplified, and structured facts and actions. We want less Homer and more haiku, less James Joyce and more Sergeant Friday: “just the facts, ma’am.” Don’t tolerate brain dumps, and encourage those who don’t think they’re writers. KCS doesn’t want writing; it wants people to communicate with words. That’s a big difference.
- Learn with every case. What a loss it is if the only thing we’ve done when we close a case is to help that single customer! If we’re capturing, improving, and reusing all the time, we’re continuously learning, helping us help future customers, too. As a support engineer once proudly told me, “I’m solving customer problems while I sleep!”
- Make tools support the process. This seems obvious, but when you have an enormous IT project that’s behind schedule (and aren’t they all?), they may not want to hear that their publication workflow doesn’t support KCS practices. Get in front of the technology implementation; be agile, delivering the most value and exposing the most risk early on; and make sure that KCS isn’t a slave to poor technology decisions.
- Invest based on demand. Capture everything, but promote and improve selectively. Some early KCS advocates made you feel like you were doing something wrong if you worked on knowledge outside of the workflow; modern implementations take a more balanced approach and recommend that resolution flows, videos, process wizards, self-healing tools, and other value-added (“Evolve loop”) content be developed when capture-in-the-workflow (“Solve loop”) content goes viral.
- Certify based on proficiency. If you don’t have a real certification program with teeth, how can you be confident your users will all do a good job? Certification should be hard to achieve, and it should require sustained good performance to keep.
- Use coaches for change. Peer coaching is an essential enabler of KCS, and if you don’t have an effective coaching program, it’s unlikely you have a strong certification program, and it’s unlikely people are capturing in the workflow. Training without coaching isn’t sufficient.
- Share the measures. As we recently posted, we all want to know how we’re doing. Take advantage of this human desire to drive performance.
- Track, trend, and analyze activities. This is a positive way of saying not to put goals or quotas on activities. This doesn’t contradict the previous principle about sharing measures, by the way: share the data, but make sure everyone understands how you’re using it, and that activity isn’t the same as quality or value.
- It’s a program, not a project. There’s no end date.
We’ve been involved in some out-there KCS implementations, and of course no two are alike. But every effective KCS implementation I’m aware of has implemented all ten of these big ideas in some way or another.
How about your KCS program?
ps – Coming to TSW in Vegas? Consider joining our workshop there, or in Chicago in October.
