5 Things I Hate About Change

Change management is a wonderful process...until it isn’t. Here, an IT service and support pro who is well versed in this process describes a few things that go wrong, and provides tips for how to avoid these common pitfalls.

Change management is a wonderful process to help control the lifecycle of changes by enabling beneficial changes to be made with minimum disruption to services you provide. Essentially, we track the work we are doing and try to minimize downtime, user impact, and the risk of making changes to the services we offer.

On paper, change management is a really helpful way to track any addition, modification, or removal of things that can impact our services. In practice, it can feel like a whole lot of problems.

Here is where things go wrong:

1. What Needs a Change?

A primary issue with change management among practitioners is they can be unclear of what specifically needs to be changed. While this is well defined in the volumes of service management and ITIL best practices, your average practitioner may not remember the nuance of it.

To help out your change practitioners, it’s important to provide clear guidelines as to what the threshold for a change is in your organization. Tools like flowcharts and decision trees can help better figure out when a change should be entered.

With all of this in mind, it’s better to err on the side of too many changes than not enough at first. If you find you are getting too many changes for trivial things, you can adjust the policies to match, but it is better to have a change record than to not have one at all.

2. You’re Not My Real Mom

Simply put, change management can feel like extra paperwork, or busy work to someone who doesn’t see the return on their investment. A lack of “what’s in it for me” can cause folks to lose motivation to participate. Add to this the ever-present conflict between change management and project management and there can be issues with authority.

The best way to solve these issues is to get leadership buy-in and sponsorship for change. If the powers that be support it, the rest will, too. This may not always be possible, as leadership may be new to change enablement concepts, but you can help solve some of the other issues by making change as painless as possible. You can lower barriers to change documentation by making the process quick and easy, listening to feedback and helping show the benefits of change to practitioners.

Finally, don’t let change become yet another meeting. Work with leadership and project managers to fit it into a bigger picture and get it included into project planning, and consider even inviting PMs to sit on Change Advisory Boards (CAB) to have a stake in the process.

3. No One Says No Anymore

After a while you may notice that CAB feels like you’re going through the motions and voting members are just saying yes to everything with very little questioning about changes. Ideally, our change meetings will be productive and hold the right balance of discussion, but over time this can slow down.

Some quick fixes for this are to look at your membership. It could be that your current CAB membership is too broad, or attendance too inconsistent to enable meaningful discussion. With this in mind, you can refine membership by assigning various departments, teams, or interest groups assigning a full-time member to represent them. This can help keep representation equal, and prevent a rotating potluck of participation. It is important to remember that a successful CAB membership is diverse, cross-functional, and inclusive of all business units.

Another consideration is that as we shift terminology from change management to change enablement, we need to focus on the meaning of those words. Within change enablement, our goal is to enable change, not to become another barrier. If our CAB is doing its due diligence, and documentation is up to par, then it may be ok to approve everything quickly. This may just be a sign that we have reached productivity as a group.

4. Everything is an Emergency

You’ve had your CAB meeting earlier in the week, and now you see a huge influx of Emergency changes. Every change entered seems to be submitted after the fact, and without regular CAB process. This can be incredibly frustrating to see, as you feel like you are losing control or oversight of changes and like certain teams are gaming the system.

So how do we fix this? It’s important to establish clear expectations, guidelines, and timelines for how and when a change should be entered. By setting rules such as, “A change must be entered X days before CAB,” you are managing expectations, and setting up pathways for discussion when this isn’t the norm.

If there are serial offenders, it’s important to involve management and make sure they have buy-in to stop this in the future. You may also consider setting up off-cycle or emergency CAB processes to deal with these in case there are genuine off-cycle needs. Finally, tracking incidents or problems associated with these emergency changes may be a good way to show why these unapproved changes are problematic.

5. Bookkeeping

You love your ITSM Tooling, you’re thriving in it, you have an automated workflow and fields, risk assessment matrixes, and dashboards galore for your change process. But as you use it more, you find yourself constantly sending nudges to folks to fill out X field, or close out Y record, and now you’re doing less change management and more bureaucracy simulating.

One of the biggest issues that can lead to this is unclear expectations. Similar to setting timelines for entering changes, you will want to set timelines for closing them out. Making sure your documentation includes things like, “All changes should be closed out before the next CAB following their implementation” can help set expectations. I also recommend sending nudges and reminders where possible. This is especially great if your tooling allows this to happen automatically. If the issue is more so on the quality of records, you can also add in pre-approvals, where a change record first goes to a peer or a person’s manager for signoff.

Wait, there’s more! If you want to see five more things that Chris hates about change management, you can click here for the sequel to this article.