Now you’re speaking my language! I’m the Knowledge Base Administrator at BCIT, a polytechnic institute serving 50,000 or so students per year and 2900 faculty and staff. Our KB covers a wide variety of topics from logging into wireless, to printing, to using Cisco phones, to using the CMS to publish to the public website, to grades submission, to running Continuous Service Improvement projects, and on and on. We document software, hardware, and processes.
We have two people assigned to each article/document, if possible. One is the Content Owner and one is the Subject Matter Expert. The Content Owner, to start with, is usually the original author of the document. The SME is a sort of back-up - someone to go to who likely has the knowledge necessary to assess whether the document is still current, accurate, and relevant or not if the CO is unavailable, has left the Institute, is on vacation, etc.
I suggest a default review period of nine months for all articles, unless there’s a specific reason to do one sooner than that. Nine months between reviews moves the review through the school year, which may help to showcase deficiencies because of the different contexts that occur. It also is just short enough to catch things before they’re a major problem and long enough to let people feel like they’re getting away with something and really should review that thing now.
We have several different knowledge repositories in various places to deal with different needs, but there’s one record-keeping system that keeps track of all of the metadata for all the documents - what article belongs to whom, when it’s next due for review, and all of the correspondence we’ve had about it. It’s a part of our ticketing system, so we also have it set up so that users can report problems and that can open a task on that Knowledge Article to fix a problem.
When the review date happens, one of two things can happen, depending on who the Content Owner is. If they’re a member of the group with access to the ticketing system, they get assigned a task to review the article which goes into the same queue as all other tasks assigned to them within that system. If not, they get sent an email, two which they must reply.
Either way, I get a notice back from them that tells me the article is either okay as is, should be retired, or needs to be changed in some way. If the article is no longer necessary, I delete it from whichever repository it resides in. If it needs to be changed either I or the Content Owner (depending on the system) will change it. If it’s fine, I just update the next review date and the cycle begins anew.
Sometimes Content Owners leave. Then I have to hunt down a new owner. This is the most fun (read “least”) of all the tasks! People are rarely eager to take on responsibility for someone else’s work. Fortunately, I have an established culture to support me, and people like having the resource to refer people to, so usually it’s not a huge problem. Where occasionally I can’t find anyone, I get to start making ultimatums about how it can’t stay in the repository if a content owner isn’t assigned to it. I’ve deleted a few, but mostly someone steps up.
I keep track of something I call the “Reviewed Rate”. Basically, this is the active articles/documents in the system whose review date is in the future, as a proportion of the whole. Nowadays I try to keep it above 80%, though we once got as high as 90% (that was a red letter day). I think at the moment, due in part to articles coming due over the holidays, we’re around 72%, which means I’m emailing people, especially those that have more than one article overdue or those whose article has been overdue for a while. They get one polite and friendly email to them personally. If they don’t respond, they get a second polite and friendly email two to three weeks later that ccs their manager. That generally works.