1. Change Enablement Is Not Change Control

For many organisations, the word “change” still creates an almost automatic reaction: approval, CAB, risk assessment, implementation window, approval again.
And somewhere along the way, Change Enablement became synonymous with Change Control.
That is a problem.
The purpose of Change Enablement isn't to stop people from making changes. It is to enable beneficial change while managing the risks associated with it.
That is a very different proposition.
When control becomes the objective
I've seen change processes become increasingly complex over time. More approval steps are added because something went wrong. More fields appear because someone needs more information. More meetings are introduced because there is concern about risk.
Eventually, the process becomes so focused on controlling change that the organisation forgets why it is changing in the first place. The irony is that this can actually create more risk.
When legitimate changes become difficult to get through the process, people start looking for ways around it. Urgent changes become emergency changes. Teams find workarounds. Changes happen outside the ITSM tool. And the organisation ends up with less visibility, not more.
Risk isn't the enemy
Good Change Enablement isn't about eliminating risk. That's impossible. Every meaningful change carries some level of uncertainty.
The real question is: Do we understand the risk, and are we managing it appropriately?
A low-risk, repeatable infrastructure change shouldn't require the same governance as a major change to a customer-facing platform.
Likewise, a high-risk change shouldn't be able to move through the process simply because someone has filled in all the mandatory fields. This is where risk-based thinking becomes important.
Start with the outcome
Before asking: “Who needs to approve this?”
Ask:“What are we trying to achieve, and what could prevent us from achieving it?”
That changes the conversation.Instead of starting with process, we start with purpose.
Instead of asking whether a form has been completed, we ask whether the organisation has enough confidence to proceed.
And instead of treating every change equally, we consider factors such as:
Potential business impact
Customer impact
Technical complexity
Degree of uncertainty
Reversibility
Previous experience with similar changes
Dependencies
Timing
Regulatory or security implications
The level of governance should then reflect the level of risk.
What practical Change Enablement looks like
A mature approach might look something like this:
Low risk/repeatable - Automated or pre-approved wherever possible.
Moderate risk - Appropriate assessment and approval, with clear implementation and rollback plans.
High risk - More detailed assessment, stakeholder involvement and explicit accountability.
Emergency - Fast decision-making, but not a complete absence of governance.
The objective is not to create more process. It's to apply the right process to the right change.
Five questions worth asking
If you want to understand whether your change process is genuinely enabling change, ask:
Are we measuring how much change we process, or the outcomes it delivers?
Do low-risk changes receive unnecessarily high levels of scrutiny?
Can our teams easily explain why a particular approval is required?
Are people bypassing the process because it is too difficult?
Does our process help people make better decisions, or simply document decisions that have already been made?
Those answers can be surprisingly revealing.
The real measure of maturity
A mature Change Enablement practice isn't one where nothing goes wrong. It's one where the organisation can make changes quickly, safely and confidently.
That's a subtle but important distinction. Because ultimately, the goal isn't better change control. The goal is better change. And perhaps that's the mindset shift many organisations need:
Stop asking how we can control change better. Start asking how we can enable change better.
Next in the series: The Change Advisory Board Is Not the Decision Maker
Change Enablement - Beyond the Change Ticket.



Comments