Keep up-to-date with ITIL news. Low volume to-the-point bulletins...
ITIL in Practice from ITILnews.com
ITIL Change Advisory Board - Is it killing your Business?
ITIL Change Management clearly states that all Requests for Change (RFCs) must be approved and authorized in advance of implementation. The speed and effectiveness of the approval and authorization element of the Change Management Process can provide the difference between the organization being responsive to market forces, competitive and in some cases 'first to market', which in the current global economic climate may be the difference between surviving or 'going under'.
 
In recent years I have engaged with several organizations that have established a Change Advisory Board (CAB), but it has in some cases been to the detriment of the organization. The CAB has met on a weekly basis to review all Requests For Change in detail. Often the meetings run for a couple of hours or more and are rather tedious and onerous.
 
The CAB is normally comprised of knowledgeable, experienced and quite well paid members of the IT department, business and potentially chargeable third party outsourced service providers (OSPs). On the odd occasions I am invited to attend an organizations CAB, I make an educated guess at what each individual might be paid / charged by the hour around the table. By adding each of the costs together to obtain a total and then multiply by the number of hours the meeting lasts, an estimated cost for the meeting can be compiled. It can be quite surprising just how much the CAB can cost.
 
Working in the manner described above some organizations may be scoring an 'own goal' by incorrectly invoking the Change Advisory Board and in fact impeding the Business in doing so. ITIL proposes that RFCs are categorised at an early stage of the process. Below are four suggested categorises, which are described as:
  • Service Requests - small repetitive changes for example password reset or individual desktop build
  • Normal / Standard - limited impact, resource and cost, reasonably short time scales to deliver
  • Significant- high impact activity or complexity that may effect several areas of the organization or business e.g. power down of a data centre for maintenance work
  • Major - long duration, high complexity, large budget / cost, multitude of resources / suppliers e.g. projects or programs
By invoking the CAB for Significant and Major RFCs a more effective and cost efficient use of the various attendees time is provided. Simply by the size or scope, complexity, impact and cost implications of such RFCs approval / authorization or rejection should be provided by a broad cross-section of the organization representatives.
Immediately the effectiveness of the CAB is improved from time spent, costs incurred of such a meeting and value added. The frequency of the CAB meetings should be on an 'adhoc' basis, whereby meetings are only convened as and when a significant or major RFC(s) are presented. Details of the RFC(s) should be distributed in advance of the meeting allowing exceptions or concerns to be raised at the CAB meeting, thus expediting duration and efficiency of the meeting. All decisions and actions should be recorded in the RFC.
 
The majority of RFCs are those categorised as Normal / Standard RFCs and are managed on a day to day basis by individual CAB members from the various areas of IT, for example; Application, Infrastructure, Network , Data Base, Security Manager(s) or Team Leader(s). Each individual RFC is reviewed by the relevant manager(s) / team leader(s) as required and applicable. The outcome of the review will be to approve, authorise, reject or request further information for the RFC. Undertaking this approach enables changes to progress in a timely manner thus providing a responsive and supportive service that underpins the Business and the service offerings.
 
ITILnews welcome your comments and feedback regarding articles and experiences shared so please do not hesitate to contact us.
 
 
 

7 VISITOR COMMENTS

2014-04-07 by "gmkushma"

I have heard about an approval to build step in the change process and I am looking to further understand this step. This isn't approval to implement in the production environment rather an approval to move forward and perform the build/test actions in preparation for the eventual release into production.

Thanks
Reply on 2014-04-29
Could I suggest that you have a look at the following article...

http://www.itilnews.com/ITIL_CHANGE_MANAGEMENT_PROCESS_ROLES_and_responsibilities.html

2014-05-13 by "chandresh.adhiya"

Hi,

I do not agree that ITIL Recommends all Change Requests to go to CAB....

Change Authority can be defined based on risk and impact of change (Technical , Business & Financial)

I have personally defined process where I made BRM as Change Authority for certain type of Change, Head of Enterprise Architect as Authority in some cases and for some IT Steering Committee for very risky and costly changes...

If you have inexperience people Adopting ITIL Processes without Adapting to Business we get into such situations as described by you..
Reply on 2014-05-13
Many thanks for your comments. I believe we are saying basically the same. From experience some organizations operate in the manner I first describe.

The maturity and experience of the organisation will hopefully evolve into an approach you and I describe.

2014-12-04 by "bruce_rains"

What about when even the number of Comprehensive changes going to CAB is making it too long and less feasible to accurately assess changes? Has anyone implemented multiple CAB meetings effectively?
Reply on 2015-01-05
Many thanks for contacting ITILnews.

I have worked in organizations where CABs are undertaken by each Region and where a Change covers more than one Region the responsibility for assessment and authorization is shared. Regions are often geographical, with different time zones.

From what you have written I wonder whether a Change template could be defined that would assist with answering the various types of questions raised by CAB members upon receiving an RFC. The responsibility would be upon the Change Owner to correctly supply the relevant information. Review of the completed Change template could be circulated to all CAB members in advance for review prior to the CAB meeting at which time any exceptions could be discussed.

In addition some RFCs may only be relevant to specific CAB members for assessment and authorization, therefore it may be easier to timetable when they will be discussed at the CAB so that those CAB members who can provide no further added value to assessment / authorization may leave the meeting. It maybe found that if the 'head' or an 'expert' of a specific area is happy with the RFC and prepared to authorize the RFC and thus undertaking the responsibilities of the CAB, the remaining members of the CAB may simple 'rubber-stamp' their authorization.

The CAB is a very important aspect of any business, ensuring the CAB is run effectively and efficiently is imperative and it should not be used as a 'talking shop' as it will loose its value and potential benefits it has to offer.

Sorry if the team cannot be more specific but we would be happy to provide further feedback if more information was available.

2016-02-17 by "Iolandacostagomes"

Has anyone ever tried to implement a Round-Robbin style of sign-off sheet among all CAB Members? The plan would be for the PM to discuss the change with each member of the CAB outside the meeting itself and have the necessary technical meetings. If every single member signs off then there is no need for a CAB. Should there be at least 1 person who does not sign due to concerns then a CAB can be held for that particular project. Has anyone every tried this? Thoughts?
Reply on 2016-02-26
Many thanks for your question. Firstly, Change Management should not be bureacratic and should be perceived as an Change 'Enabler'. We have encouraged PM and Change Owners to discuss changes with CAB members in advance of a CAB meeting as it can expedite the Change Review and obviously authorization. The acceptance and sign off by the CAB members is only one responsibility of the CAB as we would also expect a 'proposed implementation date to be stated. The date would then be reviewed against the Change Schedule to ensure there were no potential clashes with other changes on that date.

Without knowing the size, volume of change and maturity of your organization it is very difficult to be anymore specific, but we do hope the above helps.

2016-04-16 by "mike.casey"

Great post!

Senior management should be able to trust the relevant line manager (or technical authority) to judge "Normal / Standard changes - limited impact, resource and cost, reasonably short time scales to deliver" within their specialist area. (Or whether it really does need to go to CAB.)

An undesirable alternative might be a series of trivial but blocking changes, each waiting on the subsequent week's CAB, bringing overall project progress to a stuttering halt.

2017-03-08 by "mmiller"

You use the term Normal / Standard. However ITIL defines three change types: Normal, Standard, and Emergency.

"There are three different types of service change: Standard change: A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction. Emergency change: A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch. Normal change: Any service change that is not a standard change or an emergency change."

Could you please elaborate on your use of Normal / Standard?
Reply on 2017-03-14
Many thanks for clarifying the change definitions, an oversight on our part.

Are you able to share your thoughts on the article itself ?
Reply on 2017-03-14
I think the article makes valid points. What I was actually looking for were some considerations regarding advice vs. approval.

ITIL seems to hedge the issue saying its advisory, but then goes on to say that someone makes a decision if full agreement cant be reached. That's having the cake and eating it too.

I see probable good in vesting accountability in one person (Change Manager or a leader with authority commensurate with the level of change)and the CAB members only providing advice, but not necessarily "voting". I also see good in the concept of the CAB formally voting and their votes being the sole deciding factor.

Could probably list the pros and cons of each, but maybe more an organizational culture choice. But again that decision could lend itself to some logic e.g. CMM Level

2017-10-30 by "singularzxc"

Hi, the CAB meeting in my organization runs for 3-4 hours on average even though only major and significant RFCs are discussed. The volume of major and significant RFCs discussed weekly is about 150 - 200. How can we reduce the meeting duration by half?
Reply on 2017-11-03
Many thanks for contacting ITILnews.com...

Regarding reducing down the number RFCs I would suggest categorising the RFCs. It does seem to be a remarkably high volume of major and significant changes being undertaken on your estate, but that does depend the size of your organisation.

I would consider why so many major and significant changes are occurring in the first place and is the criteria for determining a major or significant change correct.

Secondly, you may want to consider categorising your changes so that some may be authorised by responsible members of the organisation who are empowered to make that decision. For instance if a change is only affecting one IT area and does not impact upon another area then potentially the head of the IT area or similar could review and authorise (or reject) as appropriate.

I hope this helps and would be very interested if you manage to reduce the volume and duration of your CAB.
There is 1 comment awaiting user validation. There is 1 comment awaiting publication.

Please submit any comments you have about this article.

Your feedback will help add value to the content for other ITILnews.com visitors and help us develop the content for the benefit of all.

You will need to provide and verify your e-mail address but your personal information will not be published or passed on to others. To identify each post we take the part of your email address before the @ sign and use that as the identifier, so if you are john.smith@itilnews.com your post will be marked "by john.smith".

NB: We respond personally to every post, if it calls for it.

If you prefer to respond without posting your comment please use our contact form.


Click the REVIEW button below to preview your comments.

Other articles in the same section;
 
Tags; ITIL,Change Advisory Board,
 
This article has been viewed 59353 times.
NB: This page is © Copyright ITILnews.com and / or the relevant publishing author. You may copy this article only in it's entirety, including any author bio and / or credits, and you must link back to www.itilnews.com.

Keeping up-to-date with ITIL...

Keep up-to-date with ITIL news. Low volume to-the-point bulletins...