Changes to Change

[Shoo]

If the CAB decides to move the change time to another timeslot to avoid a conflict on an approved Change, although not yet CAB approved. Should the CAB be able to make a change to the time and approve or should the change be denied back to the requestor?

Shoo

[UKVIKING]

Simple answer

what is the change management policy on this

It would be what ever teh policy states

If it does not , then it goes by precedence - previous history
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Shoo]

We've been redeveloping the policy and as we updated our systems to match the policy we noticed this hole in the process. We've had some discussions about resolution, since we've allowed the CAB to simply update the change and approve in the past but we're not sure if this is best practice in a more mature environment or if it was just moving things along.

Just wondering if others have thoughts on a best practice process here.

[asrilrm]

Yes, it's a matter of policy. You will have to describe the roles and responsibilities of your CAB in your handbook.

In generic, the CAB has the right to override the schedule of a RFC if they find it necessary, because it is in the CAB Meeting where prioritizing takes place.
One possible way is to invite the requestor of the RFC to the CAB Meeting and negotiate adjustment the schedule

[Mark-OLoughlin]

Hi,

here is the pinch

If the CAB move the time without notifying the requestor
1) it may impact any schedules the requestor has around the chnage - e.g. if the requeator is a release manager and another part of the rlease is dependant on this change going through
2) will the appropiate people be available at this new time?

These are the considerations you need to look at and develop a procedure around these to suit your org.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant