What’s a Change Manager to think?

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.”

Comments

[jvbon]

Charles - this has been a 'problem' since the early ITIL days. But it can be solved easily. It's all a matter of definition and context.
Both Gary and Bob are right, but their context /scope/view differs. ITIL is defined for the information technology domain, so that is Bob's perspective. Customer requirements are out of scope for that context, since they should be addressed to the 'information management' domain - which is entirely separate from the information technology domain. A first attempt to describe the information technology domain is done in BiSL.

[alphasong]

Rather than requiring people to consciously scope a frame of reference before they apply a framework, I would rather that we do all we can to more carefully scope the terms we use in these frameworks, so that words like "change," "service," and "configuration item" aren't perpetually causing confusion. This way, the scope of the framework is intrinsic within it; it is less easy to mis-apply it.

For example, if ITIL v2 had simply distinguished between Change Management and Project Portfolio Management (aka Demand Management), there would have been less confusion in this regard, and no need for people to worry about scoping it.

The simplest, most abstract reference model in the world is an entity called "Thing" with a many to many relationship with itself. Anyone can use this reference model, but they need to be rather careful in "scoping it to a particular domain"... :-)

The interaction is not a theoretical scenario. I don't know who is or was "to blame"; neither the ITIL consultant, nor those who hired them, were at all precise about the frame of reference, quite the opposite. ITIL advocates in some cases have presented it more as a totalizing discourse, one that seeks to subsume a broader and broader scope in its purview (the opposite of careful domain scoping), and I have had concerns about this.

-Charlie