What’s in a name? The etymology of the Go CAB
Hi folks, Matt here again!
One of the first big changes that I was responsible for after coming into post as Change Manager, was to implement a regular, weekly CAB. You can thank James Jarvis for the name: Go CAB.
If you didn’t already know that James came up with that name, you might have been able to guess; it’s dynamic, to the point, and ever so slightly irreverent.
The Go CAB was never just going to be called “The CAB”, even though it is centralised across all of Information Services, and even though it does occupy that kind of position of authority.
While we were spit balling for names during the consultation phase, it was important to me that we reserved a conceptual space for other CABs to coexist – because the weird truth about the Go CAB is that in a classic sense, it isn’t exactly a CAB at all.
Now don’t get me wrong, the Go CAB isn’t an unusual CAB.
Far from it, in fact. While it may not be a true CAB, it does what everyone expects a CAB to do; the Go CAB authorises or rejects work that people are planning to do. Actually, the most unusual thing about the Go CAB is that it knows that it isn’t really a CAB. Most CABs in Higher Education proceed in a very similar fashion, without ever realising that although the job they’re doing is very important, it isn’t strictly what ITIL suggests a CAB should be doing.
You see, a CAB according to the classical ITIL definition is a Change Advisory Board, and its responsibility is to advise (note: not decide) on which changes are good for the service, and which are not. And ultimately all this is in the run up to deciding whether or not to do a thing at all. That’s Change Management in action.
In Information Services, the Service Owner is the person accountable for deciding what changes should be made for their service(s). How do they decide? Well, hopefully they don’t make all their decisions in a vacuum. In practice, often they will call for the advice of various stakeholders, such as a user group, or a steering group, or some kind of board. Sometimes, they go as far as to run a genuine CAB (see the UniDesk CAB, or our oldest CAB, the Desktop CAB).
As we progress our maturity, we should expect to see more standardisation in how these decisions are made, but we might never truly centralise these decision points, in the way we must do for the Go CAB.
Meanwhile, the Go CAB really doesn’t have a lot to say about whether a change is a good idea in principle. The Go CAB is about judging whether a planned release is safe, well prepared, and doesn’t take unnecessary risks.
In other words, the Go CAB is a Release Gateway, or a Go/No Go checkpoint: at any rate, from the Service Management perspective what it is doing is Release Management, rather than Change Management. And that’s why the name Go CAB is such a good name for that group.
(Besides, this writer shouted down many worse suggestions such as RAB, RAG, rCAB, and others).
It’s also why there are other (usually service-specific) CABs floating around in IS. The Change Management decision (should we do this thing?) exists in a whole other domain than the Release decision that the Go CAB centralises (can we do it now, like this?)
Hope that’s an interesting insight into what’s in the name “Go CAB” – and the split between Change and Release decision points.
The ITIL team, and myself in particular, will be happy to advise folk from IS and further afield on either Change Management OR Release Management, so drop us a line if you want to continue this conversation!
– Matt
Recent comments