How to Deal with a Change Approver “Refuser”

One of the key roles within the ITIL 4 change enablement process is that of approving changes so that the benefits can be delivered to end-users and other business stakeholders. Delayed or missing approvals can kill weeks or even months of change planning, communication, and prep work – not to mention causing delays that could inconvenience and even disrupt the business. So what can you do to address the issue of change-approver “refusal”? To help, this blog considers the most common reasons for change-approval delays and how to respond to them.

Do change approvers fully understand the corporate change enablement process?

Let’s start with the basics. Sometimes when we perceive someone to be a blocker to getting things done, it’s easy to become frustrated and to miss things. So first make sure that it’s not something obvious causing the issue.

Does the person, or people, in question understand that they’re meant to be approving changes? This sounds like a really silly question I know but every company does change differently. Some use consensus, some have change advisory boards (CABs), and some have approval groups where if the majority approves the change it automatically progresses.

Change approval can mean different things to different people so before you do anything else, please make sure the person you have an issue with knows that it’s part of their role to review and approve changes.

Understand the “why”

The chances are that the person holding up change progression isn’t trying to be deliberately obstructive. So here are some things to consider when resolving the issue:

• Do they know how to use the change-related tools? Has the person had appropriate training in using your organization’s IT service management (ITSM) tool? Are they completely comfortable using it or is it time for a quick refresher session?
• Is it an admin thing? Some people are just terrible at admin. They have every intention of doing the task asked of them but then either forget, get distracted, or have to prioritize other things. This is another easy fix – if it’s purely a person being bad at admin, rather than a fundamental concern about the change, then delegating approval to a trusted peer or second-in-command is a quick solution.
• Is it a procrastination issue? Is the person uncomfortable in making a decision so they kick it down the line? Or they hope that it will go away if they delay things long enough.
• Is risk the root cause? Every company will have a different approach to risk. If you work in a highly-regulated environment, then the decision-makers will likely be more risk-averse and you will need to factor this into your change process.
• Is the fear of change the key blocker? Most people are happy with the status quo and, for some, the worry is that by making a change it could make a situation worse.
• Are incorrect assumptions being made? Some folks jump to conclusions and are quick to make judgments about the outcome of a change without having all the facts. Factor in history or previous experience; they might point to previous ideas that have not succeeded and convince themselves that history will repeat itself if they authorize the change.
• Is it another factor? I once had a stakeholder who would consistently reject changes even if they were not in a change freeze period. When I spoke to them about it, it turned out that he was adding an “unofficial” restriction period two weeks ahead of an already planned change.

Dealing with reluctant approvers

We’ve covered why someone might refuse to approve change activity, now let’s look at how to move forward with removing these obstacles. Here are some suggestions:

• Look at your tool. If your change tool is difficult to navigate, consider looking at the workflow. Make it easy for people to review and approve changes. In an ideal world, this could be done in less than three discreet clicks and support mobile devices so that the person can hit approve from their device of choice.
• Use delegated authority. Can this capability be used if it’s an admin-related issue?. The change reviewer gets a set time to review the change but if a decision hasn’t been made, then the approval is sent to the next approver in line.
• Look at your approval matrix. Can that change approver in question be one of a pool of approvers so that others can approve if life gets in the way?
• Set out the risk(s). Does the change reviewer understand the risk(s) of the change not going ahead? For example, delaying security patching or essential maintenance increases the risk of cyber-attacks or technical debt. An easy way to highlight this is to have a section of the change form dealing with just that. Here, having the impact of a change not going ahead set out in the change document makes it more difficult to ignore.
• Counter assumptions with facts. Often, someone will reject a change because the wording of the change isn’t clear, or the impact is too difficult to understand. When training colleagues on how to raise changes or to represent them at a CAB, ask them to go by the golden rule of “always make it easy for someone to approve the change.” So, make sure the work is clearly explained and the affected services are highlighted such that the person reviewing the change can make a properly informed decision.
• Convene a CAB. I’m the first to argue that most changes don’t need to go to a CAB but if a change is high impact or there’s a real concern, then sometimes the most effective way of dealing with it is to talk it through.
• Decrease people-based blockers. Reduce the reliance on approvals by having change models and standard changes. If something is low risk and has a tried and tested approach, then consider using the standard change approach so it that doesn’t need to be approved each time.
• Increase flow by making planned work visible. The use of Kanban boards can be a really useful way of highlighting pipeline activity so nothing should come as a surprise to the colleagues approving changes.
• Escalate. When everything else fails, go higher. It’s never fun having to raise a concern to senior management but if someone is refusing to engage with the change process then it needs to be called out and acted on.

That’s my take on dealing with “reluctant” change approvers. What would you add? Please let me know in the comments.