Too busy to read?

"We spent a lot of blood, sweat, and tears creating our old change management policy, and everyone still blew it off. What makes you think this will be any different?" I shrug. "I don't know. But we'll keep trying things until we have a system that works, and I'm going to make sure everyone keeps helping us get there. It's not just to satisfy the audit findings. We need some way to plan, communicate, and make our changes safely. I can guarantee you that if we don't change the way we work, I'll be soon out of a job."

We make a pile of nearly fifty cards proposing changes to the Rainbow, Saturn, and Taser applications, and also changes to the network and certain shared databases, which could impact a significant portion, or even all, of the business. "Even looking at those cards makes my heart palpitate," Wes says. "These are some of the dangerous changes we make around here." He's right. I say, "Okay, let's mark all of these as 'fragile.' These are high risk and must be authorized by the cab. Patty, changes like this should be at the top of the pile during our meetings." Patty nods, taking notes saying, "Got it. We're predefining high-risk categories of change that not only must have change requests submitted, but must have authorization before being scheduled and implemented."

Is it a change or not? I can see both sides of the argument. After thirty minutes of arguing, it's still not clear that we know the definition of what a "change" should be. Was rebooting a server a change? Yes, because we don't want anyone rebooting servers willy-nilly, especially if it's running a critical service. How about turning off a server? Yes, for the same reason. How about turning on a server? No, we all thought. That is, until someone came up with the example of turning on a duplicate dhcp server, which screwed up the entire enterprise network for twenty-four hours. A half hour later, we finally write on the whiteboard: "a 'change' is any activity that is physical, logical, or virtual to applications, databases, operating systems, networks, or hardware that could impact services being delivered."