Bob is the Enterprise Change Manager for a large Midwestern insurance firm. His team’s role consisted primarily of running the Change Management process which controlled the deployment of new functionality into the quality assurance, pre-production, and production environments on the mainframe and the enterprise servers. Their process was well-understood in the enterprise; it typically had a two-week lead time, with various exceptions available for low-risk and urgent changes. The success of the development teams’ changes was reviewed every week, and figures relating outages to unsuccessful changes were compiled. All in all, it was a reasonably well run enterprise process.
Then ITIL came, and his staff started going to training. They were returning with some strange ideas, so Bob called up Gary, the lead ITIL consultant doing the training.
Gary said, “You’ve got to understand that ITIL sees a Request for Change very broadly. It can even be a business-driven request for altering the functionality of some system.”
Bob said, “So let me get this straight. We’ve had a Change process in place for five years – even benchmarked it against a couple other Fortune 100 corporations in the region – and now you tell me its scope is incorrect?”
Gary said, “What you’ve been doing is Change Control. You need to move into true Change Management.”
Bob said, “We have a project initiation process. Are you saying that I am now somehow involved in that?”
Gary said, “Well, maybe not you – but all new requests for change to IT should be reviewed by the Change Advisory Board.”
Bob said, “We have one of those. Its mission is very tightly defined, just focusing on very operational concerns about changing production or pre-production environments, typically on a 2-week lead time.”
Gary said, “That’s not good enough; changes need to be assessed much further in advance.”
Bob said, “That’s what we use the Portfolio and Demand Management capability for. That’s where the longer-horizon changes are discussed, by the Project Advisory Board. The Enterprise Architecture group also gets involved. Sounds like you are saying the Change Advisory Board should be doing the same thing. But the folks we have on that group are not currently suited for the longer-horizon assessments; it’s just not their job. Their main focus is availability.”
Gary said, “Maybe you should have a Change Advisory Board whose membership composition can vary?”
Bob said, “What value would that add? It’s already confusing enough for people as to which committees they are on. Everybody would be on the CAB at one time or another. Why not leave things as they are?”
Gary: “Because it’s not what ITIL says…?”
Bob: “I’m sorry, but I have a business to run. You’ll have to do better than that.”