Most Service Desk calls result from failed changes, making IT its own worst enemy and largest customer. This makes IT the #1 preventable cause of IT service outages! The solution is Release Management... |
||||||||||||
Various industry analysts claim that about 80% of Service Desk calls result from change-related failures self-inflicted by IT. By definition a failed change is a failure of IT, and they come at a massive cost. The accepted cost per contact — answering the call and not including resolution, lost profit or productivity — is about $30 per incident. Since an average user calls the Service Desk 1.25 times per month, a modest IT organization with just 4000 users pays an astounding $1,440,000 annually just to answer the phone for largely preventable change related failures. Clearly, any IT organization looking to improve customer satisfaction and reduce costs should consider healing themselves first. Release Management (RM) is an often misunderstood IT Infrastructure Library® (ITIL®) process. Simply put, the objective of RM is the protection of the live environment and its services by using formal procedures and checks. Following I explain a how Release Management should work and how to create an effective Release Policy that can dramatically improve service quality and reduce costs. Change, Release, and the CABIt is important to understand the relationship between changes and releases in order to fully understand RM. A change is "The addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation." A release is "A collection of new and/or changed Configuration Items (CIs) which are tested and introduced into the live environment together." Change Management brings together interested parties via the Change Advisory Board (CAB) to make sure a change is well thought out. Change Management and the CAB define and agree what changes to make to infrastructure components. The CAB is also responsible for advising and recommending release content and scheduling. While many consider RM a subset of Change Management, it is a vitally important process in its own right. RM manages the introduction of the changed CIs into the live or production environment. Essentially, RM oversees the work required to implement the change.
As a member of the CAB, under Change Management control, RM is responsible for documenting the specific details of how to implement a change and making sure the change follows a stringent review process. Not all changes need to use formal RM, however you should always use RM for:
As a process, RM is responsible for implementing the release according to CAB directives (which, as a member of the CAB, RM helps define.) Without this tight connection between the Change and Release Management processes, the success of the release and its associated change becomes haphazard. Release Management In ActionPractitioners often get confused and try to create a functional organization for the RM process. RM does not define an organization, but rather defines what various organizations must do together as a team in order to modify the physical infrastructure. RM describes much more of a workflow than most ITIL processes.
As a process, the activities of RM execute within existing functional organizations, and normally span multiple organizational boundaries and technology silos. This means RM has both distributed and centralized process responsibilities and activities making it one of the most difficult processes to comprehend and implement for new practitioners.
Many problems with Change Management are really problems of RM, as described in the introduction. The “vicious” cycle here goes something like this:
The only way to break this cycle of failed changes is to make sure all parties follow the instructions of the CAB. This makes the real purpose of RM to prepare a release based on a Request for Change, and to make sure implementation of the release occurs as defined and agreed by the Change Management process.
Consider RM a supervisor of required work, and the secret to success with RM is to realize that it mostly defines oversight and describes a series of check-offs designed to validate completion of CAB and Change Management dictates.
It is important to understand the difference between a building a release and building software or hardware. A release is the managed introduction of one or more changes into production as a unit, not the development of a piece of software or hardware. Part of the confusion with RM is that new practitioners confuse these concepts. This results in so-called "turf-battles" between RM and functional groups.
For example, part of RM includes responsibility for release “design, build and configuration.” Of course, designing and building software is often a task assigned to a software or applications development group. Release does not “take over” development, but rather development must follow the Release Policy as they build the software. Then, a Release Manager (person following the Release Policy) checks to ensure the built application aligns with the Request for Change and release instructions from the CAB.
RM must leverage existing tools and Quality Assurance best practices or methodologies already in place. Many software development groups use Capability Maturity Model (CMM) to manage software quality, since RM and CMM share several objectives there is no need to duplicate them. Instead, RM just needs to validate and “check off” that release criteria as described in the Release Policy, and instructions from the CAB, are complete -- in this case by examining CMM documentation in the development organization.
Release Management validates each step required, and submits confirmation to Change Management for review and approval. After Change Management approval, the release deploys. As the release deploys, RM updates Configuration Management with modified CI details. Getting Release Management of the GroundGetting started with RM means preparing the process – establishing an owner, manager, team, etc., and one of their first tasks is to define the Release Policy. The Release Policy defines how RM conducts its business within and between other processes and functional organizations. The Release Policy documents roles and responsibilities, and defines authorities. It describes how RM is to operate, and as such, it becomes an integral part of the Change Management process as well.
A Release policy should include:
Definition
of the level of change to the
IT
infrastructure under RM control
Release
naming and numbering conventions
Release
acceptance responsibilities
Definition
of Major, Minor, and Emergency Releases
Release
frequency
Business
and Customer concerns
Release
contents
Back-out
plan policy
Release
Management process description
DSL and DHS SummaryI hope that you now understand the true role of RM, and have an idea of how it should operate. There are many tasks to RM, developing a Release Policy is just one of them. However, developing a Release Policy forces you to address virtually all of the other activities to some degree.
Key to your success is to realize that RM is a distributed process that relies upon your existing quality and production systems as much as possible. The central RM process tasks are supervisory – overseeing and checking off distributed RM tasks completed by the functional departments.
The steps of defining a RM process, creating a Release Policy, and making sure all involved do as they are supposed to do will have a dramatic and positive effect on operations. Reducing failed changes through controlling releases will improve service quality, and deliver real cost savings as well.
-- Where to go from here:
|
||||||||||||
|
Entire Contents © 2006 itSM Solutions LLC. All Rights Reserved. |
