IT Employment

General discussion


What/how would you document to guard against 1-person failure point in IT?

By Understaffed ·
I am a single-person I.T. Department for a non-profit child welfare agency, managing 150 users, 100 desktops, 6 servers, and all aspects of technology. We have our email, database, app, file, and print servers, phone system (within a couple of weeks moving to VoIP), accounting and case management systems all in-house. The only thing I don't host or manage is the website, due to lack of time and flukey local utilities.

I have not been what I would call "diligent" when it comes to keeping change-logs when servers are set up and apps installed- I tend to keep the most relevant stuff in my head. This scenario, however, is a disaster waiting to happen. If something were to happen to me, 1) nobody in this organization would be able to fill my shoes even temporarily (social workers...) and 2) I would think a new person would have a hard time getting acclimated to the network, due to the lack of *settings* documentation. I did create a "LAN Book" that contains things like server names and hardware configs, LAN physical layout (which is quite convoluted), services and apps running on particular servers, and DHCP/DNS settings.

My problem is this: I built this network from nothing, and this has been my only work experience in the IT field, so I have no others to look to. I have been tasked with creating a manual that would allow someone to run the network in case I die in a car wreck on the way home.

What would you include, and where in the world would you start? To me, this seems like an insurmountable volume of data... I know that my CFO wants a domain admin account password kept in a safe deposit box, but where is the line drawn- do I include that the fiber between buildings is 6-strand 6.25 micron direct plant with SC ends, just so that person knows?

What say those in the trenches?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Document Everything

by Mr.Wiz In reply to What/how would you docume ...

I'd document everything down to the smallest detail. If you want someone to be able to step in in an emergency, they'll need to know everything you know.

Collapse -

Document to the detail a replacement would need

by arthur In reply to Document Everything

Documentation is a somewhat necessary evil, which techies normally abhor. It is wise, however, to set time aside for documentation to make your own life and that of others easier. Depending on how complex the network is, and how many well-qualified staff are around you can decide that it is inefficient to dedicate resource to documentation. Contrary to that I have always maintained that when we are all in a bus on a day out and the bus falls into a ravine and we're all killed, a new team should be able to restore normal support within a week. This calls for documenting what skill sets are needed for the replacement team, and gives you an insight to what your own skill set is. It will highlight your areas for development and opportunities to stay one step ahead. If higher management ask for information, you have that information at your fingertips, and if there are problems which needs an outside company to help resolving the problem, your own fault analysis can save an enormous amount of expensive consultancy time.
As an example: a company comparable to ours spends about ?100K on consultancy per annum, because they have not been documenting their network, nor do they have procedures in place to log/track network changes. This company has a relatively high turnover on staff, and is destined to outsource all services to an outside support company, costing even more. It is very detrimental to customer service, that's why we are documenting and staying employed.

Collapse -

While the previous post was somewhat true

by faradhi In reply to What/how would you docume ...

Everything i know does not help. First, you should explain that a non-technical person will not be able to do your job. There is just not a way to anticipate every problem you encounter on a day to day basis.

So what I did when I was in your shoes is

first I documented restore procedures to get you where you are today. This includes admin passwords, service accounts and their passwords, where to find replacement software, images if you have them, and backup tapes. Also, a list of vendors, licenses, support contracts with phone numbers. Disaster recovery will cover a lot of documentation you will need to do.

Second, Document how-to's when it comes to common day to day operations. How to create a user account, how to restore a desktop from image, how to restore a file from backup, how to reset passwords, etc. (this is to help the non techie survive until the calvary comes)

Next, document any specialized scripts and processes that you created. Assume a more technical person will be reading this. Your employer could hire a contractor if needed.

I am sure others will give you more. I hope this helps get you started.

Good Luck.

Collapse -

Document how-tos??

by sstever In reply to While the previous post w ...

Documenting how-tos seems like reinventing the wheel to me. I've had bosses who've asked me to do that and I've refused. If something happens to you, a wise manager would bring in a professional IT person...not someone who has to be taught how to create an account, etc. You can't be expected to write a "how to be an IT professional" book. If it was that simple, everyone would buy the book and do what we

Collapse -

Bringing a "Professional"

by Spring_Chicken In reply to Document how-tos??

In my opinion this is clearly not a realistic option, in order to find that perfect ideal 'professional' IT person is not an easy task at all for HR. It could take weeks to find someone who could fill in. We as IT professionals are not the best writers or the best at documenting but we must give our best efforts. The IT professionals that I work with who don't do documentation do it for a purpose. That purpose is never looked on as a positive from management's perspective because it shows that IT professional doesn't want anyone to know what he does everyday. This is essentially 'job security' so he doesn't have to worry about getting fired. If management doesn't know what he does everyday how could they find a replacement to fill in perfectly?

It is in the best interest that you compile the documentation at your best efforts. It will give you good experience and prepare your company for the worst which isn't a bad thing.

Collapse -

"Professional" continued

by ProcessManager In reply to Bringing a "Professional"

I would not only document everthing, as other have stated, I would also include a list of possible " substitute" that is firms or consultants that could be called in should you not be available. You're not only creating the documentation you're interviewing the possible outsource supplier as well. Not that you're hiring them but this is part of the disaster plan.

Collapse -

Personnel contingency planning

by Understaffed In reply to "Professional" continued

Each year, we look at our positions and the current body of employees and identify those that are in a position to fill in temporarily, could be educated to replace, or could replace at the present time. One of the things we do right...

Collapse -

Document what is specific to your company

by mllwyd In reply to Document how-tos??

We have to document how to create accounts and other such things that any "professional IT person" could do because we do it in special ways. For instance, our programmers use specific fields in AD to pull data, therefore it's very important that you put the correctly formatted info in those fields. We also have to add users to another half dozen systems. No, you don't have to document how to add a user to Windows, but you have to document how to add a user to your system.

Collapse -

Break it up

by Jaqui In reply to What/how would you docume ...

It's a huge task overall, break it into logical sections:

1) Software, what apps are used [ including versions ], admin passwords, configuration settings. where original cds are, product keys, manuals...

2) Hardware, list each piece of hardware, and serial numbers.

3) layout. detailed description of the network layout.

4) Backups Ect.. Detail each policy for system management, and why it's in place, how often are backups done, where they are stored, why is this timing used..

I listed those in the order of importance, since they need to have the admin access to do anything, and having documentation on the software and confiiguration is going to be the biggest help from the start.

as the Previous posted mentioned, everything needs to be documented, but if you prioritise the task into smaller sections it reduces the impact of the size of the task to document it all.

Collapse -

Document a requirement

by Tony Hopkinson In reply to What/how would you docume ...

for another employee.
I don't care how good you could get the documentation and keep it up to date, during your time off from curing world poverty, solving cold fusion and inventing an FTL drive. Handover will still be horrible.

Related Discussions

Related Forums