Something that doesn’t get talked about as much as it should is how to handle colleagues who, for whatever reason, aren’t engaging with the change practice. Let’s call them “dodgers,” although other terms are appropriate. In an ideal world, your change enablement process would run smoothly – enabling changes to flow and be deployed effectively, efficiently, and safely with little to no unforeseen consequences or unnecessary admin.
However, if your change enablement process isn’t running smoothly, I’ve one thing to say – the clue is in the name people! It’s about enablement. But the unfortunate reality is that many organizations still struggle with unauthorized change activity that causes downtime and service disruption.
To help, this and a second blog explains what to do – across eight areas of change enablement – when you have colleagues who aren’t following the agreed change enablement process and how to turn things around to reduce risk, time, and costs.
1. Check training awareness
First things first, let’s not assume the worst. If you know that unauthorized change activity has happened, speak to the person or teams involved. Sometimes people genuinely make mistakes, so check the basics. Things to look for include:
- Have they received the correct training?
- Do they have the correct access to the IT service management (ITSM) tool used for raising changes and do they know how to use the change module?
- Are they aware of what actually counts as a change rather than an incident or service request?
Also, bear in mind that different organizations will handle change in different ways. Some companies will state that something only has to be raised as a change if it affects more than ten people, otherwise it’s a service request. Some will only require a change if the work is affecting a production system – whereas other organizations will require a change for test, development, and pre-production environments as well.
So, make sure that your training material is clear and leaves no room for misunderstanding. Plus, that it’s made available to the people who need it and ideally in a format that suits them.
2. Make it easy to raise changes
It sounds obvious doesn’t it – but is it harder than you think to raise a change in your organization?
Make it as easy as possible for people to raise changes. Automation and templates are your friends here because the more you can pre package as “change content,” the less potential there is for error at the change entry stage. Some things to consider are:
- Templates – ask your technical teams what their top five or ten changes are and then template them so that all people have to do is input the dates and send the change off for approval. If raising a change is a two-minute task, people are less likely to forget to raise them.
- Standard changes – level up from templates by using the standard change model to deal with low-risk, routine work that follows a tried and tested deployment procedure. Standard changes are usually pre-approved, so it really is just a case of selecting the correct template and adding the change window. The system will automatically identify it as a standard change and authorize it – meaning the technician has raised the change and everyone can now see that work is planned for a particular time and date.
- Link with email – use automation such that, if a change is approved, it automatically sends a calendar entry to the person’s email client of choice. So, they know their change is approved and they get a reminder of the change window.
- Apps – one of my favorite sayings is “always make it easy to…” In this case, “always make it easy to raise changes.” We all use apps in our personal lives to do things quicker and easier. So, if your ITSM tool has an app option, make sure that folks can access it. Sometimes it’s so much easier to fire up an app and enter a change than it is to fire up your laptop, open the ITSM tool, and raise a change. Options are good.
3. Make it easier to get approval
One of the biggest causes of change errors is people not understanding how to get the appropriate approval. If you insist on everything going to a change advisory board (CAB) meeting no matter what the change is, then you’re missing a trick. Also, people will likely hate you because the CAB becomes a two-hour snooze fest where no one is paying attention and completely undermining the whole process anyway.
Here’s what to do in terms of approvals:
- Be clear on scope – if you only require changes to be raised for production environments, make it clear in your documentation.
- Employ delegated authority – set thresholds for each area so that managers can approve work up to a certain level of risk. By trusting subject matter experts to manage their own infrastructure you’ll increase flow and reduce the likelihood of someone not raising a change because the approval process is too painful.
- Be savvy with CAB attendee time – if something has to go to a CAB meeting then play nice with your attendees. If someone only needs to be there for five minutes, either have them represent their change first or give them a dedicated slot. Don’t make someone sit through an hour-long meeting if it can be avoided.
So, that’s our first three areas for reducing change process dodgers covered. What would you add to our list? Please come back soon for part two of this blog where we’ll look at five more ways to help prevent unauthorized changes.
