This article is also available as a download.
When I first worked on a help desk, there was no facility for sharing knowledge. A team member would work out the solution to a problem and then rely on memory the next time it was needed. If you were lucky, someone occasionally passed along a bit of knowledge to other members of the team. These were the days before Windows and the myriad options and settings that keep us all busy today. Back then, we were supporting the users of a huge IBM mainframe that occupied two large climate-controlled rooms and had the processing power of a rather tired 486.
One day, an end user called with a fault on his IBM cluster controller and wanted to know how to fix it. I didn't know. It was my second day on the job so I told him that I would ask the team. But before I could ask, the caller came up with the solution: "The last time this happened they told me to press the IML button."
I looked this up in the book. "Initial Microcode Load." That looked like a reboot by another name. Remembering the first rule of troubleshooting, if in doubt, switch it off and back on again, I advised the caller to try it. Fortunately this did the trick and the caller rang off happy. I wondered why he bothered to call, as he seemed to know the answer already. I would learn later that this is not unusual; callers to a help desk often want somebody to validate what they already know. When I told the other team members about it, they all knew about pressing the button. I asked if there was any facility for making notes about such simple fixes and was surprised when the answer was no.
We didn't have anything remotely resembling a real knowledge base until our team was joined by a chap called Lenny, who had a habit of writing absolutely every piece of information he acquired in a large ring binder. There was a big section covering each of the applications we supported, where to find serial numbers on all kinds of kit, descriptions of how it was all supposed to work, names of people who worked on the various systems... You name it, he wrote it down. The information wasn't restricted to technical matters, fixes for problems, or how-to's, either. He also wrote down names and phone numbers of any contact, whether it be the pizza delivery service, the local massage parlour, car servicing, sandwich shop, or a cheap lawyer.
When a page became full, he would transcribe all the information under separate headings for ease of retrieval. At this time, there were no PCs in the office; they didn't arrive for more than a year. Until that time, Lenny's book was the source of all wisdom. It was the first knowledge base I ever encountered.
Evolution of the knowledge base
Shortly after this incident, with the arrival of Microsoft Windows and file sharing, we set up the knowledge base as a network folder containing text documents into which we could all enter information. It was crude but effective, a cross between a giant FAQ and a journal.
Later in my help desk career, the knowledge base became much more formalized. The last one I worked with consisted of a fully searchable Lotus Notes database, to which we were encouraged to add any useful pieces of information we acquired. It was the first destination for anyone looking for information. There are specialized knowledge base applications now, but they serve the same purpose as our more rudimentary efforts: the sharing of information. It makes no sense at all to spend time working out the answer to a problem and delivering the solution without recording the information for others to use when similar problems occur.
If your organization is large enough to warrant it, the management of the knowledge base should be in the hands of a dedicated person. This has many benefits, including allowing time to process new articles and properly retire old articles that are no longer relevant. It also gives an independent eye to the work, so that if the meaning of an article is not fully clear (and let's face it, not all help desk techs are great writers), that person can clarify ambiguities and suggest better phrasing.
All through the process, it should be emphasised that a knowledge base article is not written in stone. It's a living document that must be allowed to evolve as knowledge is improved and as technology changes. When I was working in support, we used to achieve bonuses by writing new articles, but there was no reward for updating anything. Consequently, the temptation was to create new articles that sometimes contradicted pre-existing ones. Had credit been offered for significant changes to existing work, I believe that the database would have been more efficient.
10 tips to ensure knowledge base success
To make the best use of your knowledge base, here are a few tips to think about.
- When you learn something new, write it down. Note where you found it, how you fixed it, what the symptoms and error messages were, why it happened, how it can be avoided, and any other useful information. Marshal all your thoughts before writing the article. Ensure that you cover all the steps involved in the fix. Verify that this is the actual fix, not just a coincidence.
- Write articles by running through the process involved, taking screenshots to illustrate the description. Make sure that the article is clear and not too long and that the illustrations are relevant. It might be important to acknowledge the source of both the problem and the fix, in case further research becomes necessary at a later date. Create a template for writing articles, so that all the relevant information is captured and listed in a format that is consistent and easy to follow.
- Make the database searchable. Ensure that the description field contains key information like the error message, the application it occurs in, and any useful extras you came across.
- Check the articles for errors before posting. Sometimes, it's hard to spot your own mistakes. A fresh pair of eyes will notice things you missed. When posted, the article should bear the name of the writer and the date it was posted.
- Check that the article doesn't already exist in a different form. A knowledge base can get overstuffed with duplicates if you aren't careful. If a piece is nearly identical to an existing one, don't discard it. Incorporate any new information into it and credit the writer with an edit.
- If you find an error, note it and get it corrected. Have a quality checking procedure in place. Anyone should be able to submit an article, but it should then go to another person for review, editing, and testing before posting to the live knowledge base.
- Review your articles regularly. Check that the fault has not been rectified by a manufacturer's patch or update and that it hasn't been made irrelevant by progress. For example, you may wish to spring clean all your Windows 3.11 and 95 articles.
- Make sure that everything is spelled correctly. If you search for, say, system.ini, you won't find articles that contain systm.ini. Emphasize the importance of consistency and the dangers of relying on spell checkers. If you have a full time editor/manager for the knowledge base, that person can ensure that a consistent approach to articles is followed.
- When you post a new article, make sure that the rest of the team knows about it. You could have a page that lists new articles or even an e-mail notification system. Having the knowledge base accessible from your intranet could be useful if you want to make the information available to all the IT crew, even if they're at the user's desk side.
- You might consider making PDF versions of articles covering common issues and e-mailing them to end users. But it's important that any fixes you hand out this way have been thoroughly tested, don't compromise system security, and will be helpful to people. To achieve this, you'll need to have a strict editorial process in place to ensure that there are no faults or potential conflicts in using the material.