What’s so standard about a Standard Change?
The term “standard” varies greatly based on context. In gardening, a standard is an ornamental way of growing shrubs, so that there are no lateral branches below the head of the plant.
In technology, standards are published documents that establish specifications and procedures designed to maximize reliability and interoperability.
And in common parlance, a standard can be a level of attainment or quality, but can just as easily mean “within the normal range” for a class of thing.
That common definition tends to lead us astray when taking an ITIL perspective on Standard Changes, because while Standard Changes are indeed very normal things, there is more to them than that.
Standard Changes are typically low risk, highly repeatable, and pre-authorised.
Many people use the term “Standard Change” to refer to anything that fits these criteria. But there’s another important thing about Standard Changes that’s often forgotten, and it’s in the name; a Standard Change is a change that has been standardised.
There are a lot of changes we make that probably could be Standard Changes.
But the ability to pre-authorise a change doesn’t stem from blind faith. It comes from understanding the change well enough that we can authorise the general case, rather than each specific example in turn.
Even if you’ve made the same change a hundred consecutive times without incident, that doesn’t mean that you understand it – although, of course, it’s compelling evidence that the change is low risk!
To correctly follow the process, the extra step is that we need to evidence our understanding. We need to show that we’ve considered that change in the general case, in sufficient detail that we can let it run indefinitely without further resolution.
That means that we need to describe a workflow for the change, describe our understanding of the risk, and we need to codify a rollback plan. The change may never have caused adverse effects before, but we need to understand what we would do if something went wrong – so that we don’t find ourselves trying to reinvent the wheel during a crisis.
The key is that we think about it once, so that we don’t need to think about every time it comes around. But we do think about it once!
When we’ve decided to standardise a change, we will typically create a template in the UniDesk tool, further simplifying the logging and tracking of standard changes.
If you’ve got a good candidate for standardisation, get in touch with the ITIL team.
Our Change Manager is happy to work with you to create a template that saves time and energy; for anything that you do more than a few times a year, it should be a boon.
Recent comments