Document, Document, Document
Many in the financial world will often tell their clients that diversification of funds is the best way to ensure that (or these days, try to ensure that) your whole account does not go down with one particular ship. A college professor I had would simply say “Diversify, Diversify, Diversify” as a way to remind we students that diversification was better for investing than unification.
I have found myself thinking about this saying quite a lot lately in terms of managing a network. To help keep everyone on the same page with an update or upcoming change, document, document, document.
This post will look at documenting things within an IT environment and discuss the importance of keeping documentation up to date.
What kinds of things should be documented?
This is a rather tricky question to answer because the documentation for your environment depends on the amount of assistance you or others in your department are providing (even to each other). Any time a change is made to an application, the change should be documented. This helps others who might work on the application see the latest changes that were made and avoid confusion, or worse yet, re-coding because they were unaware the change was being made.
All installations should be documented. This will help the IT staff in an organization keep track of when licenses are used, which users are using the licenses, and which computers the licenses are being used on.
There are likely many many more types of things that can and should be documented, but there isnt enough space here for all of them. Suffice it to say that the more documentation available for an environment or things within the environment, the better.
Document formatting
The documentation does not have to be fancy or bound or even printed and stored (until needed). The most important part of the documentation process is legibility and understanding. If the reader(s) of a document cannot determine what the content is explaining, the documentation is no good.
For example, suppose I have written a document about how to create out of office templates in Microsoft Outlook. The document includes no screenshots showing the reader what is on each screen. Presenting this to a group of users to put into practice might be disasterous. It certainly would not be very helpful.
Sharing documentation
Most of the documents produced will be living documents. The documents will change with each iteration of the environment. Because of this, it is important to share each update to a document with all of the users (in or out of IT) that make use of the document.
It may be beneficial to have a meeting after each round of documentation updates to discuss changes and ensure that all involved users are aware of changes made.
Documentation for all
Most of the documentation that will be produced by the Information Technology staff will be used by employees outside of your department. When creating documents be sure to consider that not all of the users of this documentation are going to be as technical as those on your team.
Where necessary, take the time to review the language of the documentation to ensure that the average reader of the document will understand what is going on. It is a good idea to ask someone outside of your department proof the documentation to check readability.
This should get you started on the documentation path. Remember that there really can never be too much documentation. Document, Document Document. In an upcoming post, I’ll check out documentation specifically for users.
