Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.

ITIL Tattle

ITIL Tattle

Blog posts on ITIL and ITSM news and best practice from the ISG ITIL Team

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.

photograh of a white rose standard

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.

Leave a reply


Report this page

To report inappropriate content on this page, please use the form below. Upon receiving your report, we will be in touch as per the Take Down Policy of the service.

Please note that personal data collected through this form is used and stored for the purposes of processing this report and communication with you.

If you are unable to report a concern about content via this form please contact the Service Owner.

Please enter an email address you wish to be contacted on. Please describe the unacceptable content in sufficient detail to allow us to locate it, and why you consider it to be unacceptable.
By submitting this report, you accept that it is accurate and that fraudulent or nuisance complaints may result in action by the University.