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
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.
i was thinking along the lines of would i need to list attendees
changes implemented as a result of an emergency
failed changes
backed out changes?
incidents raised due to change?
i'm not too sure about changes re-submitted to CAB? does this mean changes which have not yet been approved and are pending detail from the last meeting?
Also when should an RFC be sent to CAB, what stage of the process? in my current company changes go through CAB at the beginning
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Sun Jan 14, 2007 11:12 am Post subject:
tigs wrote:
i was thinking along the lines of would i need to list attendees
changes implemented as a result of an emergency
failed changes
backed out changes?
incidents raised due to change?
i'm not too sure about changes re-submitted to CAB? does this mean changes which have not yet been approved and are pending detail from the last meeting?
Also when should an RFC be sent to CAB, what stage of the process? in my current company changes go through CAB at the beginning
thanks
As far as when an RFC should be sent to the CAB according to ITIL -
The ITIL Change Management process is more along the lines of what many organizations consider an Office of Project Management. The RFC is actually the request made by an expense center to spend money or resources on technology. The CAB is there to give three assessments: Technical, Business, and Financial.
Unfortunately in many organizations, the CAB is either a pro-forma group to rubber stamp requests that have already been partially implemented (everything has already been developed/tested and is ready for for the production environment), or are collision prevention groups. They are there to ensure that multiple Changes that could adversely affect each other don't get implemented at the same time.
What should happen is that when a group decides that they want to spend money, use resources, or in some way affect the production environment, that group opens a RFC. The Change Manager exams the RFC and determines if they want to take authority for approving the Change. If so, the RFC is categorized as a Minor Change and approved/denied. If the Change Manager does not want to take the authority, then they review/set the RFC's priority (based on Impact and Urgency) and add it to the Agenda for the next CAB meeting as a Significant Change.
One of the Agenda Items for every CAB should be Assessment of Significant Changes. Those assessments will be the Technical, Financial and Business assessments. The Significant Changes should be reviewed in the order of highest priority first down to the lowest priority last.
When the Change has passed all three Assessments, it is the role of the Change Management Process to then follow the Change through its life cycle. This can easiest be thought of as a Project Management function. This is the typically done by an Office of Project Management who are responsible for managing all on-going projects in the organization. This is, in fact, part of the Change Management Process.
A suggested agenda might be:
-------------------------------------------------
Significant/Major Changes -
Assessment of all submitted/re-submitted Significant/Major Changes (Major Changes that have been blessed by the Management Board)
Determination if any Significant Changes need review by the Management Board (if so, the Change is re-categorized as a Major Change)
Report of implemented/failed/backed out Significant/Major Changes
Review of any Incidents generated from Significant/Major Changes
Emergency Changes -
Assessment of all Incidents associated with Emergency Change requests
Report of implemented/failed/backed out Emergency Changes
Review of any Incidents generated from Emergency Changes
Minor Changes -
A report of Minor Changes approved/denied since last CAB meeting
A report of Minor Changes implemented/failed/backed out
Review of Incidents generated from Minor Changes
Standard Changes -
A report of Standard Changes submitted since last CAB meeting
A report of Standard Changes implemented/failed/backed
Review of any Incidents generated from Standard Changes
Review of any suggested re-categorization of Minor to Standard Changes
-------------------------------------------------
The purpose of having an agenda in this order is to make sure the primary purpose of the CAB is achieved. If the CAB does nothing other than review/assess/approve Significant Changes, then they have met their primary purpose. If you actually have time to get to re-categorization of Minor to Standard Changes, all the better.
Joined: Sep 16, 2006 Posts: 3339 Location: London, UK
Posted: Sun Jan 14, 2007 8:30 pm Post subject:
There is also no prevention of having multiple CABs either - each with its different focus
An Executive CAB which defines and distributes policy and reviews and changes the process/policy/procedures
An operational CAB for the day to day stuff
A emergency cab for the doh... Emergency Changes
a Post Implementation Review CAB which reviews the closed Changes and how well they went _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
0. open the meeting.
1. collect last feedback to agenda (mainly aobs to be added at the end of the meeting (2 minutes)
2. Statistics of last period (2 minutes)
3. RfC review by category (as long as needed) with recommendation (I ask people to prepare recommendations before the meetings - so I can collect them all and not waste time for RfC explanation)
4. Review of RfC implementation progress to that RfCs that CAB wants to have knowledge about (YES - we made such a point to spread knowledge about RfC implementation within organisation)
5. Any other business.
6. Close the meeting.
Posted: Sat May 12, 2007 12:49 am Post subject: Multiple CABS?
In this context, I'd also like to ask a question:
What about an organization in wich you have different types of products or different types of technology?
Can you establish more than one CAB? and not in the lines of establishing CABS with different purposes, I mean four CABS with the same purpose, only regarding different technologies.
To be more specific: we are a Telecommunications company that provides Fixed Landlines, Mobile Voice Service, Mobile Data Services, DSL, Dialup and every flavor of the communication pie you may think of.
In our case, we already have a CAB in the IT department following ITIL guidelines and I'm leading the project to establish a change management process in the Operations Department.
One of my questions at this point would be if any of you would shed some light in the matter of multiple CABs with the same purpose.
For example, I would have a CAB consisting of 8 to 10 experts in the Data Department, another CAB with 8 - 10 members in the Wireless department (each member an expert in a different area of the wireless spectrum), another CAB for Landlines with same characteristics (and an expert in each landline technology) and a last CAB for Transport Systems (Radio and Fiberoptics).
Needless to say, to convene one CAB would be horrific regarding the size, so now I'm in the middle of this debate of whether to implement one Big CAB (with members attending only if they have changes regarding their area of expertice) or multiple ones.
Posted: Sat May 12, 2007 4:16 am Post subject: Multiple CABS
OK, but what about if they do interfere with other areas and we just have the Change Manager(s) decide wether or not the change could be implemented in the desired time frame?
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
