Change Management part 2

In my last blog posting about change management I talked about how to start selling change management in a hostile environment. I mentioned that you should keep some talking points handy and keep track of service affecting outages that could have been prevented if you had a change management process in place. However, even with all of that sometimes you're going to have to wait for a crisis in order to push change management into reality. As Rahm Emanuel says "never let a good crisis go to waste."

I'm not going to go into detail about what happened in my organization, but there was an unplanned change that resulted in thousands of users not having access to services. The help desk was pissed and that was working its way up the chain of command. The people that were resistant to change management were already on defense over the unplanned change and they were in a position where they couldn't put up a big fight against change management since that was the cost of forgiveness. The help desk was demanding change management, and I was the guy who had been banging the change management drum for two years. It was time to strike.

The question at this point is how hard should I strike? If I came out with a complete change management policy complete with change lifecycle, maintenance windows, change management database, and a process for getting permission to make changes, then the resistors would circle the wagons and fight very hard to tear it apart. I also needed to act quickly. There was no time to sit back and think about how this should go together. I needed to take advantage of this momentum. So I decide to strike very softly. The groups that were resistant to change management would grudgingly go along with this and not put up too much of a fight if it didn't seem like it was too much of a burden to them.

So we started to have our first change management meetings, even though we hadn't even defined what the different levels of change were (minor, major, routine, etc) or even what changes needed to be discussed at the meeting. The Vice President just told everyone that each group within IT is expected to send someone to these change management meetings. I did my best to make sure that the meeting was not a forum to attack anyone, and I wanted to keep it very informal. I also had to stress over and over that people were not coming to change management meetings seeking permission to make their changes. One thing I said in these meetings and tried to repeat a few times is "we're not going to get this right on the first try. There will be mistakes, and we will learn from them." In these early meetings we just went around the table and talked about what we were planning to do next week.

Here is where the magic really started to happen in these first few meetings. The system administrators were not coming to the meetings to get permission to make their changes, but when they presented a change that interfered with another project, they ended up discussing how to resolve the conflict. Very few people are going to say to their peer "I don't care if you're doing a network backup at 10:00pm, I'm taking the switches down and that's that!"

The other magical thing that happened was that decisions started being made at these meetings regarding future changes. You need to write those down and keep them somewhere because those are the seeds that will become your change management policy and procedure down the road. For example, we decided as a group that routine electrical work that was being done in our datacenter did not need to be reported to the change management group. I disagreed with that decision, but I can't win every time. Regardless, that will someday be enshrined in our change management procedure. Maybe put together a skeleton policy and procedure, but don't show it to anyone yet. Let it grow on its own for a while.

Looking back I think the worst thing I could have done was to announce that we were going to develop a change management policy. If I had done that it would have given people the opportunity to delay change management until the policy and procedure were absolutely without flaw. They would have killed change management by demanding perfection. Instead we're easing into things gradually and I think we're avoiding some of resistance because everyone has more of a voice than they expected in the process. We've also scored a few wins where some change was going to cause a problem for another and we were able to resolve that ahead of time. I'm keeping track of these wins just as I kept track of the failures before we had change management. You never know when someone is going to pick up the fight again and you'll need ammunition.