Quality over quantity

[RogueFader]

Hello again people.

Another question...so having been thrown in the deep end with managing the knowledge process, of which I've zero experience, I want to review what we currently have, as it seems that the majority of the organisation doesn't' engage too much with it. I would have at least expected more engagement from 1st line teams using and linking knowledge to incidents, and more knowledge creation from 3rd line teams.

I suspect one issue is finding knowledge, so want to look at what we have, and look at the quality in general.

I want to retire all published KBs that are 2 year old with less than 10 views, a large number have 0 views so no value there.

I've limited the number of templates available, I think we had about a dozen, this is now down to about 5, as I suspected people were confused what to use when creating knowledge.

I've requested a default font and size for all knowledge articles, to ensure consistent formatting.

Meta is added to ensure searchability.

Before I hit the bottle of lafite and pull my remaining hair out, I was hoping to get a bit of a steer from those more wiser with the process or procedures about what they have in place for quality of data/KB, any automation etc...?

Thanks again in advance.

[Kim27]

Congratulations! You are now a knowledge manager. ‌‌ Your journey is very similar to many of us who woke up one day and discovered a steaming pile of knowledge articles was now ours! 

Make sure you don't work in a silo. You need allies early on so the more you can partner with the owners and consumers of your knowledge, the better off you will be. It's so easy to want to make changes, just make sure you are aware of the full impact your change will bring. Here are my thoughts.

Take it slow. Don’t try to “fix” everything all at once. Take time to understand the “why”.  Understand and get agreement on what is trying to be achieved. What are the outcomes? For example, "reducing ticket time" is an outcome that can be achieved by increasing knowledge use.

• How will you measure success? 
• Why isn’t the current KB isn't being used? Are there knowledge gaps between tickets and existing articles? It is worth watching the team work tickets. You will learn a lot about what sources of knowledge they are using. I bet you will discover a OneNote or SharePoint site with knowledge maintained outside of the KB.
• If possible, work with the article owners to get their feedback on "unused" articles. If the team isn't following the behavior of attaching articles, maybe they are being used but it isn't showing up in the data (see next bullet!) In addition, if the content would benefit from a quick update and additional meta to make it more usable or findable, you may not need to retire it. 
• Make sure to understand the various SN tables and how they calculate view count. See https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0693819
•  Are you familiar with KCS? This will have a lot of information for article quality, templates, etc. https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide

Best of luck to you. We have all been there.

[Aga_Sznajder · Accepted solution]

This is quite common issue, especially when working with 2nd/3rd liners, as their usual story is they are too busy to create any articles.

What I would look into:

• They certainly have some information stored somewhere - identify their to go places (SharePoint? OneNote?) and point out weak points of those -no workflow, no control over content, no user feedback, no continuous improvement. 
• Explain, why it is not so smart to store their knowledge outside of ticketing tool, using all the "pros" of having tickets, articles, reporting, portfolio or service catalog in one place
• Set up clear workflow - I am using ownership groups to ensure content is managed by experts, I also use one step approval, so that senior members of teams can review anything before it gets published or retired.
• Set up review process, where articles, which have not been recently updated, are reviewed once a year, with monitoring via dashboards, notifications, even escalations to managers, if needed. In IT I had 6 months review period due to very dynamic environment, but sometimes it's ok to go for annual.
• Think about building self service page for customers, it might be a great opportunity to lower the number of tickets hitting teams.
• Do they create content for 1st line? If yes, start looking for those tickets, which have bounced between teams over 5 times (probably no one knows, how to handle those), monitor breached SLA (again, maybe these got stuck due to knowledge gaps), monitor most frequently raised tickets, which could be easily solved via self help. These all are great candidates for knowledge
• Set up creation of articles from solved incidents - this allows to quickly patch knowledge gaps
• Create KM dashboards, monitor articles created by group, most useful, with highest rating
• Create feedback tasks for feedbacks, low rating, flagged as not helpful - these tasks should go straight to ownership groups
• Ensure Change Management and Problem Management deliver updates to existing knowledge, create articles from lessons learnt, from workarounds etc.
• Talk to team managers and suggest using number of created articles as part of monthly performance review - or think about some motivation for most active creators

In general yes, quantity is not as important, as quality, which should always be your main focus, but it is good to cover all recurring incident types with information, mainly for new joiners' and self service's sake.

Certainly in case of major changes to customer's environment the number of articles will grow rapidly, while during the stable months it will be at low level. That is natural as well.

[RogueFader]

Thanks for your response. Can I ask you about your comment about setting up a clear workflow. Currently where I work, where an article is to be published, the author will publish, it moves from drafts to review, its' at this point that I will review, ensure quality checks and if happy will approve and it moves to publish. If authors want to retire anything they're free to do that, it then comes to me for 2nd stage approval where I can approve it to be retired. Thanks

[Aga_Sznajder]

So workflow is ok, though I would also require some technical confirmation for both publishing and retiring content. I am not sure, if Knowledge Manager is the best person to confirm content reliability and quality of everything in the base - I wouldn't, as I work with finance, HR, marketing and other teams. I would rather perform random quality checks myself, but content should be confirmed by a specialist in the matter.