Documentation and tangets

Good documentation would describe everything that goes on, but it a small scale IT environment, projects fly in faster than the documentation can be completed.  For a 70 site company, I can think of at least six projects in less than ten seconds that are on the plate.  There are probably more.

Projects pile up faster than they can be documented, and often the final solution isn't something we'd expected.  As such, building a new back office computer becomes an exercise in fighting Windows 7 and fighting documentation that hasn't been updated since Windows 2000, if the documentation exists at all.

In the end, you have to document.  Otherwise, you sit there scratching your head, thinking back to all the memorable moments you've had, trying to figure out what the solution was.  It could be something like the serial port communication speed wasn't correct, or you had the cable plugged in to a slot that no longer works and surprise, whoever moved the cable didn't document.  So you have to document.  It's not a choice.

First step: buy a label maker.  I can hear the questions: what does a label maker have to do with documentation?   Simple answer: go look at any switch in a location, and tell me what all those cables plug in to.  Every single cable.  Now go find the other end.  Have fun.  I'll be waiting here.  Back?  Ok.

I was thinking of a second question when I started writing this, but when I came to finish it (today) that question is completely gone.  I have no idea where I was going with that. 

Cabling is the simplest and easiest way to see results when documenting.  If you have done your job right, you should be able to immediately notice if a cable has come out.  You should also be able to walk a non-technical person through chasing that cable over the phone.  At the moment, I don't have to do that.  All but two of my sites are within 30 minutes drive of each other.  But that's going to change.  It's just a matter of when. 

Second side note...  My first original sentence was "documentation is a necessary evil".  But that's not correct.  Documentation is a discipline and security issue.  You have to be disciplined enough to actually write the documentation.  You have to be secure enough to realize though you performed the steps, it's someone else's equipment.  And that could be half the reason most IT people don't document when they should.  A lack of discipline in an otherwise highly disciplined environment is unacceptable. 

So, after a couple of side notes, I think I've gone somewhere completely different from where I started.  It's a good place, though. 

The other point I was going to make about documentation...  Quit trying to write a "complete" document and turn all your documentation into "living documents".  In other words, hash out whatever steps you can think of for the project and document steps like crazy, but if you forget a section don't sweat.  If the project was worth doing once it'll probably get repeated.

Besides, documentation is only good after 3-4 people have gone through and tried to do what you are trying to do.  Because you know what you are trying to do.  They don't.