Definition of change that should go the CAB?

[Tommy]

Hello

I am working on designing a flow chart for the change management process in my company, I need to define a factor that trigger a change request to go for approval through the CAB and not to be treated as a standard change request that can be approved by the change manager only.

In other words my question can be as follows: what makes a change need to be approved by the CAB and not by a change manager?

Regards

[RobRoy47]

Actually it is the reverse. All changes go to the CAB. The CAB can vote that a specific category of change can be handled by the Change Manager alone, but the first instance must go to the CAB.

[rjp]

RobRoy 47 is correct - the reverse is the recommended approval rule for changes.

In addition, to the CAB delegating some change approval authority to the Change Manager, many sites also define 'standard changes' which are effectively pre-approved and may be carried out by technical staff as required. An example of this may be replacing like for like components on a standardised desktop. They will of course be recorded.

It also pays to think about how the different processes interact. Very few ITIL processes are 'quarantined' in one discipline (like change management). So configuration management steps into you search for a 'rule' - whereby it may be established that the change approval status of any specific CI is recorded as an attribute of it's CMDB record. There may also be a more general rule that all CIs under change control will be in the CMDB. This helps define a Change Management scope - in that anything not in the CMDB may be deemed to be 'out of scope' for change mangement. (Use with care though).

[Mazhar]

Tommy,

I have come across instances where companies did not want certain changes to go to the CAB or what they call Change Review Board (CRB). They considered some changes to be rather low impact or even very critical in which case they could not wait on these boards to sign off on. So they recommended we design a process which would by pass the board on such ocassions. We basically designed these based off of the category of change and at times with the combination of impact that was selected.

It's unbelievable how many different approaches have been used by the companies worldwide. But then there is no universal workflow that would work for everyone.

I hope I have helped a little along with the other members who have posted replies to your question.

[malwright820]

I am new to the forum but in my last job we implemented change control within the IS dept without reference to the QA dept. The problem with this approach is we were working outside the company QA system. I agree with RobRoy47, the CAB must see each change control request.
The way we finally worked was to use the QA change request (A high level form) On this we reference the internal IS change control request, this was more detailed in what was required to make the change and listed procedures followed in making the change.

At the end of the day, QA were aware of the change but the 'nitty gritty' document was held in IS.

[wsctb]

I work at a major finance company in the UK. Maybe 5% max of our changes are approved at a CAB. The remainder have their approval delegated to support groups to authorize locally.

It is important to appreciate that signing-off a change does not mean that the change is guaranteed 100% correct. What happens at the CAB is that the Risk associated with the Change is discussed, understood and accepted by the signatories.

Understanding that the process is based around acceptance of risk, rather than 'proof of correctness' is important in understanding what can and cannot be delegated.

Anyone abusing the system by sneaking risky changes through is soon found out. You have to be dispassionate, like a bookmaker, and understand that a certain percentage of changes per year will definitely fail.

You just have to make the call on how much you can gamble with the production service, when you can gamble, and how you will get out of any hole you find yourself in.

R.

[outager]

Creating a general description of changes that bypasss CAB can be tricky in my opinion. Small changes can have high risk. Problem with defining a catagory is that you cannot be sure that some of the described "small changes" do have high risk.

I would always turn it around:
- All changes pass CAB.
- CAB manages a list of standard changes (template changes).
- Template changes are descriptions of changes of which you know the risk, is done before, etc.
- The list is dynamic, and grows.

[TemperedMeasures]

I would recommend having all changes go through the CAB first. Have the CAB go through the resulting change data, and determine (based on historical incidents resulting from changes) what can be considered "pre-approved" and what should go through the different levels of the CAB.

Dan Vogel