How to Implement Change Management

Many times, changes can be extremely helpful to an organization (implementing a fix or patch, releasing a new application, etc.). Being able to make changes – and lots of them – quickly allows us to be an agile and responsible organization. However, sometimes when we change things, we break things. And those things can be pretty important. This is why it’s so important to have a solid Change Management process in place.

If you don’t currently have a documented process for managing change in your organization, rolling one out can bring the people who have gotten used to independently making changes to their own stuff out of the shadows with pitchforks and torches. Here are some things to keep in mind if you’re rolling out a new Change Management process and want to avoid a bit of the backlash.

Communicate Why Change Management is Important

As with any major initiative or improvement, you have to lead with answering the inevitable WIIFM question (What’s In It For Me). If you don’t, people tend to feel like they’re being made to go through the motions simply because you told them to. Management has a habit of diving straight into the how when implementing new processes (“Here’s how to fill out a Request for Change (RFC)…”). It makes sense from a let’s-get-this-show-on-the-road perspective, but doesn’t do any good in the morale/buy-in department. Answering the why first (“Here’s why we’re introducing RFCs…”) – then getting to the how – will do wonders for you when you’re introducing a new process. People aren’t motivated by context-less orders bestowed upon them from on high – they’re much more engaged, in large part, when they’re informed and made part of the conversation.

So, what are the whys?

Broadly, one of the main reasons for implementing a Change Management process is that it allows you to make more changes faster. If you’re starting out with Change Management, or currently in an environment with an ineffective Change Management process, that statement may be hard for you to believe. Stay with me. When done well, Change Management ensures we’ve thought through the change being made, including the implementation and remediation steps, informed all of the appropriate stakeholders, and communicated to the affected users.

The key is to convey this to your organization in a meaningful way and ensure you are providing the WIIFM in a manner that applies to your specific organization. Don’t just copy bullet points from the ITIL publication and throw them up on a PowerPoint. Provide compelling examples from your organization of how change management will help the organization the individuals. Below are a few scenarios that may help bring it home. Why is a Change Management process important? To avoid anyone on your team saying anything like this:

• “When I went home last night everything was running fine, and this morning everything is on fire.”
• “No one, including IT, knew we were going live today.”
• “Bob called in sick today, does anyone else know how to…?”
• “Hey, the application is running slow, did anyone change anything?”

None of that is okay. It hurts me even to type it. Okay, moving on.

What if the Why is “Because we Have to”?

Some of you maybe embarking on a Change Management implementation because you’re required to do so by regulatory or statutory compliance. That’s a perfectly valid reason, as your business will and has already confirmed for you.

If you are in this situation, go ahead and list it as one of your reasons why. It cannot stand alone. If you go down the route of compliance being your only, or even your primary driver, you’ll create a culture of box-checking. The difference is, “We do Change Management because we have to pass the audit.” vs. “We do Change Management to improve our service delivery and overall work experience.” Those are two vastly different work cultures; One is soul crushing, the other is positive and rewarding.

Clearly Define the Scope of the New (or Improved) Process

Now that everyone is fully on board and has a thorough understanding of the why behind the new Change Management process, it’s time to define the scope. (Do you like how I made it sound so easy? In one flippant sentence I stated the single biggest hurdle you’ll encounter during your implementation: getting buy-in. Just wanted to make sure you know I know I did that.)

Anyway, by scope I mean the boundary or extent to which a process applies (per the ITIL publications). The scope of Change Management, for example, could include all live IT services and related Configuration Items. Essentially, it defines when people need to interact with the process. For example: Are RFCs required strictly for production systems? All systems? When a configuration change is made?

Scope can be a deceptively complex thing to define. It needs to be articulated clearly enough that your team members understand whether the particular activity they’re responsible for is governed by the process. As a general guideline, I recommend covering everything under Change Management, with the caveat that there are a variety of change types that will need to be handled differently (to keep the process from getting clogged up or becoming too bureaucratic). How you define your scope often impacts how you’ll roll out the process.

Don’t Treat all Changes the Same

Not all changes are created equal. Large, complex, costly, or risky changes should follow a separate, more robust process than those simpler changes that pose little threat to the environment. Make sure the overall process scales accordingly. For the simple stuff, come up with pre-defined steps, called Standard Changes.

Look at each step of the process – the RFC form, the number of required approvals, the documentation necessary for each change, etc. – and make sure it’s reasonable for the type of change requested. If the process is too bureaucratic, particularly for the simple changes, you may not be leveraging Standard changes properly.

The Phased Change Management Implementation: Pros and Cons

Many organizations adopt a phased implementation approach, starting with the most critical systems. There are pros and cons to this:

To help mitigate some of the cons, define the overall goal of the implementation from the beginning. So, if you’re starting with critical systems but plan to eventually cover everything, tell everyone from the get-go. The trouble some organizations find themselves in as they roll out and expand the scope of Change Management is that their teams feel like the process itself is constantly changing. We want to establish a change process not create a changing process. Avoid this by creating and providing a roadmap from the very beginning. That way, your team will know what to expect and won’t feel like they’re in a never-ending change spiral.

Hold People Accountable

While there are many processes you can implement using a grassroots approach, Change Management isn’t one of them. The real power of Change Management is the cohesiveness it creates within the organization as a whole. Imagine your server team is on board with the process, but your network team is still doing its own thing and making changes when and how they want. That scenario makes it impossible to coordinate changes, track down potential issues (which change caused what), communicate outages to your users, etc.

Users care more about end-to-end service availability than the individual teams responsible for supporting it. If the website goes down on Tuesday for server maintenance, then down again on Wednesday for network changes, your users will see that as two outages, that you’ve impacted the business twice. At that point it doesn’t matter which team wasn’t following the Change Management process – all of IT takes the reputational hit.

NOTE: Part of Change Management in this instance would involve coordinating those two changes. Do the server change first, verify it was implemented properly and that everything works, then implement the network change. That’s one disruption of service vs. two.

To avoid multiple outage (and many other unfortunate) scenarios like the one above, each team must be held accountable for its piece of the Change Management process. A big part of that is training – namely, ensuring everyone who will be submitting changes fully understands the process and the importance of following it. There cannot be any exceptions to this – it really must be everyone (not, say, everyone but the Vice President). This is one place where a zero tolerance policy is merited.

Now go forth and implement! Your team will love you for it.

Looking to dig a little deeper?
Watch Andy and Brian Flora chat about what makes a successful CAB meeting.