Getting creative with CAB meetings

[SimonMorris]

"Look, you're the change manager. We've got to do better than this. We need better situational awareness, and that means we need some sort of functional change management process. Get everyone to bring in their changes so we can build a picture of what is actually going on out there."

To my surprise, Patty looks dejected. "Look, I've tried this before. I'll tell you what will happen. The Change Advisory Board, or CAB, will get together once or twice. And within a couple of weeks, people will stop attending, saying they're too busy. Or they'll just make the changes without waiting for authorization because of deadline pressures. Either way, it'll fizzle out within a month."

One of the many things that I enjoyed from reading "The Phoenix Project: A novel about IT, DevOps and helping your business win" was how the story cut through the plot, the characters and the words and went straight for the jugular vein of the reader. I've worked in IT Operations, I remember what its like getting that call in the middle of the night. I remember the frustrations with trying to get an effective change management process, and even more importantly... even harder... sustaining that process over time.

Gene Kim knew that his words would invoke a visceral, emotional reaction from his readers. I felt levels of despair, helplessness, hope and victory whilst reading the book.

The trouble with the process escalation race

At the point in the book where I've taken this quote, the protagonists have experienced multiple outages due to unplanned, unapproved changes. Patty is resigned to the fact that if they "reboot" the Change Advisory Board its only a matter of time until stakeholder interest wanes and engineers start to work around the system. Most importantly, she is saying that reinforcing the Change Management process becomes a reactionary response to the problem of outages, rather than a strategic response to reducing the risk of change.

When the change management process fails one common response that I've seen is "the process escalation" race. Add more process to the problem in the hope that next time it will stop a recurrence of the issue. For example, add more approvals, increase the lead time, more reviews of test plans and so on.

Not that these actions are necessarily bad - they might be perfectly sensible additions to a Change Management process - but it's the reactionary way that they are added that makes them dangerous. And without a thorough root cause analysis of failures introduced by bad changes, there is no guarantee that a recurrence will be avoided.

If your stock response to a failure is to instinctively add process to the problem rather than investigate the actual cause - you might be part of that problem!

And that goes double for Change Advisory Board meetings

Piling on the process is especially problematic with Change Management because of the nature of CAB meetings. High participation, hard to schedule, heavy on procedure. More than anything they are dull, dull, dull.

I wondered if the experience of CAB meetings had improved in the time since I'd been involved in actively running them. I put the question to the Back2ITSM Facebook group a few weeks ago for responses.

"I've seen some great change management processes, but the typical CAB meeting is still the same dire affair as it ever was"

"Time-suck death march! For the love of process efficiency why can't a CAB meeting be called if there's a major risk change that needs a true walk through or change conflicts."

"I find when people have an Advisory board, that everyone wants to give advice so the meeting turns into a long tedious discussion. When we changed the name of the meeting to APPROVAL and moved ADVICE to the Design phase, things started to quickly improve, move, collaboration....."

"Does anyone else find it interesting that all have such stories and yet the meetings are what they are? The question begs: If they are so obviously a waste of time, too bureaucratic, etc. then why are organizations letting them go on as if they provide value? No one questioning (silent suffering)? No one listening (denial)? "

"The CAB is the reflection of the organisational culture not the cause of it. Just like ITIL. You can't just make a better CAB. A CAB is a thing. Things change nothing. Change the culture and the CABs will be better. Work on behaviour. Start with a focus on facilitation in change not obstruction"

"Start by clearly segregating and defining the authority from the advisory board for each broad type of change. Even if that authority is a single person who makes the decision after CAB. Then you ask that person what they need to make a decision - whether it's record quality, advisors, lead times."

What can we do to improve Change Advisory Board meetings?

Unfortunately the experience of CAB meetings hasn't improved despite the Change Management process and product improvements in recent years. Patty, the Change Manager, still has the same challenges of gathering the right people to discuss the proposed changes, the same ensuing discussion and time limitations on getting everything into the meeting. When you hear the words "time-suck death march" you know there is room for improvement.

When your Service Management platform holds all of your Configuration data, change conflicts, identity, shift and skill data - there must be a solution there somewhere.

As we get closer to the upcoming Geneva release I'll be excited to share some of the improvements we've made for Change Managers. There were some great culture and process tips from the Back2ITSM group above but improved tooling always helps.

In the meantime, please share this article and also leave a comment describing your most recent Change Advisory Board meeting. Or have you transcended this problem and eliminated CAB meetings altogether. If so, you might be a very sought-after person for my next blog on Wednesday!

[Uncle Rob]

There's a real killer in there.   I'm beginning to wonder if the assumption that the "Service Management platform holds all your Configuration data" is a valid one these days.   That's aggravating the CAB problem.   Without the CMDB, its relationships, and its internal controls, what other option is there but to talk about everything we know?

Last cab I was in had 1/2 of all IT reading off a hard copy print out of the 30+ changes that were scheduled for that day.   That meeting happens every day.

[SimonMorris]

rfedoruk - thats a really good point. My perception (which I would love to have changed) is that the data isn't presented in the right way.

Yes - there is too much data in the CMDB that could be analyzed, but in the same way that social media algorithms are (supposed to be) presenting you with the right information you need, SM tools aren't doing that today.

What is the one key bit of information that would help a Change Manager make an informed decision and how do we present that at the right moment in time?

I can understand why it would be advantageous to a team to read from a printed copy because it narrows the amount of information to the bare facts, rather than misleading with dozens of unrelated attributes. How can we get the point of decision making back into the tool with enriched information.

Would love to know! Thanks for the comment

[Uncle Rob]

The thing about Social Media algorithms is that (1) they have a massive captive audience (2) keeping them captive is what drives revenue and (3) there are teams of extraordinarily talented people driving the algorithms.   The effort readily translates into gain for both the social platform and for the users.   On the IT support side of the house (1) everyone wants to minimize their in-tool time (2) keeping people in tool reduces time for all other work and (3) CMDB is rarely staffed (if ever).

And that's what I think is killing things lately.   Everyone says they want faster, smarter Change, but they can't *pay* for it with the faster smarter CMDB

[Uncle Rob]

For those attempting to tackle the CMDB issue, the problem is usually too much raw data ("lets discover $%&#ing everything")

In those cases the speed bump on Change Management is "how do I easily associate changes to the configs"

[SimonMorris]

I agree with you on your analysis, although I wasn't suggesting an algorithm that is literally like a social media promotion one. Just that the user experience of being fed relevant information is one that is lacking.

Regarding your comment on too much raw data through discovery... I like provocative statements and "You might get a better CMDB by turning off discovery for a while" might be as provocative as it gets for today

[ecracer]

New vision is to utilize the data in the CMDB paired with clearly and completely described change.   Within the change, goal is to implement a change rating algorithm that factors priority, risk, conflicts, etc. to identify only those few that must be reviewed in CAB.   The remainder, facilitating review through (hopefully) comprehensive group of reviewers on-line.   If all approve... change authorized and CAB bypassed.   Any reviewer would have the ability to push to CAB.   Not implemented yet - in early stages of design.   CAB then becomes more information about what is happening with a few critical changes reviewed vs. endless recitation of "this change is about..."   Cultural change to address.   Trust required.