cOMMON prOBleM AreAS

® the lack of coordination between Change and Configuration management leads to inaccurate analysis of the impact of Change.

® generally, the responsibilities of the individuals involved in implementing the Change are not clear. thus, the process might not be implemented correctly.

® wide Scope of Changes. to resolve this bottleneck, routine Changes, which are clearly defined and covered by procedures, should be identified as Standard Changes in the Change management process. development environment Changes should not be included in the Change management process.

® at times, to avoid an adverse impact on the business, certain Urgent changes might be implemented by Change management, resulting in errors.

® the lengthy activities and excessive paperwork make Change management a bureaucratic process.

2.5.6 Key perFOrMANce INDIcATOrS

to measure the effectiveness of the Change management process, you need to compare the actual output with the following key performance indicators:

® number of implemented Changes with respect to a Ci, during a specific period

® number of unsuccessful Changes

® number of successfully executed Changes

® number of Changes backed out

the following key performance indicators help you in determining the impact of a change:

® number of incidents resolved by the implementation of a Change

® workload reduction after the Change is successfully implemented

® average time needed to implement a Change

® average time required for a reduction in the related incidents after the implementation of a Change

in addition to reviewing the key performance indicators for Changes, you need to consider the following indicators for rFCs:

® number of rFCs and their impact on Ci

® number of rejected rFCs

66 itSm handBooK

2.5.7 crITIcAl SucceSS FAcTOrS

the following critical success factors improve the functioning of the Change management process:

® management support to ensure adherence to the Change management process

® Coordination with the it staff and suppliers through proper communication

® evaluation of a Change and its repercussions on it service stability

® Coordination with Configuration management to get updated Ci-related information Chapter 2.6

releASe

MANAgeMeNT

Á

^

2.6 reLeaSe management 6 itSm handBooK 2.6 reLeaSe management 6 itSm handBooK

^

the following terms and concepts are integral to the release management

process. OBJecTIve

release management takes a holistic view of a Change in an it service (hardware and software elements) and ensures that all aspects of a release, both technical and non-technical, are considered together. the focus of release management is the protection of the live environment and its services by using formal procedures and checks.

BeNeFITS

implementing the release management process increases the effectiveness and efficiency of the it services. Some benefits of release management are:

® risk optimization

® release implementation in a manageable period of time with minimum disruption

® Few individual implementations

® Less chance of using illegal copies

® increased user involvement for testing a release

® Standardization of hardware and software versions 2.6.1 cOMMONly uSeD TerMS

the term release is used to describe a collection of approved Changes in an it service authorized by Change management. a release is defined by the rFCs that it implements. depending on the size, the release can be divided into:

® emergency release

® minor Software release or hardware Upgrade

® major release

a Release Unit describes the portion of the it infrastructure that should be released together. depending on the type or item of software and hardware, the size of the unit can vary.

the status of a release alters according to its current environment. release

Identification refers to determining the status of a release in different environments. the environments in which a release can be categorized are:

® development environment

® test environment

® Live environment

® archive

depending on the number of Changes that should be included in one release, a release can be of the following type:

® delta release - only those Cis within the release unit that have actually changed or are new since the last Full or delta release

® Full release - all components of the release unit that are built, tested, distributed, and implemented together

® package release - a bundle of Full and/or delta releases of related applications and infrastructure that are released at longer time intervals. it provides longer periods of stability for users.

Delta Release Full Release

Module 1 Package Release Full Release Component 1 Component 2 Component 3 Component 4 Component 5 Module 1 Module 2 Module 3 Module 4 Module 5 reLeaSe typeS

70 itSm handBooK

_^

itSm handBooK 71

during the development phase, the software items should be physically located in the Definitive Software Library (DSL). the dSL includes all the original versions of software items used during production and development. the dSL can also include several versions of software.

a standardized hardware configuration can be used to replace or repair similar configuration in the it infrastructure. the standardized hardware configuration is available in the Definitive Hardware Store (DHS).

2.6.2 prOceSS process inputs

® approved Changes from Change management

process outputs

® new released software in the dSL

® new hardware in the dhS

release policy

the release policy for an organization should include such items as:

® release units

® Frequency of releases

® dSL management standards

® Versioning/naming standards

® process roles and responsibilities

preparing the release plan

Consider the following issues for creating a release plan:

® type of release

® hardware and software required for the release

® Cost of the release, for example, obtaining quotes from the suppliers for new hardware and software

® roles and responsibilities for implementing the release

Development Environment

Controlled Test Environment

Live Environment

Release Policy Release Planning Design and develop, or order and purchase the software Build and configure the Release Fit-for- _Purpose testing Release acceptance Roll-out planning Communication Preparations and

Training

Distribution

and Installation

Configuration Management Database (CMDB) and Definitive Software Library (DSL)

Release Management

2.6 reLeaSe management 72 itSm handBooK 2.6 reLeaSe management 73 itSm handBooK

^

designing, Building, and Configuring the release

after preparing the release plan, the release team sets up standard procedures for designing, building, and configuring releases. these procedures include:

® installation instructions

® operating instructions to ensure that the same set of components are combined every time

® Setting up a test laboratory to test all software and hardware before installation on site

® Configuring and recording of hardware and software components so that they are reproducible

® Standardizing hardware and software requirements

testing and acceptance

all release Units should be thoroughly tested for errors before being introduced in the Live environment. the release units should be tested by the:

® representative of the users

® it management personnel

after successful testing, the users and developers should formally accept and sign-off the release. the formal acceptance helps in certifying that the release Unit has been adequately tested and is ready for the live environment.

preparing the rollout plan

a rollout plan includes:

® a schedule and a list of tasks for the release

® List of Cis to be installed and phased out

® activity plan for each implementation site

® release memos and other communication to relevant people

® plans for purchasing hardware and software

® Schedules of meetings with management departments, Change management teams, and user representatives

Communication

all teams communicating with the customers, such as Service desk, Service Level manager, as well as operational personnel, and representatives of users should be aware of the release plans. release plans help them estimate the impact of the release on their routine activities. all relevant it staff and Users should be trained in the functionality of the new release.

distribution of the release

it is advisable to use automated tools for software distribution and installation. the actual conditions in which the software is to be implemented should be compared to the planned conditions before installing the new software, for example, Capacity requirements. after installation, information in the CmdB should also be updated.

2.6.3 rOleS AND reSpONSIBIlITIeS

the Release Manager creates the release plan and coordinates the

implementation process with other teams. the responsibilities of the release manager include:

® defining the release policy for the organization

® preparing the release plan

® authorizing the release build and configuration

® Communicating with other groups, such as Users, Service Level manager, Service desk, and Change manager

® Coordinating the final implementation of the release

the Test Manager ensures that the release is tested and signed off by proper authorities. the responsibilities of a test manager include:

® Successful testing of the release before signing off

® ensuring that the test environment is the same as the live environment

® preparing the rollout plan along with the release manager

Key Skills

typically, a release manager should have:

® a sound technical background

® good understanding of the it infrastructure and the services it provides

® good working knowledge of support tools and utilities

® good grasp of the principles and practices of it infrastructure management processes, especially the Change management and Configuration

management processes

® an awareness of the organization’s business strategy and its priorities

74 itSm handBooK

_^

itSm handBooK 75

2.6.4 relATIONSHIp WITH OTHer prOceSSeS

In document Foreword. Copyright Statement (Page 33-38)