Hi,
All of these are quite specific to your business, however I'll offer a few things to be considered as a base platform to start from. You should add to it and build up for your specific requirements.
I'm going to mix up your questions a little to make things a little easier to understand.
2) There should be comprehensive data provided. This should be saved somewhere secure and NOT editable. A revised version can be submitted, but that would have to go through change control too.
Security and IG - There should be a checklist. This checklist has points assigned to each aspect. If a boundary of points is reached then the change should be considered safe and secure.
Justification - Why is this change being raised? Decommissioning a switch to give the apprentice practice probably isn't good justification. Decommissioning the switch because it only has one user connected to it who can be moved to another switch, is a good justification.
Plan - What will be done and in what order. Using the above example it would be something like "
1) Un-patch network point EG1 from SWITCH1
2) Patch EG1 to SWITCH2
3) Remove SWITCH1 from RACK1"
Risk - What risks are involved? If you have a risk scale then what level on the scale.
Risk Reduction - What actions will be taken to reduce risks
Impact - Worst case scenario if the change doesn't go ahead
Test Plan - What will be done to test this? Include start and finish dates. A user acceptance test should be planned here too. For example, testing moving the Sales dept to a new OU would involve creating a virtual machine identical to one of the sales PC's, and copying an account. You would then log into that virtual machine that is in the new OU with the test account. If everything works and you spot no errors then move a single user into that OU. They will be able to offer feedback as to if it works as expected.
Actions on failure - If something fails then what will you do?
User impact - How many users are affected, and what effect will it have to them? EG. "Networking will be offline for 24 hours. 30 users affected."
Inventory impacted - This should include software AND hardware that is affected by the change.
Contact and Responsibility - Who should be contacted in regards to questions. Who should be responsible for errors and failures
Communication plan - How will you communicate to the staff when they will be affected, and what they will need to do. This is usually email.
1) Very simply, the 3 R's should be looked in to.
Requirement - How much does this need to happen
Risk - What could go wrong
Reward - What are the benefits of this happening
3) That is VERY specific to your situation. It depends how many are generated a day and what the typical urgency is. There should be an emergency process but that is more for operations rather than projects. Due to the multiple requests, but not knowing numbers, I would recommend every 3 days. This WILL have to be revised for your requirements.
I hope this helps
