Creating network documentation is probably the least glamorous (and least exciting) part of any consulting project. Even so, documenting network changes is a must. At some point your customer may become self-sufficient and need information about their network's configuration. And even if your customer never becomes self-sufficient, you'll find the documentation useful for a variety of reasons.
 |
| Windows Networking Project Guide |
| Get more tips and strategies on building, troubleshooting and securing your customer's Windows network. |
|
|
|
|
As your consulting business grows you may no longer have time to service customers personally. In the future, one of your employees may service the customer. Having proper documentation is a best practice that ensures that anyone on your staff is able to service the customer's needs without having to interrogate the customer as to their setup and what your company has done for them in the past.
Documentation is also important from the standpoint of helping you to remember what was done. I've completed projects that I thought were going to be a one time job. A year or two later, the customer has called me back to do something else. There's no way I'm going to be able to remember exactly how the customer's network was set up or what I did for them a couple of years ago. Having good documentation has allowed me to review the customer's network (as it existed of the time of my last visit) so that I don't embarrass myself at the customer's site.
Good documentation also serves to protect you. It's been my experience that once you touch a customer's network, the customer naturally assumes that anything that goes wrong from that point on is related to something you did (whether it actually is or not). The problem with this is that if your customer has a major system crash, they may attempt to pursue litigation against you, even if the crash was not your fault. This sounds a little far-fetched, but remember that you know more about the customer's network then they do. If that wasn't the case, then they wouldn't have called you in the first place. As such, the customer may lack the skills to tell the difference between a crash that is related to something that you've done and a crash related to something else.
If the customer does attempt to take legal action, then your documentation will likely be your best defense. Thorough and well-written documentation will not only show which parts of a customer's network you modified, it also provides evidence that you adhere to industry best practices.
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, Active Directory layout, etc.)
- A list of the computer names and IP addresses
- 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 you worked with on the project, as well as notes about the roles they played in the project (who approved what, etc.)
- If your client has invested a significant amount of money in new hardware, you might even take some photographs that you can use as proof that the hardware was given to the client.
Most of these items are intended to help you cover yourself should a client become disgruntled months or years down the road. However, the items on this list can also be used to refamiliarize yourself with the customer's network should they eventually want you to perform more work. You may find though that you have to do additional types of documentation not so much for your own benefit, but for the benefit of your client.
For example, last year I took a job in a third-world country. The employees that were hired to support the network had very little experience with computers and almost no experience with networking. The time difference made it impractical for them to call me every time they have a question (not to mention the difficulty in making an international phone call from that country). Thus, I spent a few extra days on-site writing documentation for various procedures, such as how to create user accounts, perform nightly backups and add workstations to the domain. I then gave the IT staff time to work through the procedures that I documented to ensure that nothing was unclear.
Anytime you perform work for a customer, it's important to document what you've done. The level of documentation required will vary greatly depending on the type of work and your customer's skill level. In any case, your documentation should be comprehensive enough that you could use it to defend yourself should your customer take legal action against you.
About the author
Brien Posey is an award winning author who has written over 3,000 articles and written or contributed to 27 books. You can visit Brien's personal Web site at www.brienposey.com.
