Change Control Reviews

By sprashanth ·
Hi,Could someone help me with

1. Important aspects to be looked into during CCB's review of changes reported
2. Reports on change requests along with kind of information that is usually reported.
3. On a project(s) that generates multiple CR's in a day, whats the optimal CCB review meeting frequency?

Also appreciate if someone, who have had the opportunity to track and control changes to multiple 'related' projects in parallel, help me with some best practices in tracking these CRs and their impacts on other parts of the project and other projects.

A lot to ask but I am trying to implement and streamline the same; so really would be helpful


This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

Briefly covered

by Noshmon In reply to Change Control Reviews


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

Related Discussions

Related Forums