IT has been calling Change Management by that name for decades. In the latest update to the de facto ITSM framework – ITIL®, the practice has unceremoniously been renamed to Change Control. A move that some feel hearkens back to the worst elements of bureaucratic, command-and-control that many attribute to ITIL to this day.
Nothing could be farther from the truth, as I’ll explain.
Process or Practice?
As you know, a process has inputs, activities, and outputs. With this lens, the all-too-common CAB-centric Change Management looks a lot like a process.
The inputs? Change requests.
The activities? Filling out the Change Request form, reviewing the change at a formal meeting, implementing the change and so on.
Starts with a request for change (input) and ends with an implemented change (the output).
And as a process, work flows through it.
For years, I’ve refuted that Change Management is a process. I’ve contended that Change Management is an organizational capability to bring about outcomes desired by, and beneficial to the business. In short, I’ve maintained that managing individual changes such that they do no harm is a part of Change Management, but not the entirety of the capability.
It’s the exclusive do-no-harm focus of Change Management (as a process) with which I take exception. This focus has spawned the nearly universal understanding that Change Management is a quality inspection point between the completion of the work and prior to releasing into production.
Even a passing familiarity with W Edwards Deming suggests this focus is wrong. He famously contends that we “must cease reliance on mass inspection” (i.e. quality assurance at the end of the process), that “quality must be engineered in”, and that “quality is everyone’s responsibility” (i.e. not just CAB).
Deming’s views are antithetical to the commonly-practiced CAB approach, for which ITSM is so widely criticized, especially from Agile/DevOps corners.
They’re not wrong.
In practice, there is limited value in a last-check CAB. Dr. Forsgren pointed out this fact in her infamous “CAB is useless*” comments from a talk she and Jez Humble gave at DOES18 on the Data Behind DevOps: Becoming a High Performer. (Comment at about 29:30)
She’s speaking, of course, from a data analysis perspective (documented in Accelerate), finding no correlation between existence of ‘CAB’, and 2 specific change outcomes (failed changes, and recoverability).
Interestingly, moments later, Jez Humble goes on to suggest that CAB serve more of a change governance or oversight role where it has value (in improving overall change outcome achievement).
Which brings us to a fundamental paradox.
If Change Management is a process, then changes have to flow through that process. Flow stops while awaiting CAB review, with questionable ability to add value.
But if it’s a capability (“practice” in ITIL4), then it’s part of the organization’s ability to achieve change-related objectives without obstructing flow.
That is the point.
What’s in a name?
So, why Change Control?
In my view “Change Management” has a subtle implication that its focus is on managing each-and-every change.
Change Control, on the other hand, seeks to control the circumstance in which changes are developed consistent with the organization’s change outcome expectations.
In other words, Change Control provides oversight and governance on how the organization produces changes – In the Value Stream.
Let me repeat – changes are controlled in the value streams that produce them. No QA inspection at the end, no waiting for CAB.
And that’s significant because, as commonly practiced, CAB is easily the leading cause for anti-ITSM sentiments.
As Change Control must understand (and improve) the circumstances in which changes are produced, we turn our attention to engineering quality into the development (in this context, I’m not referring exclusively to software development, but rather to the activities associated with producing (“developing”) any change.)
I use the analogy of a rifle. Once the sites of a gun are calibrated, they can be used by a skilled marksman to hit the target. The analogy is telling, in that the attention is on first making sure the sites are accurate, and then making sure they’re trained on the correct target before pulling the trigger. The emphasis here is that once calibrated and aimed properly, we have a high degree of confidence that it’s going to hit the target.
To be dramatic, we don’t stop the bullet at the end of the barrel and check to make sure it’s the right bullet, is trained on the desired target and we’re confident it is likely to hit its target. We recognize how fruitless and unworkable that is.
In Change Control, like ballistics, we should not pull the trigger unless/until we are quite certain of the desired target and quite certain it will be achieved.
It’s this very certainty that allows us to ‘fire at will’ (release as frequently as required to meet business need).
In Shift Left terminology, this shifts the focus to before the change development begins and away from after it’s been completed. In practice, this works very well with product owners, sprint planning, and allows Change Control to support modern approaches (like DevOps, Agile, Continuous Integration/Continuous Deployment)
In order for Change Control to shift its focus, it has to understand the change outcome performance of the various change-producing value streams.
This is accomplished by tracking and monitoring the outcome performance of each value stream. Things like:
- Number of failed changes
- Types and causes of failed changes (continuous learning)
- Business impact of failed
- Incidents, problems
- Feature failure
- System failure
- Catastrophic service outages
- Recovery time
- Business-impacting down time
- Blast radius of failed changes (“how much is impacted if something goes wrong?”)
- Incidents, problems
The list goes on, and this is hardly all-inclusive – the point is simply that change outcome performance must be understood for each change-producing value stream.
It’s also worth pointing out that this is done in conjunction with the teams, not to them. Teams practicing the elements of agile and the ways of DevOps are already continuously learning and improving their practices.
So, no CAB, then?
Before I answer that, let’s look at risk management briefly. We all recognize that not all changes are created equal. Some changes have higher risk (to the organization) than others. Some changes are so significant that they put the very viability of the business at risk.
These are not the kind of changes that should be delegated to development teams. These are business risk decisions and should be made by informed, accountable people in the organization, who are empowered with sufficient authority to make such risk-based decisions on behalf of the business. These are the people who will not be fired if a change goes awry, because they have sufficient authority.
Changes of this magnitude may very well be served by a review meeting of some sort – often in conjunction with project management.
So, call it Risk Assessment, call it Change Review, call it what you like. The point here is that it’s the outcomes Change Control is seeking to ensure, not so much the form or process used to accomplish.
So, here’s my tweetable quote regarding CAB and Change Control:
So long as the organization’s change outcome expectations are being met in the value stream, CAB cannot add value to individual changes.Greg Sanker
As you can see, Change Control is way more than a new name for the same old Change Management. All changes start with a need (demand/opportunity) and end with business value. Change Control seeks to influence the circumstances in which changes are produced such that the organization’s change outcome expectations are consistently met.
The difference is significant and worth paying attention to.