Change Management & CAB

[ChrisPope]

Why start with Change, its all good right? Possibly the most dreaded of ITIL processes, one that strikes fear into the hearts of IT resources due to its reputation of being bureaucratic, slow, monolithic, and a blocker to getting the job done!. With so many acronyms in IT these days, there are not many that put the fear of 'Gxx' in people as the dreaded 'CAB'.

Too often during ITSM projects or process re-engineering exercises, multi-day workshops are planned where the stakeholders gather like the Conclave, by the end of which the only smoke released is through shear frustration. Many organisations design the change process with the thought that all eventualities have to be covered, every resource or approver will always be available during all hours of the day, and the workflow will magically be transparent and simple enough that Changes will flow through the system, like butter off a hot knife. Now, back in reality, we know this isn't always the case. Change Managers are rarely born or grow up in the ranks of infrastructure or application development teams, where they know first hand what it takes to get the job done but also ensuring that risk to the organisation is minimised when implementing new capabilities or modifying existing ones. Change Managers rock up with their ITIL Badges, flip flops and often wearing a cardigan, with the perfect process model in mind, visio diagrams as far as they eye can see and a pipe dream of the perfect toolset to support them.

Sound familiar? Implementation resources often complain that it takes longer to get a change approved than it does to implement, or who the heck approves this anyway, I am just the Network guy getting stuff done.

The best change management and CAB processes I have seen are far from this. The CAB by definition is 'A dynamic group of people (depending on the change) that approve Changes with medium to high priority, risk and impact.' The key word in this for me is 'dynamic'. In other words the audience and participants change, its not static. Ask yourself how often you have sat through the weekly CAB knowing full well you don't need to be there, and its an hour (or 2) of your life you will never see again.

Mandatory attendance immediately devalues the purpose the CAB and also the respect of resources time. The key to enabling a dynamic, responsive CAB is in the data used to drive it. If a change represents a higher level risk, priority or has widespread impact then it should represent that. Change is one of the biggest consumers of a good CMDB, but also people and hierarchy data. Ensuring the right people are notified or approval requested, first time right time, is key. Valuable time is not lost in the approval process and figuring out who needs to do what. (See another blog series on CMDB on how to get that right! Click Here)

Change Management often resembles a waterfall project, when in reality it really needs to be agile and ever evolving, improving based on past performance and experience. Governance and audit requirements often scare IT folks, but in reality they shouldn't. If the process supports a higher level requirement to demonstrate control and accountability then it essence it should enable IT to absorb more change, more reliably and more consistently

There is good news though. The Change Manager is no longer the 'Department of No!'. That title and honour has shifted to the Security team…Congratulations and you are welcome!