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.
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.
:-)