All these answers are incorrect because they omit the critical first step: Define the project. Before you can use any of these ideas (many of which are very good), you need to be able to answer the following questions with absolute certainty
- What systems you are touching-- when and for how long can they go down?
- Which departments will be hit and when will they agree to be inconvenienced?
- If there is a critical system, when can I shut it down? is it backed up?
- How much money can I spend to do this?
- How many people can I borrow?
- How long can I take? (meaning both man-hours to do it and time when it must be done)
- Is there any documentation and should I trust it?
Maybe you know all these things and you didn't go into detail. But unless everyone is on board with your plan, you can end up writing one of those "How I blew up my company" Infoworld columns.
I had this situation once. Turned out we had a box that had to be on and connected. Pull a wire for too long, it would hiccup and crash. If it went down, anyone using it was screwed. Plus, two other systems-- who rarely used it but continually monitored its status-- would freak.
It only took a few minutes with the manual to figure out the order the systems needed to be shut off and a few phone calls to schedule it and one "Don't log into this system remotely over the weekend!" mass e-mail. But that's the difference between nobody noticing and people hating you forever.
Management's responses to definition questions will help you plan other projects. Your work requires them to make occasional choices and you need to learn what, how and why they will choose. You might find you can't hire anyone to help, can't buy 1-foot cables to replace 8-footers, can't shut people down, can't stop taking "can you unjam my printer?" calls while you do it, can't get overtime and can't come in early, stay late or work weekends if it means you won't be there M-F. If so, you know you need a new job.