Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: GHopkins
New Today: 1
New Yesterday: 98
Overall: 143928

People Online:
Visitors: 60
Members: 2
Total: 62 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Definition of change that should go the CAB?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Definition of change that should go the CAB?

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
Tommy
Newbie
Newbie


Joined: Jan 21, 2006
Posts: 1

PostPosted: Sat Jan 21, 2006 7:14 pm    Post subject: Definition of change that should go the CAB? Reply with quote

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
Back to top
View user's profile
RobRoy47
Itiler


Joined: Jul 26, 2005
Posts: 42
Location: Northern Virginia, USA

PostPosted: Sun Jan 22, 2006 2:21 am    Post subject: The Reverse Reply with quote

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.
Back to top
View user's profile Send e-mail
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sun Jan 22, 2006 4:19 pm    Post subject: Reply with quote

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).
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Mazhar
Newbie
Newbie


Joined: Jan 29, 2006
Posts: 1

PostPosted: Wed Feb 01, 2006 1:46 am    Post subject: Reply with quote

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.
Back to top
View user's profile
malwright820
Newbie
Newbie


Joined: Jan 31, 2006
Posts: 8

PostPosted: Wed Feb 01, 2006 7:31 pm    Post subject: Change Control Reply with quote

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.
Back to top
View user's profile
wsctb
Newbie
Newbie


Joined: Dec 28, 2005
Posts: 1

PostPosted: Wed Aug 09, 2006 6:31 am    Post subject: It's all about Risk Reply with quote

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.
Back to top
View user's profile
outager
Newbie
Newbie


Joined: Aug 01, 2006
Posts: 7

PostPosted: Thu Aug 10, 2006 6:34 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
TemperedMeasures
Newbie
Newbie


Joined: Aug 13, 2006
Posts: 8

PostPosted: Mon Aug 14, 2006 11:11 am    Post subject: Reply with quote

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
Back to top
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.