“Wait… how am supposed to know if this requires an RFC?”

When I engage with a new or existing client to explain a complete Change Management model I am met with a blank look and the words, “Yeah, we’re not ready for that.” Or “that wont work here” followed by an endless stream of examples crafted to demonstrate how things are “different here.” Then I spend a few minutes biting my tongue, resisting temptation to remind clients that they are not as different or as special as they think.

Here’s the thing: The ITIL books talk about organizations that exist with… nothing.   ITIL, version 1 through to version 3, have painted their picture of ITSM on a blank canvas or a “green field”. In that fictional world, we are told to:

1) Identify our inventory and relate it to services (Configuration Management),
2) Build a governance model to protect those services (Change Management), and
3) Establish gates to control the state of those services (Release Management).

The reality, as demonstrated by typical private and public sector clients, is that some kind of Release Process exists, and it’s erroneously called Change Management. They have a “Release Team” that they call “The CAB”.  There is often little evidence of any effort to establish a dialogue with representation from the business side of their house in support of their theoretical “IT Change Management.”

Now add to this picture and endless stream of vendors coming to their door to sell them a CMDB. They behave as if they have one in their brief case… and it comes in two colors. This is the stuff of great frustration and, more importantly, great distraction.  I propose to my clients that the CMDB can live on a spreadsheet while they get sorted on Change, Release and possibly Event management.  If (and that’s a big “if”) Transition Management processes begin delivering a measurable return on investment then perhaps it’s time to think about paying for a CMDB. Step one would be to tie the spreadsheet of data on configuration items to a module supporting their Operational Processes (Service Desk: incident management).

Don’t get me wrong… a CMDB is a wonderful thing, but it’s expensive, complicated and absolutely without value until there is an effective set of processes in place supporting Transition and Operations Management. That’s a much larger subject – worthy of it’s own blog post – but for now, lets at least agree that the CMDB doesn’t come first (unless you live in Imagination Land with a completely “green field” landscape in IT services).

Getting back to Change Management… and the whole “You’re calling release management – Change Management”. This has got to stop. LOL.

Look… the really important issue is this: Organizations are developing and implementing these processes without ever spending any time or effort on understanding what services they are actually providing. If you haven’t documented a service, you can’t associate IT assets to it (the service) and you don’t have a value proposition to justify exactly what is to be governed by an IT Change Management paradigm.

All you’re really doing with your undocumented services and a so-called “CAB” meeting is considering your preparedness to introduce a change to the live environment… aka: Release Management.

Typical clients turn to ITSM consulting for support and guidance when a pain-point has broken through the façade of ITSM practices. It would be nice to get pulled into the game before choices are made, but such is life … and the lack of a green field.

Reaching for IT Change Management success is absolutely not simply calling a meeting a “CAB” and making everybody fill out paperwork when they want to make adjustments to the production environment. This will lead to endless conversations about whether or not changing someone’s email profile constitutes a “change”.

No matter where you are on the “Change Continuum”, no matter what “amount” of Change Management your company has an appetite for, it is paramount that a “full-on” picture of Transition Management be presented. It should show the alignment of the process to various pain points in your organization, and – most importantly – an alignment to the benefits or process rewards. Now you can use that model to identify your organization’s “process appetite” and decide just what you’re going to engage in…