Change Management is a hot topic lately on my social media channels. Like my friend Jon Hall, I also am a long time veteran of the classic Change Advisory Board (CAB) process. It almost seems medieval: a weekly or bi-weekly meeting of all-powerful IT leaders and senior engineers, holding court like royalty of old, hearing the supplications of the assembled peasants seeking various favors. I’ve heard the terms “security theater” and “governance theater” applied to unthinking and ritualistic practices in the GRC (governance, risk, and compliance) space. The CAB spectacle, at its worst, is just another form of IT theater, and it’s time to ring that curtain down.
As a process symbolizing traditional IT service management and the ITIL framework, it’s under increasing pressure to modernize in response to Agile and DevOps trends. However, change management emerged for a reason and I think it’s prudent to look at what, at its best, the practice actually does and why so many companies have used it for so long. 
This was the topic of my most recent research, “Change Management: Let’s Get Back to Basics.” In that report, I cover the fundamental reasons for the Change process. It has legitimate objectives — coordination, risk reduction, audit trail — that do not go away because of Agile or DevOps. The question is rather, how does the modern, customer-led, digital organization achieve them? The classic “issue a request and appear before a bi-weekly CAB” is one way to achieve the desired outcomes — and likely not the most effective means, as I discuss. 
As usual with research notes, there were a few ideas that didn’t make it in, either because they came up too late, or were too speculative.  
ChatOps is an important addition to change record keeping, providing a rich and detailed history of who did what when to critical systems, and what the discussion and reasoning were. 
Reconciling detected changes with Change records remains a useful practice, and can be automated, for example by integrating a detection tool like Upguard or Tripwire with an ITSM Change module. Policy-based infrastructure managers can also detect drift and integrate in this way. 
If we think of Change as a coordination problem, there are various ways to solve it. For example, there is the increasingly popular idea of the virtual CAB – coordinating asynchronously, rather than on a cadence. However, this may increase risk. People then must rely on some kind of boundary-spanning artifact or lower-bandwidth channel (e.g. a written description of the change, or a text-based chat) rather than more effective direct, face to face communication. 
Organizations often justify change in terms in terms of reducing risk. But does anyone link it to formal risk management? Too often, real world Change processes represent risk only in terms of the technical impact of the change failing. At best, the Change request references the affected business unit or process. But the true risk of the Change’s failure can’t be understood without fully understanding the potential business impact. At a business level, many enterprises invest in rigorous risk management, quantifying the probability and impact of various scenarios, and then implementing a controls approach. Has anyone integrated risk from a business-driven, GRC perspective effectively with their ITSM change process? Pulled in data from an Enterprise Risk Management system? If so, drop me a line. 
Finally, robotic process automation and AI would seem to have potential for accelerating Change management and automating some of the associated toil. Again, if you are exploring such avenues, please drop me a line. 

Note: This is my first official Forrester blog. I have joined the Infrastructure and Operations team, where I’m excited to be working with an analyst dream team.