Use the principles of change management to maintain documentation
As everyone who has ever worked in the IT industry knows, change is inevitable in this business. It is only a matter of time—and usually a short time—before significant changes are made to the network environment. Servers will be upgraded, network segments added and/or removed, procedures modified, new employees and offices may be added, and so on. As a result, the network documentation you worked so hard to create will quickly become obsolete unless you develop a serious plan for keeping it up to date. Here are some ways you can keep your documentation current and prevent your network documentation efforts from going to waste.
The key to making sure that your documentation is kept up to date lies in the organization’s change management process. Every IT department should have a formal change management system in place that will allow it to control changes to the network in an organized manner. (See this article for a change management form that can help.) It’s also imperative that managers be firmly committed to this change management process, including keeping documentation up to date. And one or more persons should have job descriptions that include maintaining the network documentation.
The exact procedures for managing change differ widely depending on the size, nature, and culture of the organization. But typically, the process will start with a proposed change, followed by an evaluation of the proposal, a decision on whether to approve the change, and implementation of the change. The person responsible for maintaining documentation should be involved in that process from the beginning.
How the proposed change gets evaluated will also vary from organization to organization. It may involve just a few people, a committee, or even several committees. But in any case, when a proposed change is approved, the next step should be to start updating the documentation to reflect the changes that will be implemented—before the change is actually implemented. This will guarantee that the documentation remains current at all times. This process might look something like Figure A.
Other documentation considerations
When you make a change to a network’s configuration by moving hardware around, it’s usually pretty obvious that changes will also have to be made to the network diagram. But the change management process should also consider how such changes might affect intangibles such as policies or procedures. You may have procedures in place, for instance, for administering a firewall. If you replace that firewall with a new one or add additional firewalls, you should review those procedures to see if they still apply. If not, the procedures will have to be rewritten.
Even without replacing hardware, your policies and procedures, as well as standards for hardware and software, should be reviewed periodically. Over time, an organization’s goals or priorities might change, and you may need to reflect these changes in your policies and procedures. In addition to evaluating proposed changes to the network, reviewing these documents should be a regular part of the change management process. Establish a specific review period for each standard, policy, or procedure—annually, every two years, etc. Within the documentation itself, you should specify the date last reviewed and the next review date.
Finally, don’t throw away your old documentation after you make changes to it. Keep it in an archive. Over time, you will have a historical record showing the growth of your network. That information could prove valuable to someone in the future who needs to understand how the network got where it is.
A never-ending process
Certainly, completing your initial documentation project is a great accomplishment—but it's just the beginning. You will need to protect your documentation from obsolescence. Documentation maintenance must become an integral part of the change management process to make certain that your documentation is always current, accurate, and useful.