I’m writing because I keep getting so much gmail spam from India. I think that the Teams in India are looking up Seattle IT Consulting and sending spam email to my account, hoping that I’ll respond. I’m happy to work with any company from anywhere in the world, but I’m not interested Continued »
First let me say I like working with Indians. I’ve worked for 21 years as a Seattle IT Consultant working with teams all over the world. Thinking about it, I’ve worked 95% of my time in the Seattle/Bellevue area yet I’ve worked with teams from Russia, The Philippines, Malaysia, China and multiple project teams from all over India. Continued »
SharePoint is not always the most intuitive system. I setup my Seattle IT consulting clients with 365 SharePoint to replace file servers for small businesses. The problem is that SharePoint is just really awkward. What my client really wanted to do was see the SharePoint site like a drive letter on the network and interact with the drive like they would as if SharePoint was truly on the Continued »
Did your parents tell you not to get into art? There’s no money in it? Your family will starve? That’s the way my parents thought. I was discouraged from getting into art. I think though that a lot of things have changed in the last 30 years. As a Seattle IT Consultant I see art everywhere in our entertainment, the Continued »
I began writing about why a configuration or settings document is important for network troubleshooting. In this article, I’d like to try share a basic layout I use. As I’m working with my Seattle IT Consulting clients, I am teaching them how to build this type of documentation. This is just meant to be a base to get you started. Continued »
In other articles I’ve talked about how IT Experts can leap frog their careers by being able to document. As a Seattle IT consultant, I find that the stereotype is true. IT Experts don’t document. They are under a great deal of stress to move Continued »
When IT experts do write documentation, it’s usually a “How To…” document. As a Seattle IT Consulting firm I need my experts to be able to troubleshoot the entire system, not install the system. Topology documents describe the network in a Continued »
As a Seattle IT Consultant, I review a lot of documentation. Not because the clients I work with have documentation, but because I am training technicians to write their own documentation for the first time. Documentation is one of my favorite subjects. I think that a technician can increase their income faster because they are willing to do what most IT experts seem Continued »
As a Seattle IT Consultant, I meet with IT departments on a regular basis. When I ask, 95% of the time there is no documentation on the network. I know I talk about this regularly but I’m working with fortune 500 client who is struggling with this very problem. So I thought I’d talk about this subject again. Recently, for example, Continued »
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.