3. Standard Changes: Stop asking for permission to do the obvious
There is something slightly strange about asking for approval to do something you've already successfully done dozens, or hundreds of times. Yet this happens every day in IT organisations.
A routine change is raised, it goes through assessment, someone approves it, perhaps it goes to CAB and then someone implements it. And everyone moves on, until next time...
The missed opportunity
Standard changes are one of the simplest ways an organisation can make Change Enablement faster and more efficient. But only if we use them properly.
A standard change should represent a change that is:
Low risk
Well understood
Repeatable
Documented
Proven
Appropriately authorised
The important word here is proven. A standard change shouldn't simply mean “we think this is safe.” It should be based on evidence.
Automation changes the game
The opportunity becomes even greater when standard changes are automated. Consider something like provisioning a standard development environment.
Historically, someone might:
Raise a request
Create a change
Wait for approval
Provision the environment
Update the ticket
Close the change
With automation and infrastructure as code, much of that can become a controlled, repeatable workflow.
The governance doesn't disappear. It moves upstream. The organisation approves the pattern, rather than repeatedly approving every individual execution.
That is a fundamental shift.
Pre-approved doesn't mean uncontrolled
There is sometimes concern that standard changes mean “no governance”. Quite the opposite. Good standard changes have stronger controls because the organisation has deliberately defined the conditions under which they are safe.
Those controls might include:
Defined scope
Approved implementation procedure
Automated validation
Monitoring
Rollback
Clear ownership
Defined failure criteria
Regular review
The change becomes predictable and predictability is exactly what good Change Enablement should be trying to create.
But standard doesn't mean forever
One trap is treating standard changes as “set and forget”.
Technology changes.
Architecture changes.
Dependencies change.
Risk changes.
A standard change that was low risk two years ago may not be low risk today. That's why standard changes should have an ongoing review mechanism.
Look at:
Failure rates
Incidents
Rollbacks
Customer impact
Security concerns
Changes in technology
Changes in architecture
If the evidence changes, the classification should change.
A simple maturity test
Look at your standard changes and ask:
Can this change be automated?
If not: Can the procedure be simplified?
Then: Can the approval be delegated?
And finally: Can the organisation learn from every execution?
The ultimate goal is not simply to have a large catalogue of standard changes. It is to create a delivery environment where safe, repeatable work becomes increasingly frictionless.
What should you measure?
Don't just measure how many standard changes exist.
Look at:
Success rate
Failure rate
Rollback rate
Incidents following implementation
Time saved through automation
Percentage of changes moved from normal to standard
Number of standard changes removed because they are no longer appropriate
That last metric is important. Maturity isn't about continually adding process. Sometimes maturity means removing it.
The bigger lesson
Every successful repeatable change is an opportunity to ask: Why are we still treating this as a one-off decision? That's the mindset shift.
We shouldn't need to repeatedly prove that something is safe when the evidence already exists. We should use that evidence to make the next change easier. Because Change Enablement at its best doesn't just manage today's changes. It learns from yesterday's changes to make tomorrow's changes better.
Next in the series: Emergency Changes—when everything is urgent, nothing is.
Change Enablement - Beyond the Change Ticket.
Comments