Abolish the CAB at your peril
There seems to be a fashion for analysts to make rash revolutionary statements. I reckon it is in their KPIs. The normally-temperate Glenn O'Donnell said: "Abolish the CAB!". That is - to put it mildly - a bit rash.
The main culprit of inflexible change - in my opinion - is the Change Advisory Board (CAB). The CAB is an anachronism. It has become a speed bump in the journey to cloud flexibility. Those on the CAB are often power-hungry narcissists who merely want to impose their control over the process instead of serving the needs of the business. Regardless of the makeup of the CAB, they are also clueless about the realities involved. The world has gotten far too complex for this panel to make any trustworthy judgement calls. Even the best and brightest technologists are losing grasp of this complexity. The CAB rarely includes such people, thus even further diminishing the CAB's insight to reality. The CAB has become more a liability than an asset, adding little or no value and slowing progress.
Suitably provoked, I said:
You are throwing out the baby with the bathwater. To paraphrase: "let's abolish consulting stakeholders before making change". The CAB is essential.
As with all these things it is how well it is done that varies. But don't shoot the message because the messenger screws up: the CAB is a good idea.
Anyone who properly understands change knows that the CAB is only required for some changes. Many changes should be Standard or Minor and not need CAB review. I'm also a fan of virtual CAB, where approval is given by email or by an online tool, and the CAB only physically convenes for major or controversial changes. Likewise I'm also a fan of dynamic CAB, where the membership is determined according to the change in question, so that staff aren't forced week after week to sit through innumerable changes that don't interest them. No wonder they turn nasty.
A CAB is only as good as the people implementing it, but that's true for everything.
You can follow the rest of the discussion over there.
This is yet another example of trying to trash the theory because of cases where it is badly applied. A CAB is a representation (that dirty word: a committee) of the stakeholders affected by a change. To suggest they do not get a say in the change is simply madness.
We can discuss how best to consult them, how best to communicate the implications of the change, how best to act on their opinions, how much power to give them. All these things are open to debate. But to suggest we can do without a CAB is just sensationalism. Even Glenn admits that "Yes, I do articulate a strong position to get the dialogue flowing" and goes on to argue against the original premise.
If analysts keep trying to top each other in outrageousness I'm not sure where it will end, but it will be fun watching.
What do you think?
Made in New Zealand 
Comments
It depends...
It all depends on how closely your company, or the IT functions and the company work together.
With disperate systems all over the world, managed by different teams with different agendas - without the CAB it is impossible.
However, a smaller IT organisation where people all sit together and talk regularly - the CAB could be taken away.
Sometimes knowledge is power for some people and not everyone can know the in's and out's of all their IT systems (documentation? what documentation???). So the CAB is a place where people can share their concerns or views on change timings or the possible impact to fred who works nights and needs access to that certain system - and most people did not know he even existed!
How the money men see it all...
A little off topic, but well worth the read:
http://www.cfo.com/article/2011/12/it-value_cfo-cio-relationship-it-cost-transparency-consumer-tech-environment
"There are no such things as 'best practices'; there are only practices that best fit a company."
Provocative title, common sense content
O'Donnell's comment seems to me to be quite common sense.
He suggests that a weekly CAB is no longer optimum. I agree.
Instead, he urges:
"The best approach must be a combination of approval methods:
*A process for low risk, repeatable (Standard) changes
*A system for accurately and systematically ranking changes according to a risk profile
*Electronic approvals using a majority system, or selecting the right approver based on Business service
*CAB meetings to review the changes that really need it"
It seems to depend upon an extensive use of pre-defined changes - probably from a service catalog, request and fulfillment process.
Many times now I've helped companies eliminate ~ 80% of their changes through the use of organized, proactively-managed standardized request/fulfullment processes integrated with approval flows, VM management, runbook automation, asset management/procurement, SAM, software distribution, field service management, etc.
O'Donnell's view that such automation increases agility and speed of service makes sense to me.
One can also start to create outside-in, lean approaches to management. And, can apply TQM and Time-Driven Activity-Based Costing to the processes - measuring times, costs, rework, etc. This can be done "bottom-up" once the infrastructure is in place.
CABs can then become virtualized and meet far less often. Letting management focus more on the important than on the urgent. Overall, seems right to me.
conventional ITIL
Of course it seems right: as far as i know that's conventional ITIL:
*A process for low risk, repeatable (Standard) changes
*A system for accurately and systematically ranking changes according to a risk profile
*Electronic approvals using a majority system, or selecting the right approver based on Business service
*CAB meetings to review the changes that really need it"
Standard (pre-approved) Change didn't appear until V3 (ST 4.2.4.5), but V2 says "it should not be necessary to insist on face-to-face [CAB] meetings; much of the assessment referral can be handled electronically via support tools or email. Only in very complex, high-risk or high impact cases will a formal CAB meeting be necessary" (V2 SS 8.5.5)
In many organisations I think it is still appropriate to have quite regular CAB meetings, weekly, fortnightly or monthly, to ensure stakeholders are aware of what's going on and what's planned. people don't read emails or notifications.
Glenn's point was - I think - that CABs become entrenched bureaucracy. That's true but it doesn't mean we abolish them, that's sensationalist. We just need to be discriminating in our use of process.
No true
Rob
Standard change was very V2 concept.
This is what the SS book says: A standard Change is a change to the infrastructure that follows an established path, is relatively
common, and is the accepted solution to a specific requirement or set of requirements.
Aale
Desperately seeking Standard
I'm glad Standard change was in V2 - where did you find it? SS 8.5.4 only talks about Minor, Significant and Major. 8.5.7 insists all changes need approval. I can't find the concept of pre-approval in V2, which is to me the essence of Standard change.
I used to teach it
It is in 8.3. I used to teach V2 Foundation and pre-approved standard change was quite important concept in my class.
CAB has always been a quite British and governmental concept to me and I used to say thet one cannot take it literally, not the way things work in Finland.
Smart Analyst, Not-so-smart Statement
This "Abolish the CAB!" sounds a lot like the recent “Fire All the Managers” remark from Gary Hamel on Harvard Business Review. I don’t know. Maybe we should abolish modern society and just go back hunting and gathering in order to do away with some of the problems we are facing now in the society. *grin*
CAB is part of a check-and-balance mechanism, and it can be implemented effectively via many different ways. I like Mr. O’Donnell’s work because I think his is a smart technology thinker. On this one particular remark, I think it is pretty dumb.
Rose?
Wasn't Shakespeare is the one who said "a rose by any other name would smell as sweet"?
As long as the risks are being managed....
CAB important
Change Advisory Board is a forum representing entire community of stakeholders. How can you drive the change without passing it through the vetting process.... It is this representation that is important. That's the key. The format of the board, the composition, the schedule - all can vary, can be fluid, flexible - depending on the organisation, and the nature of changes and implementation process.Board can be efficient or not efficient, but that's the question of design, it needs to be designed such as to fit the local circumstances. It can be dynamic, and virtual, and what not, but one overarching concern is to ensure that change request unser review is reviewed and approved by people directly involved and affected by it. How to put such board together is an internal to enterprise question, local ITIL practitioners, in charge of change management should know better. But important not to treat it as a sacred cow - fixed format, fixed schedule, fixed membership, fixed agenda, etc - that attitude needs to be abolished. The implementation of CAB need to be looked at creatively, otherwise it might just as well become a roadblock. In our organisation CAB is poorly implemented monstrosity of the fixed variety - as a result changes go in unapproved, with the resulting havoc in the organisation..... That is changes are unapproved by those who should be approving them, and approved by those who have no business approving the changes. In my previous organisation (bank too) CAB did not exist as a board meeting, but was of virtual nature, there were fixed approvers and variable approvers to a change , and usually that representation included implementors, developers, IT users, business users, and potentially affected IT and business stakeholders from adjacent groups - was highly efficient.
I'm not so sure
The usual situation what I have seen is that the people who decide most of the changes are not in the CAB. The business owns the applications and they decide what to do with them. IT CAB or CABs are just an organization which manages the technical domain.
Aale
Hmmm... CAB
I'm working in IT in a bank owning several processes, change mgmt included. We have never implemented formal CAB as we could not see the purpose for it in out environment. We have 500+ people in IT and do up to 200 change implementations per month. Two things that might have made CAB obsolete:
1) our change mgmt process is concerned with mainly change authorization and not approval. Approvals for Change Requests and Projects go through Project Mgmt Process. So when the change is ready (build & tested) it's more of question how then why or when.
2) each change implementation requires approvals from possible affected IT Service Owners. Currently our ratio of task execution to approvals are 4:6 - so for 4 task executed by various teams during the change we've got 6 different teams approvals.
I believe that second step eliminate the need for a CAB as all stakeholders see what might impact their services and have to give approval. It's a kind of continuous CAB.
totally agree
Totally agree Rob - Whilst the CAB is often flawed through its misunderstood execution, the CAB function is essential and makes perfect sense.
The biggest mistake I see is the CAB process becoming bloated and slow as a knee-jerk reaction to service interruptions due to either unauthorised changes or badly executed changes. I.e. people are trying to focus on the preventative measures rather than digging to find the root-cause of these service interruptions.