5 More Things I Hate About Change

In part 1 of this series, IT service and support pro Chris Chagnon listed five ways that change management can go wrong. He was just getting warmed up.

Here are five more ways the process can derail, and tips for how to get it back on track.

1. No Minute like the Last

It’s the day of CAB and your slate for the meeting is looking a bit light, today is going to be a quick CAB! You go grab a coffee before the meeting, and come back to a dozen changes entered minutes before CAB.

The same expectations we are setting for change type and timeliness we can set for the individual meetings. This means setting clear rules and guidelines around changes being entered X days before CAB, Y days before the proposed start date of the change, and things like during Z maintenance window. Clearly defining these can be helpful, as can enforcing these rules with your tooling.

With this said, remember the goal of change is to get them entered. While it is inconvenient, and a bit inconsiderate to enter changes last minute, they are at least getting entered. Finding the right balance between ease of use and enablement without being too strict can be tough. If a change is lower priority or criticality, you can always defer it to a later time.

2. Too Many Oopsies

Changes are being entered, which is great, but sometimes when they happen there is impact to our business units, or critical services are being brought down when they shouldn’t be.
A quick solution to this problem is to leverage blackout windows and maintenance windows. A blackout window allows us to mark off when important or critical events are happening that we don’t want our changes to impact. You can enforce these as soft windows, or fully block them. Similar but slightly different are maintenance windows. A maintenance window is an expected, or negotiated time where it is acceptable for there to be an outage of a service. These can be weekends, early mornings, or overnight, but are usually something we declare, and discuss with consumers of our service.

3. Overengineering Risk Scores

With the customization options and tooling we have at our fingertips, we can make awesome processes for assessing and scoring change risks. The issue that arises here is that we can very quickly over-engineer a solution that is too complex and has too many conditions that impact the change process arbitrarily. This can lead to opaque processes, or folks not filling out the questionnaire because it takes too much time.

At its most simple level, you could make the fields required, this would force people to fill them out. But in practice this won’t always lead to quality usage of the tool. So the real solution is to simplify your processes. Ask only what is absolutely necessary for auditing, due diligence, or compliance. Try and simplify questions to what the root intention is.

Do you need 5 quantitatively scored numeric assessments to figure out impact to users, or can it be a simple checkbox of “this change impacts users”. This gets to the root of the problem we have with tooling - just because we can doesn’t always mean we should.

If the goal of a subset of questions is to assess user impact, then you need to figure out if discrete values there matter. If you develop a score system on a 100-point scale, what is the user impact of a 91 vs a 93. Beyond numeric systems, could this be a text field where the practitioner describes the impact?

4. Let Me Make That an Informational

Your users have discovered the informational change and now every change seems to be entered as an informational. The initial purpose of an informational change within my organization was to allow a way to document third-party changes such as “The Learning Management System will be down at 2am on Saturday.” In that case, a SaaS vendor is doing work that we want to document, but which we have zero control over. This is a perfect use of informational change.

But what happens over time is people start entering them for every change that really should follow the normal process.

Defining your change types and when to use them will go a long way in making sure people are using the correct ones. Similarly make sure your tool is set up in a way that helps people easily switch change types or know which one is correct. If a user goes too far down one path and realizes they chose the wrong type, they may just keep using that one rather than starting over, so allowing conversion is key. Reviewing all changes in CAB regardless of type is another way to make sure you are not letting any slip through the cracks.

5. If a Change Falls in the Woods…

Change requests are being entered, and work is happening. We are vibing with the process and things seem to be working…internally. And then we notice that during an approved outage, phone calls, emails, and tickets are still flowing.

The biggest issue here is that we have a change process that is wholly disconnected from our communications process. The best way to fix this is to enable workflows between the two. A quick fix for this is to allow for a task or ticket to be created out of a change that goes to your communications/news team so that they can better report out when things are happening. That way, if the network is going to be down for five minutes, we can have a post to our portal, or a company wide email go out in advance of it. If you have information to share, you can also publish out your change calendar for public consumption. This is a great way to get info out using the same tooling, and to allow folks to see what is going on in real time.

Change is a vital part of service management, and enabling change can help our organizations to be more resilient. But that doesn’t mean that there aren’t frustrations and pain points with the processes we have built. These strategies can help us to rekindle our love of change, and remove barriers and frustrations that make more people want to participate.