SOP: The Network Documentation Binder

The Network Documentation Binder is exactly what it sounds like. Originally, this was simply something that emerged from the way I ran my consulting business. Then it emerged into the Network Documentation Workbook. After that, we literally used that workbook and the forms in it to maintain our clients’ networks.

Find out more about the Network Documentation Workbook at www.networkdocumentationworkbook.com.

Here’s the sad truth about documentation in our industry: It sucks! There are 948,253 different ways to document a network. And 99% of the time, that documentation is either in the head of the technology consultant or in the possession of the technology consultant.

That information belongs to the client. The client should have a copy. The copy at the client office should be up to date. If you’re a small shop and you personally die or are incapacitated for some reason, the client needs to be able to hire a competent technician and that person should be able figure out the network VERY quickly based on the documentation.

That almost never happens. I can honestly say that we have seen exactly ONE well-documented network with a new client since I went into consulting full time in October of 1995. One.

All the other networks – hundreds of them – had either zero documentation, very poor documentation, or some amount of poor documentation maintained by the owner or onsite IT person.

Here’s the most interesting change in the last twenty years: Consultants have gotten better and better at tracking these thing. We have tools. We have resources. We have a PSA and SharePoint and OneNote, and all kinds of cool stuff.

But we haven’t been good at making sure the client has a copy of all that stuff. Even if you have an awesome system for documentation, you need to make sure that you print it out and give it to the client at least once a year.

Holding Documentation Hostage is NOT Job Security [Rant]

This is one of my absolute pet peeves. I hate the fact that our industry is filled with people who think that they might keep a client because the client doesn't know the passwords, the configurations, the warranty information, etc.

Time and time again, we have acquired new clients who had zero documentation. Many of them could not get the passwords from their old I.T. consultant. The consultants literally refused to give the client access to their own equipment.

This is a favorite rant of mine. Why don’t these consultants get sued all the time? How come clients never have their attorney write a letter simply stating that the client has paid all their bills, nothing is in dispute, and the client owns the information stored by the I.T. consultant?

It doesn't have to be a nasty-gram. The letter can be very nice but stern. But it never happens. Ever. Ever.

We have had clients pay us thousands of dollars to crack into their systems and then re-document them rather than face off against their former consultant. This is beyond my comprehension. (It does, however, give me a level of confidence that I won’t be in a lawsuit. If they’re not going to sue someone like that, they sure as hell won’t sue someone who is conscientious.)

Anyway . . . remember the context here. Keeping passwords secret and not giving the client access to their own documentation was not a successful job security strategy for 100% of the “other” I.T. consultants we followed.

When a client has decided to find a new consultant – for whatever reason – the client is about 90% gone. If they no longer want you for their tech support, they will leave. And my experience is that they will pay large sums of money to make that happen. So hoarding some passwords won’t do you any good.

One of the reasons I wrote my first book, most of my intervening books, and the this four-book series, is to raise the quality of service provided by technology consultants. Keeping passwords and bullying (former) clients is childish and unprofessional.

The client has paid for the hardware, the software, the installation, the support, the maintenance, and the wires in the wall. They own it. Every bit of it. Unless you have a HaaS agreement (hardware as a service), you own nothing.

That means the passwords belong to the client. The configuration information belongs to the client. The configuration backup files belong to the client.

Be Professional!

What’s the most professional way to handle all this? Do the best job you can of documenting the client’s systems. But make sure the client gets a copy at least once a year.

In fact, I recommend that you send someone to get a photocopy of the client’s documentation binder once a year and put it that into the PSA as a PDF document.

When you lose a client, graciously make sure all of their documentation is up to spec. Print it out and update their binder. And then hand it to the owner with a stern warning: Let the new I.T. Consultant use this, but never let them take it out of the building.

We had a client who left us for two years and then came back. They were with us for ten years. One of our people had a disagreement with their new front office manager, and the owner decided to side with her office manager (which is probably the right thing to do).

Anyway, they fired us and hired someone else. We created a service request to make sure all the documentation was up to spec and perfect. After all, if we leave with class and style, we might just get invited back some day.

Just at that time, one of our employees decided to spread his wings and go work for a larger organization. Well, he ended up working for the company that had taken over our client.

When we met up for beers shortly thereafter, he reported that there was zero documentation of the site. The new company had removed the network documentation binder and put nothing in its place.

In fact, the new company had a manager who believed that his personal possession of this kind of information gave him power and job security. So no one could touch a router except him. No one could touch Active Directory except him.

It was, in Josh’s opinion, a huge step backward. I agreed.

After two years, the client came back to us and we re-created all of their documentation. Plus we made sure they knew that they need to guard and value that documentation as a valuable resource.

The Network Documentation Binder – NDB

[End of Rant]

I went through all that to make the point: Documentation is important. In fact, it is central to what you do. Look at this four-book series. It’s all about documenting your processes and procedures. Time and time again we talk about documenting client systems.

Documentation should be the one thing that differentiates you from the competition. What you do. What you see. Everything.

So the Network Documentation Binder – or NDB – evolved out of our standard practice of documenting machines, networks, and configurations. Remember, back in the days of NT 4.0, you needed the drives for everything or you could not load the operating system.

So the Machine Spec Sheet emerged so that we knew which video card was used and could have those drivers ready if something went wrong. And the NIC. And the sound card. And so forth.

Automated systems, such as your remote monitoring tool, give you massive reports with all this data. But the useful 6-10 items of data are hidden among 1,000 other items you do not care about.

In 20+ years managing I.T., I have never found it useful to list every .dll version of every DLL on every computer in an office. But I have found it extremely useful to know the exact video card or network card!

The NDB has these basic components:

·         Title Page/Front Cover

·         Table of Contents

·         Fix-It Request List

·         Fix-It List Priorities

·         Backup Log

·         Notes Sheet

·         Network Diagram

·         Network Summary Page

·         Shared Resources

·         Exchange Specifications

·         Server Software Summary

·         IP Address Allocation

·         Hard-Coded IP Addresses

·         Router Configuration

·         Firewall Configuration

·         Machine Specifications

·         User Records

·         Product Information

·         Internet Domain Registration Information

·         Backup Procedures

·         Monthly Maintenance Checklist

·         Password Policy

. . . most of which are discussed in this four-book series.

The NDB is not intended to be 100% of the information about any machine or the network. It IS intended to give you the important and non-obvious information you need to get systems working again when they break.

How do you make that massive network-connected faxer-scanner-printer connect to the server, deliver faxes to the intended recipient’s email, and drop scans into the correct directories on the public share? I don’t know – but it’s in the documentation!

More fundamentally: How many physical drives are in the server? How are the RAID arrays configured? What’s the domain administrator password? How is the firewall configured? And what is the backup strategy? (See Section III of this volume.)

The NDB covers the basics of users and desktops because, to be honest, those are simple and mostly-disposable resources. All the important company data are stored on the server and backed up. So if a user leaves the company or a desktop computer crashes, no company-critical data are lost. Still – there’s enough information there so that re-building a desktop is as fast as possible.

On the more arcane configurations, the NDB does into more detail. Which publicly-visible ports are forwarded to the server? How do users gain remote access to their desktops? How is the BDR (backup and disaster recovery) device accessed in an emergency?

Implementation

There are two basic approaches to building your NDB. First, you will gather up some information when you take on the client. Remember Chapter One: Your First Client Visit. An ideal first job will touch each computer.

Whether it’s installing RMM agents or doing desktop tune-ups, the opportunity to touch every machines means you can start building the machine spec sheets. You’ll also need to know the IP addressing of the network, and some information about the server and firewall.

Make it a policy and a norm within your business: Every time you touch a piece of equipment, you document it.

The second approach is to do the documentation all at once. You’ll miss a few things because you don’t know they exist. But for the most part, you can document most small networks in one or two hours. This is also a good first job. Just hang out in the client’s office awhile and get to know people.

When you’re done with the documentation, photo-copy or scan everything (whichever is easier and faster for the client) so that you can have someone enter it into your PSA. The client should have a physical Network Documentation Binder that lives next to the server. You should have all of that information as one or more documents in your PSA.

Here are the two easy methods for keeping the NDB up to date:

1)      Whenever you make a change and you are on site, enter the change into the NDB. Sometimes this means updating existing pages. Other times it means that you will create a new page. Just do it.

2)      If you are working remotely and make some significant change, take a screen shot or create a PDF document. Then email that document to your in-house contact and ask them to a) Place it in the “c:\!Tech\Tech Notes” directory on the server, and b) Print it out and put it in the NDB.

Each month, when you do monthly maintenance, you will need to add a few notes to the NDB, and maybe straighten it up a bit.

I know it sounds morbid, but the ultimate test of your success is that you could be hit by a bus and your company would still continue to provide perfect service to the client because everyone documented everything they did.

For most clients, the NDB is maybe 25 pages. For some, it starts out as ten. There’s one for each server, one for each workstation, maybe three for the network, and one for each major device or line of business application (LOB).

The NDB is never intended to be a 200-300 page document that no one ever reads. Just the opposite. It is the most basic, most fundamental, most important information that a competent technician will need to come up to speed very quickly if you and your company are suddenly gone.

:-)