Are you a member? sign in or take a minute to sign up

Member login
Network Documentation

companyCCreating network documentation is probably the least glamorous (and least exciting) part of any project. At some point customer may become self-sufficient and need information about their network's configuration. And even if customer never becomes self-sufficient, it's a known fact that the documentation useful for a variety of reasons.

Networking Project Guide

Interactive provides comprehensive strategies on building, troubleshooting and securing customer's network.

As our company businesses grow we may no longer have time to service customers personally. In the future, one of our employees may service the customer. Having proper documentation is a best practice that ensures that anyone on our staff is able to service the customer's needs without having to interrogate the customer as to their setup and what our company has done for them in the past..

Documentation is also important from the standpoint of helping us to remember what was done. We have found that having good documentation allows us to review the customer's network. Good documentation also serves to protect us. It's been our experience that once we touch a customer's network, the customer naturally assumes that anything that goes wrong from that point on is related to something we did (whether it actually is or not). The problem with this is that if our customer has a major network crash, they may attempt to pursue litigation against us, even if the crash was not our fault.

What to document

Actual documentation contents will vary greatly depending on the type of job, but here are a few things that might be appropriate to include:

  • A network diagram (network topology, LAN/WAN layouts, etc.)
  • A list of the Network names and IP address scheme
  • Supporting documentation for software licenses purchased, along with documentation showing who the installation disks were given to at the end of the project
  • Receipts for hardware purchases
  • A detailed description of any configuration procedures used (group policy settings, user account configurations, VPN configurations, etc.)
  • The names and contact information of any one that our teams worked with on the project, as well as notes about the roles they played in the project (who approved what, etc.)
  • If our client has invested a significant amount of money in new hardware, we might even take some photographs that we can use as proof that the hardware was given to the client.
  • Provides an easy way to share documents with other office branches or take them on the road. Conforms to the way you work, rather than forcing you to change.


All IET projects involve the production and control of documentation. There will be many types of document with varying purposes, natures, and lifecycles. Of course, most information and documentation will be on paper and its format may not even look like a conventional document. There is every reason to use state-of-the-art ideas and technology to share and convey information as efficiently as possible. The concept of document control sounds very authoritarian and bureaucratic. It should not be seen that way nor presented in such terms. It should provide an efficient way of sharing knowledge, technical information and configurations among the project implementation teams. All participants should find it easy to consult the project's documentation to find all content that is relevant to their work/interests. It should equally be easy for them to lodge in the repository any documented information that they feel is of value to the team. Documentation Control system is closely related to Configuration Management system. In some projects they will be treated as part of the same overall process and toolset. More typically, separate management procedures are applied to documentation and technical components

In terms of project documentation control information, there are four main scenarios:


Consider how these factors affect the requirements for quality, review and update. For example:

  • External deliverables need to be of high quality, whereas internal documents may be informal and incomplete.
  • Permanent documentation will need to be updated as time change, but temporary documentation will usually be left unchanged.

As technical solutions improve, and particularly with Network Solutions, it is increasingly sensible to make components self-documenting, i.e. there is not a separate document to be created, stored, accessed and read the information is directly within the component itself. This is absolutely crucial with business-to-business customer network solutions. It is equally valuable in terms of other documentation and information, for example:

  • Network Analysis, design and development tools should be self-documented.
  • Standards & Procedures for configurations should generally ensure it can be easily understood and followed by Engineers.
  • Teams working procedures can be presented through a workflow system.
  • User manuals and help information can be provided as context-sensitive, Hard copy or through E-mail,

The traditional IET view of Network documentation is one-dimensional - there would be a document to reflect each major stage in the evolution of the project. A better view of the project's knowledge, configuration information and documentation is that it forms a matrix reflecting different types of configuration information, at different stages, for different issues within the overall network solution. There are at least two dimensions in the matrix - the type of configuration information and the aspect of the project to which it relates.


If the documentation has been constructed as a structured knowledge repository, with adequate indexing and controls, this should be easy to achieve. If we have followed a conventional route and produced a single, enormous document to describe the entire design - the team members will be swamped with unnecessary information.

A further advantage of compartmentalising the information and documentation is that items can be released for review, finalisation, approval or action without waiting for other non-dependant elements to be completed. The net result is:

  • Project teams only deal with the content that is relevant to them.
  • They receive it in manageably sized pieces.
  • They do not have to wait for unrelated content to be ready.
  • By restricting circulation of any given information to those people with a relevant interest in the specific content, the complexity factor is reduced.
  • The various elements will arrive at differing times, reducing peaks and troughs in the workload.
Document Management and Control at Project Start

At the start of the project, IET team will only have a high-level view of the required deliverables, so it will not be appropriate to catalogue them comprehensively in detail. What we do need to do is to consider and define how we will manage and control documentation during the project. In most cases we will set up some form of system to control the documents. In a short simple project, it might be as simple as a spreadsheet in which one tracks the main documents. We might personally take control of the documents and transport them using E-Mail or a shared server. .

In larger projects it will be worth selecting a Document Management system. There are many Document Management systems available. As it is a constantly changing and improving market place, we will not attempt to analyze the merits of specific products. Instead, let's consider what functionality we are looking for. Here are some of the functions to look for in a Documentation Management system:

set set

Implementation Process : IET team will be in a position to set up the initial data for project implementation documents. We should now know the planned deliverables and documents. We followed a deliverable-focused planning approach this should be simple; otherwise, we will need to identify the anticipated deliverables, documents and other output products from the plan. We should also define and agree the key details, e.g. formats, responsibilities, further circulation, level of quality review, etc.

It is worthwhile to validate the flow of documents. Within our planned approach:

  • Incoming documentation and information should be coming from somewhere, and
  • Outgoing documentation and information should be used somewhere.

Where possible, we will guide the team members with templates, models or example versions of each document. This will encourage them to follow a preferred format and will help them to understand what is required. Ideally, the templates, models and examples will be chosen by project team, the Project Director and Project Manager, so that we have editorial control over the style the documentation should take.


As individual team members join the project, they will need to be instructed and coached on the use of the Documents. This is one of the many aspects we would normally include in the project team briefing and training sessions at the start of each phase.

Document Management and Control During the Project

Operation of the Document Control System during the project should be made as easy and efficient as possible, but without losing the degree of control and audit that is required. Routine control will often be a responsibility of the Project Director. Other Project managers & team leaders should be able to access, "check out", update, and "check in" the contents, subject to the defined rules concerning implementation process, installation & configuration, testing and all other controls.

The Project Director and/or Project Manager will keep track of document status, looking particularly at:

  • Documents that are not at their planned stage of completion.
  • Documents that are unnecessarily checked out.
  • Completed work where the documents have not been finalized.
  • Competing demands for a document.
  • Participants not working on the correct, controlled version of a document.
  • Adequacy of review, control, quality and audit information.

The Project Manager will monitor the overall status of the repository and deal with issues as they arise.

At the End of Project

At the end of the project, all planned deliverables should have been completed, finalised, approved and distributed. Internal documents should also have been completed, subjected to the defined reviews and finalised. The Project Manager would review the status of all items in the repository. The Quality Audit process would normally ensure that all planned items had been produced in accordance with the defined standards and procedures. Bear in mind that the information and documentation should be flowing out - either into the project's support & future work or as final handing over documentation. We will make sure that all outputs have been directed to the right person/department and will be picked up and used in those contexts.

Items in the project's handing over documentation will be dealt with according to project nature:

  • Installation of equipment & other items will be normally mentioned.
  • Configuration and testing documents will be retained for future use; e.g. in maintenance and support, and.
  • Other deliverables will have been mentioned and must be maintained; e.g. demobilization of our teams, material and etc.

A running Network operations needs are to continue process to manage, maintain & update the all documentation. Before the project is complete, the Project Manager will have established and agreed who will be responsible for which network part & item after discussion with technical team of customer.