Knowledge Centered Support

During a conference I attended recently, I encountered the concept of Knowledge-Centered Support.

Kaliegh Belda at Western Kentucky University gave a presentation on this topic that turned out to be the hit of the conference.

This concept is taken from IT Help Desks and Service and is one way to think of learning in bite-size, easily consumable chunks that are updated by the people on the front-lines of support – taking some of the pressure off the training team to update materials. The other benefit I see (and that Kaliegh touched on in her presentation) is that the act of writing the article helps her staff become more familiar with whatever tool they are supporting.

An even bigger benefit is the growth of an up-to-date, easily searchable knowledge library for both the IT staff and the university community.

This is, essentially, one of the best implementations of micro-learning I have seen in action.

 

Screenshot of WKU’s IT Help Desk Client Portal.  This particular portal is run off of TeamDynamix Service Management solution.
——————-
Brief notes on how this works (from my conference notes):

• This particular solution uses TeamDynamix ITSM Knowledge Base engine.  You can do the same thing with RightAnswers, or any wiki or knowledge base engine.  Heck, you could probably do this using WordPress.
• All responses to help desk tickets MUST include a link to an article.
  • This is enforced by the help desk management.  I believe they are copied on all responses.
  • If the ticket was a phone call, the help desk personnel still send a follow-up email with the appropriate article linked.
  • If an article does not exist, the help desk person must write one.
  • As part of their process, they still track turnaround time.  I didn’t catch whether they had a way to track time spent writing.  I know they are paying attention to authorship and using that as part of their metrics.
• They created a standard format early on.
  • It made it faster for the author to write the article.
  • It created a fairly common UI for the reader.
  • As part of that format, they enforced tags and created a common library
• There is a review process for each article, but it was a short one.
  • Initially – the help desk person wrote it, then it was reviewed quickly (same day) and published by the help desk manager.
  • Later – they got the experts writing articles as tickets were escalated to them, which were reviewed quickly (same day) and published.  Escalated tickets still had the requirement of having an article attached before closure.  This is done by the help desk staff and is slowly being done by the tier 2 and tier 3 support as well.
    • It was very impressive that she managed to get the engineers to start writing articles.  She admitted, it took some doing – but the engineers started quickly seeing how by writing articles, fewer tickets were escalated to them.
  • Finally – as they found people who were really good at writing these articles, they created a group of approvers.  This allowed the articles to be published even more quickly.

They found that as they applied this technique, end users would start looking up articles on their own, reducing help desk calls. This is a good thing.

—————————
Throughout her session, Kaliegh emphasized “writing as needed” vs “unnecessary pro-activity”.

During implementations, we often find ourselves guessing what the most frequently asked questions will be and creating materials based on these.

Her observation – “What we THINK we will get questions on and what we ACTUALLY hear are often worlds apart.”

I know I spend a ton of time creating materials based on how I and the rest of the project team think the end-user will use the tool.

“Not necessary” Kaliegh argued.

And it boils down to giving our end-users more credit for figuring stuff out.  Especially as tools become more user friendly and as people are forced to become more adaptable to changes in how their tools work on a regular basis.

I admit to a bit of discomfort – only because I get the brunt of the “We’ve never been trained” whining from people who refuse to take responsibility for their own learning.

But she has a point.  I have a lot of materials I have developed “just in case” that have never been touched after the initial implementation.  Either because people aren’t using that feature or the feature is so blindingly obvious to use that it doesn’t require instruction from an “expert”.

And if the search and tagging are done right, the reduction in duplicate effort and the ability to update and refine information quickly would be more than worth it.

With the increased growth in cloud-based solutions built using Agile techniques and the resulting loss of control over user interfaces and features – I think this just-in-time, as-needed approach becomes more necessary.

There is no way the training team can keep up using its traditional methodologies.
—————
The Consortium for Service Innovation has some great material if you want to learn more about this technique.

KCS Principles and Core Concepts

• I would particularly read the sections on Transformation and Continuous Improvement , Knowledge Integration and Sufficient to Solve

KCS Adoption Guide . Though the information is in an IT context – it would be worthwhile to see how this concept applies in more soft-skills and business process contexts.
—————-
BTW – I ran this article by Kaliegh before I posted this to make sure I didn’t misrepresent her or her talk.

If you have any questions, she’s invited you to contact her at Western Kentucky University.
kaliegh.belda@wku.edu

She’d love to answer your questions.

Thanks Kaliegh for reviewing this blog post and for introducing me to Knowledge-Centered Support 🙂