Change enablement (or change management if you’re using ITIL v3 best practice) is the ITIL 4 management practice that introduces changes into the live environment in an orderly and safe way. Successfully balancing value and risk. Used effectively, change enablement can facilitate everything from essential maintenance to full-on transformation projects. To help, here are ten tips for running your organization’s change enablement practice like the IT service management (ITSM) pro you are.
Tip #1: State your change enablement intentions
Have a change enablement policy such that everyone knows the scope and exactly what’s expected of them. Set out your dos and don’ts such that everyone is clear on what is and isn’t acceptable in your organization.
Every company will have slightly different rules. For example, highly regulated industries such as financial services or pharmaceuticals will have very tightly controlled environments. Whereas other sectors for example tech startups will have fewer regulatory restrictions. So, set your stall out accordingly.
Tip #2: It’s all in the training
Train everyone in your IT department on what constitutes a change such that no one can use the “Oh, we didn’t know that was a change” excuse. Train your people on how to raise changes, how to represent them at change advisory board (CAB), and most importantly what counts as a pre-approved change (something that you’ve already set out in your policy and practices).
Tip #3: Know your business stakeholders’ appetite for risk
Sometimes in IT, we get so focused on avoiding risk that we can end up doing the wrong thing(s). And there’s no such thing as zero risk. So, for example, we all know that most businesses implement change freezes around critical business times. But what about the freezing of security patching? Potentially resulting in unplanned downtime due to a vulnerability that would have been patched if the monthly patching exercise had been allowed to go ahead.
So, know your business and its appetite for risk and go from there.
Tip #4: Make it easy for people to raise changes
Another “gotcha” in the change management/enablement game is getting too wrapped up in the toolset. Just because your ITSM tool offers you 50 different fields on your change form doesn’t mean that you should have 50 different fields on your change form (or, even worse, 50 mandatory fields on the change form).
So, ask for what’s needed rather than what might be useful at some point. If nothing else, it will result in better quality information because people aren’t daunted by having to provide those 50 pieces of information.
Tip #5: Use standard changes whenever applicable
Continuing the thread of making it easy to raise changes, get the ITSM tool to do some of the heavy lifting by creating standard changes.
Standard changes are pre-approved small pieces of work that are tried and tested and have very little risk associated with them. For example, making network ports live, restarting servers in your test environment, and moves of less than ten users.
Tip #6: Delegated authority can prevent mid-level risks hitting the CAB
If a change is a slightly higher risk than you're comfortable with for the standard, pre-approved change route, then another option is to use “delegated authority.”
Delegated authority is where you have an owner for each area who can approve a change up to a pre-agreed level of risk. Delegated authority changes have a higher level of scrutiny than a pre-approved change but require fewer resources, and less of a delay, than a CAB-processed change request.
Tip #7: Streamline your CAB’s workload
If you use standard change and delegated authority models effectively, then your CAB should be one of the most straightforward meetings in your department.
By shifting the focus of your CAB from every change (because, let’s face it, how many of us have been in organizations where everything has gone to the CAB “just in case”) to just the big, complicated, medium to high risk planned works, you focus the CAB on what matters most. Catching flaws in testing, making sure that an implementation plan is rock solid, and ensuring that any downtime has been agreed with the business.
Tip #8: Use Kanban for greater change insight
Use Kanban boards, within your change enablement practice, to increase visibility and flow. Kanban boards will enable your teams to visualize work, limit work-in-progress (WIP), and maximize efficiency and flow. For example, once a change has been authorized and progresses through implementation, the Kanban board will be updated such that all parties have a visible representation of what stage each change is at.
Tip #9: Plan for emergencies
It sounds counterintuitive, right? We have a policy, everyone’s trained, and we have models and meetings, so what could go wrong?
The reality is that, despite all our very best efforts, things can and do go wrong. That server that needs intervention otherwise it’s going to fall over in the middle of the working day. That security vulnerability that needs to be patched yesterday. That marketing campaign that the business is flagging as mission-critical.
So, have a plan in place for curveballs, such that you can at least mitigate risk. Sure, emergency changes won’t have the full checks or impact assessments, but you can at least make sure that any critical testing is done and that the change is deployed in a controlled and safe manner.
Tip #10: Learn from your mistakes
Sometimes it’s not about executing every change perfectly 100% of the time. Instead, it’s about responding when something hasn’t quite gone to plan. Very few things in life are perfect, so if something goes sideways, capture it, understand what happened and why, and then look at the required actions such that it doesn’t happen again.
What change enablement tips would you add to these? Please let us know in the comments.