Release Management Left Behind

Posted March 12th, 2008 by Joe Pendry

In a recent post from the Pink Elephant conference, I mentioned something we have noticed about change, configuration and release management:

Configuration managers and change managers get their own breakout sessions at ITIL/ITSM conferences, but there doesn’t seem to be a large amount of material or sessions tailored specifically to release managers. Our guess is that organizations haven’t matured to the point where the release manager position is developed and distinct from change management, but to truly give testing its due, we need to give the release manager function more attention and guidance.

This finding has been noticed by other folks in the IT management community as well. Last May, for example, Mike Drapeau and Sudesh Oudi wrote a column for ITSMWatch.com that talked a bit about why release management isn’t as popular among IT Managers:

The current ITIL implementation landscape is populated with Incident, Change and Configuration process improvement projects. However, mention Release Management (RM) to an IT Manager in the Infrastructure group shop and you will likely receive a few blank stares.

In fact, many IT careers have been preserved by defending the idea that RM cannot be mastered by a single IT manager and, in any case, the requirements of software development and infrastructure are so distinct that they merit different treatment. This “separatism” is the single greatest factor hampering RM implementations and it is a profoundly mistaken notion.

Having thought about the subject for a few more weeks, I think I understand one reason why change and configuration management seems to have a little higher profile than release management. It has to do with impact on downtime and effectiveness of IT management. Even our own research suggests that disciplined, regularly scheduled changes can have strong benefits for organizations, including:

20 % fewer production problems
20 % fewer IT staff required to for change management activities
23 % fewer emergency changes
5 % greater confidence in changes
70 % more likely to view the change management process as “smooth”

But does this mean that release management is less important than change management? Not at all. It just seems that IT Managers are reluctant to address release management until they have their “house in order” with regard to configuration and change. Or, as often happens, they try to extend the change management activities into release management by making a small tweak or adjustment here or there. Drapeau and Oudi discussed why this is a problem in their article:

Many, if not most, ITIL implementations start with Change Management (so as to “stop the bleeding” in IT Operations). Over time, the process design and policies begin to take on more than just Change Control disciplines. Organizations are tempted to avoid launching “another ITIL process” and just amend the existing Change Management guidance to include pre-Production testing requirements prior to authorizing a Change.

The results of this approach are predictably poor. Changes fail in Production, testing blurs with deployment, no risk assessment techniques are used, and nothing exists to arbitrate access to pre-Production resources. Fingers begin to point and accountability is blurred because the Change Manager is trying to accommodate the dictates of a Release within the confines of a Change Management system.

Organizations with undifferentiated Change Management processes similar to this will see improvements shortly after extracting the Release-related activities.

Our prediction is that, as downtime continues to hamper organizations – sometimes with very public results – the focus on release management will grow. IT managers will begin to adopt a separate release management function to improve performance and, of course, better manage change.