Posted by: James Murray
when relevant content is
added and updated.
Long before I became a Seattle IT Consultant, I started at the bottom. About 21 years ago my mentor said to me,
“IT guys never document. If you want to leap frog ahead, practice documenting”
I’ve worked on literally hundreds of networks. Finding a network with strong documentation of their systems is like finding a needle in a haystack. Even when you find someone who has “documented” their network, nobody trained them. So the documentation is often outdated, poorly written and can’t be understood. I’m writing this article to again sing the praises of documentation. The right documentation with improve troubleshooting times, increase the productivity of the technology team and my biggest reason will get you on projects you couldn’t otherwise get on.
So documentation is such a misnomer. When I come onto a sight with problems, the first thing I ask is,
“Do you have documentation?”
Of course the answer is usually no… Even if the answer were yes, a better question to ask is probably, let me see your knowledge base. We really can’t easily define the term documentation; it could anything from emails to topology maps. A knowledge base is specifically designed to organize and manage documentation in a way that supports the IT vision.
Definition: A knowledge base is a special kind of database for knowledge management. The knowledge base is an information repository that provides a means for information to be collected, organized, shared, searched and utilized. It can be either machine-readable or intended for human use. (See Wikipedia for more information.)
A knowledge base may be made up of the same articles written for multiple audiences. A user “How To” document written for a user would be different than and install document written for the technician. A KB articles documenting the troubleshooting process for known issues, is different than the documentation for root cause analysis of unknown issues.
Irrevo, a local Seattle Knowledge Base expert I work with describe several areas most IT companies forget in their knowledge base design.
Quality Assurance – Many IT departments don’t take the time to write a standard. When I first started my IT consulting career, I had a database to clean up. When counting 1;s and 0’s little things like writing Suite, STE., # or whatever the writer felt like, was a serious issue. When trying to filter account information based on something simple like Suite, the report was never accurate. Creating and enforcing naming conventions for templates, checklist and even fields is a small part of the quality assurance process that pays long term dividends as the company grows and the potential for incidents increase.
Analytics – Creating the document is a good first step but many writers lose a good opportunity because they don’t understand how the document will be used. For example: Many ticketing databases leave the symptoms in the text fields of the tickets. The problem with leaving symptoms in a text file is losing the ability to filter tickets for symptoms. Creating a knowledge base means writing documentation systems that can be compared, measured and analyzed to measure trends and enhance management’s ability to make decisions. With the symptom in the text file, the quality of the data depends on the technician’s writing skills and consistency in maintaining standard naming conventions. Without this consistency, management can’t determine accurately, how often a specific symptom re-occurs. Creating a drop down field with pre-determined symptoms for known issues changes the game completely for the analyst.
By learning about the components of a knowledge base a technician can jump start a waning career or leap frog ahead of other technicians that usually get the more interesting projects and opportunities. Being the one person on the team that can created all the documents required means that every project manager will want that person on their team as well. That’s how it started out for me. When I became the manager, I needed technical writers. I also needed my new technicians to quickly understand the network. What better ways than having the new technician learn? These new technicians became responsible for the network knowledge base. They were able to quickly learn the knowledge base templates required to plan, management and measure network service. In the process the technician also developed their own knowledge base , technical writing skills and quickly came up to speed sometimes jumping ahead of the more experienced technicians.