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: HGaray
New Today: 19
New Yesterday: 72
Overall: 139509

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 - Change Advisory Board - CAB
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Change Advisory Board - CAB

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


Joined: Jul 21, 2005
Posts: 1

PostPosted: Thu Sep 01, 2005 3:14 pm    Post subject: Change Advisory Board - CAB Reply with quote

The ITIL process for change seems to have the CAB sitting very much at the front of the process to assess RFC's being submitted so they can be approved for implementation. At this point the activities around change build/test/backout etc commence. Within my organisation the view being taken is the CAB is actually run very close to change implementation so the technical contents/change quality/etc can be assessed and the change approved or rejected at this point. Has anyone else implemented CAB processes and where in the change process flow have they occurred?
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Thu Sep 01, 2005 5:25 pm    Post subject: Reply with quote

We don't have a CAB. Rather the CABs role/function has been allocated to the plenary meetings which were already taking place.

When a change is approved, this does not mean that if testing fails the parameters or scope of the change can be altered. In that case it becomes a 'diferrent' change and requires approval. But yes the 'CABs' are close to the implementation planning process. But our implementation strategy is to 'transform' existing practices (where possible) - A common approach is to implement alternative processes and 'switch' to them once you are sure they will work.

Also - remember that in ITIL the CAB, and the Change Management process is intended to be predominantly an assess, approve, update (cmdb) and review process. Not the implementation and planning process - which is what Release Management is about: I.e. getting all the tasks done, ensuring the change will work and 'releasing' it into the live environment. So where release management is in full swing, yes the CAB is very much at the front end of the process. But in business terms distance isn't really measured in the number of steps in a process, but in the time and resources expended to get from step 1 to step n (or back again), and the overall visibility of the activity in each task - monitoring, reporting, tracking. So the CAB can be at the front end of a complex process, and still be close by being well informed, and agile (quick to respond when required).
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
blamblam
Itiler


Joined: Jan 16, 2005
Posts: 37
Location: New Zealand

PostPosted: Tue Sep 06, 2005 9:51 am    Post subject: Reply with quote

We do have a CAB which convenes for Major Changes only. The Change Manager is the only permanent member of this group, the other members are assembled according to the Change. The CAB comes together to review and approve the Change following an impact assessment as overseen by the Change Owner. If the CAB gives it's approval for the Change to proceed, it's then developed and reviewed prior to release by the Change Manager. Any deviation from the original design that attained approval may mean the Change is stopped, though these things are usually dealt with pragmatically.

In our organisation, the Change Manager is also the Release Manager, so following approval for release, it is then scheduled for release. However this step is often done siginificantly in advance as Major Changes tend to be Projects and so there is visibility of when the Change will need to be implemented.
Back to top
View user's profile Visit poster's website
SD
Newbie
Newbie


Joined: Aug 29, 2005
Posts: 8
Location: Dublin, Ireland

PostPosted: Wed Sep 07, 2005 1:58 am    Post subject: CAB Reply with quote

We have a CAB, which meets on a weekly basis to approve/reject any signifcant changes pending.

Changes only go before the CAB, once they have been fully assessed in terms of impact, time, risk etc. by the resolver group(s). If the CAB gives its approval the change can proceed to implementation.
Back to top
View user's profile
mgnrfan
Newbie
Newbie


Joined: Jun 25, 2006
Posts: 6

PostPosted: Sun Jun 25, 2006 8:29 pm    Post subject: Reply with quote

We do have a CAB in our organization, and like SD mentioned they meet once a week in which they decide to go ahead or not.
Basically they review the Change Request, interms of Financial, Resource, Time requirement,
but Change Request goes to CAB only after first level of Impact analysis, so that it helps them to make decision in positve way
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Jun 26, 2006 2:44 am    Post subject: Reply with quote

Good day all,

Change Management and the CAB is actually an interesting dilemna. If you think about it, assessing the impact of a Change has traditionally been the responsibility of a Product Manager, who is usually the accountable party for the strategy of a Product and ultimately what Changes actually go into a Release and why. In a small company, where there are only a handful of products, it's OK to continue to let the Product Manager perform the CAB functions. But, obviously, as you scale to a point where you have many Products, constantly being Released into one environment, it becomes important to try and coordinate and evaluate as many of those Changes as possible, since any one Change can possible take down other related businesses or business units who share infrastructure, systems, data, etc.

It is in companies where many Products all funnel into one common environment that a CAB seems to be most useful. However, it is in these same environments that we see a CAB function breakding down as the organization gets larger. As an enterprise grows to be very large, it becomes almost impossible for the CAB to understand the whole view of the enterprise and, as a result, their evaluation of the Changes and their impacts becomes ineffective. This usually happens because 1) There are far too many Changes for far too many systems to understand and 2) The environment is too large and in a constant state of flux, making it too difficult for any small group of humans to understand.

In cases where the organization gets very large, we see the role of the CAB being reduced. They do not evaluate Changes so much as facilitate the communication of Changes. For example:

- All RFCs and their schedules must be communicated to the CAB so that the CAB can, in turn, ensure that all parties in the organization know that such Changes are intended for the future.
- Provide a centralized Release calendar that highlights what Changes for what systems are going into any specific environment, usually a month or two out.
- Highlight what Changes are Standard, Emergency, or Expedite
- Provide information for how interested parties can find documentation on each scheduled Release and their related Change(s).
- Bring all appropriate stakeholders to the CAB table (usually a week or so in advance of scheduled Changes) to ensure everyone understands what's going in the environment and to allow interested stakeholders the opportunity to voice their concerns, for one last final time.
- Ensure that all Release Managers provide proof of detailed Release Plans that include rollback processes
- Review success/failure of deployed Changes
- Generate, manage, and communicate enterprise wide statistics and metrics of Changes across all products, systems, services, and environments in the enterprise
- Etc.

In short, what we're finding is that the understanding and evaluation of Change impact is falling off the CAB's table of responsibilities and that those functions are being pushed "back" into the Product Management role, who's responsibility it is to work with their Service Delivery managers to ensure that Change impact and risks are accounted for, before the scheduled Release.

Anyhow, I hope you find this useful.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
WendyB
Senior Itiler


Joined: Apr 03, 2006
Posts: 78

PostPosted: Sun Aug 06, 2006 5:01 am    Post subject: Reply with quote

We've just implemented Change, and had the first CAB meeting to review an upcomming change. Even with the review of the RFC during the prior week, there were enough concerns about the implementation of the change that the change builder felt they couldn't be addressed quickly enough so it was postponed until he has a better understanding.

First one out of the block, too. The next one should be interesting.
Back to top
View user's profile
TemperedMeasures
Newbie
Newbie


Joined: Aug 13, 2006
Posts: 8

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

Something that works well in a lot of companies is to have everything go through the CAB on the first go. As data is collected... the CAB can make the determination for what should and shouldn't continue to move through it. This way, the assessments are based on fact. The CAB can take the data to help structure the change categorization structure. Using the data the CAB can also make a determination for what should be considered "pre-authorized". This doesn't take a lot of effort up front, and is a huge time saver as you progress forward.

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.