Branimir Valentic Every now and then, there is a need to make an easy, minor change. For instance, most people (be it a user, or someone from the IT Service Management (ITSM) team) don’t consider resetting a password to be a – change. But, according to ITIL – it is.
To dive deeper, ITIL recognizes different kinds of changes. That’s logical, because changes are different in many respects (a bit more about this later). For the purpose of this article, let’s consider changes like the example above, i.e., something that doesn’t actually look like a change, but it is. More precisely – a standard change.
Standard change – What is it?
So, not every change is – a change. Yes, there are differences. For example, reinstalling someone’s PC is not the same as changing operating systems (e.g., Windows 7 to Windows 10) for a company of, let’s say, 1000 employees. Budget, scope, risks, resources . . . there are a lot of differences between them, aren’t there? Though both examples are, actually, changes – it’s obvious that they are different.
First things first – what is a change? According to ITIL, a change is “the addition, modification or removal of anything that could have an effect on IT services.” The ITIL approach to Change Management, as well as different types of changes, is explained in the article ITIL V3 Change Management – at the heart of Service Management.
A standard change is a pre-authorized change with low risk and an approved budget. Pre-authorized means that there is no authorization procedure needed. Implementation activities are well known and proven. Budget is preordained (usually in the scope of the budgeting process). There are no significant risks related to such changes, as everything is clear and well understood.
How to use it?
By using a standard change, you have the opportunity to put under control some routine task that impacts IT services or users, without creating a complex environment that will slow down the process. In order to have an efficient standard change process, here are a few tips on how to handle them:
Logging / documenting – I’m sure that most of you are familiar with the Request for Change (RfC) – a common form that triggers a change. And, that’s correct; i.e., this is the way to initiate the change procedure. But, how about standard changes – do they need a RfC? Well, not such a formal one, but they do.
Service requests are the ideal way to handle standard changes (read more about managing service requests in the article Managing Service Requests in ITIL/ISO 20000 using the Service Request record). It could be argued whether standard changes need to be documented at all, but from my experience – do it. Yes, it’s not a big issue if someone requires a password change, but if half of the company requires password changes after you change the password complexity – that could be problematic.
Plan it well – Standard changes are not complex changes, but they could (if not performed correctly) cause harm all the same. Take, for example, the above-mentioned password change. One way to handle such a change is that everyone can call in and request a password change, and the other way is to introduce (at least) some identity check.
To be honest, it’s quite difficult to resolve secure password changes, particularly in bigger organizations. But, some level of security needs to be in place. What’s important is that whatever the change (a password change, in this case), a defined, proven, and agreed set of activities must be established. And, I would add (because I have seen some bad examples) – communicated to all relevant parties. That could include users, as well as ITSM (IT Service Management) staff. Regular monitoring regarding whether the change procedure is followed (and efficient) is also something I would recommend.
Manage your routine activities – A standard change is your chance to get (at first glance) some routine activities under control. That could be something like a user’s PC reinstallation or desktop setup with a standard set of applications/tools (usually pre-budgeted), moving a user’s equipment (e.g., desktop, monitor, and printer) from one place to another, minor changes to some application (e.g., standard application patching), extending your storage area, etc.
Although standard changes sound simple, every organization needs to decide for itself which kind of changes are going to be standard changes. To decide that, consider the risks related to that change, costs (are they known or not, how high are they), the impact (local, e.g., a single user, or the whole company), etc.
The benefits
So, as you can see, standard changes are not some complex issue, and they don’t generate significant costs or require many resources. But, on the other side, they need to be controlled (like many other things in the scope of ITSM). Control sounds bureaucratic, but actually, it’s your chance to get feedback regarding usage of (ITSM) resources, user behavior, or even (potential) pitfalls. What you do with the recorded information – well, that’s up to you. But, what I see as an argument with regard to recording standard changes is that it’s your opportunity to keep control, not just over your services, but over your users’ behavior as well.
“For what purpose?” someone could ask. It’s improvement – not only for ITSM processes and teams, but for users as well. By initiating many standard changes, it implies that your users are stuck somewhere. Help them, and you have helped yourself. Further on, once improvement is implemented (based on analysis of standard changes), your users will feel better, too. No matter whether they know it or not, it’s for mutual benefit.
Use this free ITIL Gap analysis tool to compare your change management process to ITIL recommendations.
