Tag Archives: network documentation

How good is your network documentation?

Jun 18, 16
, ,
No Comments

Blogger: James Osborne, Technology Consultant at Osborne Technology Consulting

How good is your network documentation?  If you were to win the lottery today and retire to Bora Bora (my version of the ‘hit by a bus’ scenario – I find it less depressing), would your replacement be able to ‘hit the ground running’?  If ‘aliens took your building’, would you be able to recreate everything? Do your current vendors provide you with documentation after they complete project work?

We should all know how important network documentation is to any organization. While you know your server names, and some of your IP addresses and print queues, do you really remember routing rules in your firewall?  Or all of the security groups and who has access to what? Good documentation frees you from having to remember how things were configured when you need to make changes. Good documentation also assists you when you have new staff trying to do something, or when you have a consultant working with you for some project. You can send them to the documentation rather than holding their hands for the entire process.

Virtually none of the clients I’ve worked with over the years have had great documentation; most have had no documentation. This doesn’t mean their networks weren’t setup properly, or well maintained. It just means that whoever had been working with their technology didn’t bother to write down what they knew. I’ve always tried to keep accurate and ample documentation wherever I’ve worked, and it’s always been worth the extra effort. It’s saved me from having to remember every little detail, and it’s been useful when I’ve had to hand things over to others. I’ve always feel it’s something that the client is entitled to – they’re paying for the hardware and software, and deserve good documentation of what they purchased.

While working with one of my clients recently, we brought in another IT consulting firm (Mirazon) to assist on a project. I’d worked with Mirazon before, and always found their engineers to be competent and friendly. I was surprised this time when they presented me with 40-odd pages of documentation at the end of the engagement. The documentation included numerous screen captures, and an updated network diagram. Finally, their documentation was subject to in-house peer-review – an engineer who hadn’t worked on the project came in and double checked the documentation.

I discussed this with the engineer who’d worked on the project and he commented that Mirazon endeavors to make this standard practice for all of their work.