7.
Documenting IT
The most commonly
overlooked aspect of IT is not the technology itself but the documentation
that goes along with it. How often have you tried to re-establish
functionality in a particular application after installing it on a new
computer? Or simply run into an issue that you didn’t remember how to
resolve? Usually this happens at the most critical times and when the
issue to be resolved is a critical success factor for the task at hand.
Many times the configuration documents for hardware or software components
are not current or, even worse, don’t even exist. This leaves many
companies at risk that the knowledge about their production computer
environment is concentrated in one person’s memory, the Systems
Administrator’s. Needless to say that this can create major obstacles
when personnel changes or vendors or service providers need to be
replaced.
But,
it can be pretty frustrating to flip through pages and pages of
documentation without finding what you’re looking for as well. Not to
mention the cost associated with the creation of the documentation and the
inability of the average business owner to assess whether the stack of
paper produced was worth the money.
Regardless
of whether you produce the documentation yourself, have someone in your
company prepare it or the service provider generates it, you should know
the following: The key to good IT documentation is in knowing what
should be documented, for what
purpose and in what form.
The
form is really the key to finding what you need when you need it and to
transfer the knowledge from one individual to another. Think about the
documentation for your computer environment in the same way you document
the processes and procedures in your shop. You want to have a high level
table of contents that expresses, in understandable terms, the scope of a
particular subject. Make sure the information is structured in general
terms rather than technical mumbo jumbo. Use terms like “Workstation
Email Software Configuration Procedure” instead of “POP3 Client
Setup”. This will greatly improve your ability to find what you need
because the documentation package can get rather substantial even if you
just stick to the basics. The
table of contents should include sections organized by topic. You want, for
example, a subject that is labeled “Email Delivery System” and focus
areas underneath this subject that talk to the different components like
“Workstation Email Software Configuration”, “Mail Server
Configuration”, “Firewall Specifics for Email”, “Email SPAM
Filtering” and others. Of course how you define these subjects and focus
areas is up to how you think they will be most usable. Typically you want
to keep troubleshooting related information closer together. In the
example above, I included firewall configuration specific information
because it directly impacts the functionality of your email delivery and
you may need to find this information while you troubleshoot it.
(read
on ...)
Copyright (c) 2008 by In Scope-Solutions,
Inc.
|