IT Channel.com
Network design documentation
By null
By Stephen J. Bigelow, Senior Technology Writer
Solution providers embarking on a network design project face an enormous documentation problem. In many cases, clients provide inadequate network design documentation, or no network documentation at all. This forces providers to deliver inaccurate quotes, resulting in wasted time and resources. Other clients may not understand the importance of network documentation, and forego documentation services or squander the documentation that a provider does deliver.
The first part of this Hot Spot Tutorial covered the basic elements of network design, while the second installment discussed robust network design considerations. This final chapter focuses on the detailed (and sometimes daunting) documentation needs surrounding network design projects.
Obtaining and supplementing current network design documentation
 |
||||
|
|
|||
|
||||
Solution providers should obtain as much network documentation as possible before embarking on a design or redesign. The form and detail of any network documentation can vary between clients. Solution providers should expect to have enough information to understand the business requirements for the network; growth estimates for the network; applications running on the network; network storage needs; external network access requirements; remote network access requirements; and network support needs within the environment.
In practice, however, clients often have little to no network design documentation available -- or choose not to share that documentation with providers during the pre-assessment or bidding process. This presents a dilemma for providers who then must make an additional investment in network discovery or risk underbidding the job. "Many consultants lose money on the first job because they don't do enough discovery work to give an accurate quote," said Karl Palachuk, CEO of KPEnterprises Business Consulting Inc. [www.kpenterprises.com] in Sacramento, Calif.
Client server migration is often a "first engagement" for a solution provider, but it's also one of the most complex tasks to tackle. Without adequate network design documentation, solution providers may find themselves quoting a complicated job with little tangible information. Palachuck underscores the counterproductive effects of withholding documentation. "Clients are reluctant to give out too much information before they choose a consultant to do the job," he said. "But that just means they are forcing the consultants to give them bad estimates of the actual job!"
Any documentation presented by the client should be used cautiously. "Even if they have docs, they're often not right," said Adam Gray, chief technology officer of Novacoast, an IT professional services company headquartered in Santa Barbara, Calif. Mistakes may be present in the original documentation, and changes (especially small changes) frequently go unrecorded. "Never trust any work that was done before you. Always double-check the work you're looking at," Gray said.
Some solution providers circumvent potential problems by adding an initial discovery process to the project. "We almost never get any documentation," Gray said. "We typically have to build in a requirements assessment as part of a project. At the end of that requirements assessment, there's a possible scope change based on findings." Any signed contracts should include a clause that accommodates scope and price changes based on assessment results.
There are additional tactics to consider when initial network design documentation is scarce or nonexistent. The first option is to price the job based on time and materials, avoiding the risk of guesswork entirely. Another approach is to document the client's environment for them as a promotional opportunity. "For example, we can do PC tune-ups," Palachuck says. "Then we document everything we see and everything we touch." The insights gained during such initial jobs can help providers understand the environment, find where critical information is stored and so on. Solution providers may rebate some (or all) survey costs as a promotional tool when bidding on the "real" network design job.
Solution providers can use network discovery products and other tools to help speed their assessment or spot-check the details of some documentation. For example, Microsoft's Business and Technology Assessment Toolkit [https://partner.microsoft.com/40025740] helps consultants gather information about the client's environment. There are also many powerful tools that can map networks and analyze infrastructures, such as SolarWinds' LANsurveyor [http://www.solarwinds.com/products/LANsurveyor/].
Delivering network design documentation to the client
A proposal contains a summary of the client's objectives, a confirmation of the project's scope (including a description of the intended architecture and suggested equipment), a description of the intended project (including any assumptions made), along with a phased deployment plan and a diagram of the expected network architecture. There may be additional elements, and the level of detail can vary depending on the project and its complexity.
"We very rarely put any network documentation in a proposal," Palachuck said. All of the meaningful documentation generated during a network design project should be presented to the client at the project's conclusion. A completed network design documentation package can contain considerable detail. Content can include a summary of the project and its individual deployment phases, a detailed diagram of the actual network architecture, executive and detailed deployment plans, a WAN diagram listing geographic locations of all business installations, floor plans for each location, data and voice wiring jack maps, annotated LAN and other infrastructure diagrams, power and cooling details and specifications, and architectural diagrams (if appropriate) showing conduits and other relevant network details.
"The basics would include a network diagram, a spec sheet for each machine including servers and workstations, a description of the IP scheme, a list of all the equipment passwords, and an up-to-date description of the backup strategy," Palachuck said.
The package may be daunting, but the goals are clear. "A client needs enough documentation to completely re-create the client's computing environment in case of a disaster. They also need enough detail to make regular maintenance fast and efficient," Palachuck said, noting an incident where a client was obligated to buy a new firewall because the prior solution provider failed to provide the necessary administrative credentials. A client should expect (and deserves) a complete suite of documentation.
While there are no limitations on the detail for the client, there can be too much information. For example, listings of software components installed on every system are easily generated, but contain little practical information for the client or future technicians. The challenge in producing documentation is to strike a balance between detail, cost and the client's business efficiency. "Ultimately, logical network diagrams won't mean anything to the business analyst," Gray said. "All they care about is that the thing works, it stays up, it's stable, and that it provides the level of service they're expecting."
Solution providers rarely focus their business on developing or updating client documentation. While it's certainly possible, clients are hesitant to buy and pay for a separate documentation package unless they've had documentation problems in the past. Instead, providers include documentation in the current job, and then update documentation as part of subsequent jobs. Managed services may also include regular documentation maintenance as a standard service. Solution providers often chose to retain a copy of the client's network design documentation. This not only provides a duplicate if the client should lose their copy, but it also makes service more efficient for technicians that visit the client regularly.
11 Nov 2008