I’m not sure why you decided to read this. Nobody sets out to fail, do they? Maybe you just wanted something to read while you had your lunch today. Or maybe you suspect I am being facetious.
But, for the sake of argument, let’s assume that what brought you here is a genuine interest in sabotage. If you want some methods to make the knowledge base project go belly-up, rest-assured I’ve got a few tricks up my sleeve for you:
Start from a blank slate.
Enough said. You fill in the blanks here:
Not that easy, is it? Now build something and expect people to know what the hell they’re supposed to do without setting expectations or providing a few examples.
Draw a Venn diagram: One circle will contain all the names of your subject matter experts. One circle will contain all the people with technical expertise. Now look at the overlapping names and pick only people from your department. Meet with this elite team (affectionately called The Mighty Triumvirate) and set a schedule of alternating Wednesdays and Fridays during each semester when content will be published.
Assume that Triumvirate’s blessed canon is the ultimate authority on campus because you have locked down the content, while in the mean time all the people you rejected have-in true higher ed fashion-circumvented you and published a million other versions of the content via Facebook pages, blog posts, slideshare presentations, departmental and personal Websites, etc. Eventually there is mass chaos, and no best source for information (least of all the Triumvirate’s knowledge base because no one has updated it since 1996).
Be the knowledge base.
Keep answering every question that someone asks you. It’s easier for you to answer it than to show them how to use the knowledge base. If the answer does require the use of the knowledge base, look it up for them. Don’t prepare them for a time when you might be out of the office or at a meeting.