You are hereLearn it, Know it, Show it
Learn it, Know it, Show it
Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it.
If you want to build an IT group of any significance (in what is accomplished), you'll need to start capturing the knowledge that is gained by individuals on your team...
The process is to Learn it, Know it, and Show it. In this business, learning is continuous and most people keep expanding their knowledge--there's always a problem to solve. But it often stops there. Once you learn it, you really need to know it. This means more than "I solved the problem", you need to be able to know it well enough to explain it to someone else. Once you reach that point, you are ready to show it. We do this by documenting what we learned and keeping that knowledge organized.
I started doing this years ago with just text documents written with a text editor that were searchable with grep, some simple forms that were created the same way, and files that could be copied from folders. That was usable, but not terribly user-friendly. Eventually that evolved into what was called a intranet (using internet technology internally to create internal-use-only websites). These could be nicer to navigate and search for the user, but they still needed some pretty high-level skills to keep running and updated.
Times have changed and now YOU don't have any excuse for not using some of the easy-to-use, advanced tools that are available anywhere and anytime, thanks to the internet.
What you need is a single place where your team, even if your team is just you, can go to look for hard-won information that you don't want to have to hard-win again.
I use the same software as wikipedia on an internal server in order to create a knowledgebase that I can access from anywhere. The wiki software lets me (and my team) make changes, upload files, add forms, manage change rights, and create repositories of knowledge so that we can easily find what we want without chasing all over the place. Most of this information I keep locked-up in a secure place so that only staff can see it. Some of it I copy and make public on my website, if it isn't client specific or a security problem.
Here's what I look for when creating a knowledgebase:
* Accessible from anywhere, anytime
* Easy to make changes or additions
* Proper security (user, page, search, view)
* Handles lots of file types (PDF, images, Office)
This usually means a wiki these days, since you can get one for free and have it up and running without the overhead of running sharepoint or something like that.
Here's what I load up on my wiki:
* SOPs (Standard Operating Procedures--how we expect important things to be done)
* How To's (step-by-step recipes for doing something complicated or hard to remember)
* FAQs (frequently asked questions)
* Forms (employee review, time off requests, I-9, W-4)
I add something to the "How To's" or "FAQs" whenever I learn something new or complicated or get tired of answering a question, again. It is especially important to get documented those things that took a long time, couldn't be found with Google, were difficult to figure out, or you know you'll have to teach someone else.
As a rule, I look at our wiki as the one place we can go to find that thing we did or the solution we came up with or our standard ways of doing things. But, since there are exceptions to every rule, I do have two other places information can be found.
One place we sometimes look to find what was done is the trouble ticket system we use. As part of that process, we always document the steps we did to solve the problem. Sometimes, we just want to wrap up the ticket and move on without creating an article on the wiki. This is a judgement call, but since our closed tickets are searchable, if we do a good job documenting a ticket, we have already captured the information we need. The decision to make it an article is usually based on how hard it was to get the information or solve the problem and how likely we think we'll have to find the information. Also, if we find we are repeating the ticket, we would probably make a wiki article about it.
The other place we put things is on the public sites we use. This is one way I give back for the information I've gotten from others on the internet. If the information I found on the internet had to be massaged or reworked or updated, I'll usually post on the board where I found the information and add it to the articles on my site. I'll also post it if I didn't get any help from anywhere, but the information was so difficult to work out or the problem so tough to fix that we were the first to fix it or the first to really resolve it. I'll also post something, if the information I found was way off from the actual solution and I think I can help.
Did this help you? You can help me!
Did you find this information helpful? You can help me back by linking to this page, purchasing from my sponsors, or posting a comment!
+One me on Google:
Follow me on twitter: http://twitter.com/mojocode