Research

Publication Date:

ID Number:

IT Change Management Policy Documentation

Guidelines

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior
written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable.
Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no
liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader
assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed
herein are subject to change without notice.

TABLE OF CONTENTS
Analysis...........................................................................................................................................4
1.0Governance Introduction...............................................................................................4
1.1Mission.............................................................................................................4
1.2Strategy and Objectives...................................................................................4
1.3Scope...............................................................................................................5
2.0Change Management Definitions, Roles, Classifications and Procedures....................5
2.1Change Definition.............................................................................................5
2.2Change Policy Document Management...........................................................5
2.3Change Management Guiding Principles.........................................................5
2.3.1Change Agility Principle....................................................................6
2.3.2Common Change Management Principle.........................................6
2.4Define Individual Roles and Responsibilities....................................................7
2.4.1Change Process Owner...................................................................7
2.4.2Change Process Manager................................................................7
2.4.3Change Owner/Requestor................................................................7
2.4.4Change Implementer........................................................................7
2.4.5Change Coordinator/Administrator...................................................8
2.4.6CAB Member....................................................................................8
2.5Define CAB and E-CAB Roles and Responsibilities.........................................8
2.5.1CAB Guiding Principles....................................................................8
2.6Define RFCs, Types, Categories and Classifications.......................................8
2.6.1Change Types..................................................................................9
2.6.2Priority..............................................................................................9
2.6.3Risk................................................................................................10
2.6.4Impact.............................................................................................10
2.6.5Additional Categorization and Classification...................................11
2.6.6Documenting RFCs........................................................................12
2.6.7RFC Documentation Principles......................................................13
2.7Process Workflows.........................................................................................13
3.0Integrative Process Partners.......................................................................................18
3.1Business Continuity Management and Disaster Recovery.............................19
3.2Configuration Management............................................................................20
3.3Incident and Problem Management................................................................20
3.4Project Management......................................................................................20
3.5Release Management....................................................................................20
3.6Examples of Key Policy Integration................................................................20
4.0Schedule/Calendar......................................................................................................20
4.1Scheduling Key Policy Attributes....................................................................21
4.2Change Measurement....................................................................................21
4.3Critical Success Factors.................................................................................21
4.4Quality and Efficiency Metrics........................................................................21
4.5Compliance and Control.................................................................................21
5.0Communications, Coordination and Education Methods.............................................22
5.1Key Meetings..................................................................................................22
5.2Cross-Departmental Collaboration and Coordination.....................................22
5.3Training Programs..........................................................................................22

LIST OF FIGURES
Figure 1. Revision History...............................................................................................................5
Publication Date: /ID Number:
9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 2 of 22

Figure 2. Change Management Process.......................................................................................14

Figure 3. RFC Integrative Process Workflow................................................................................15
Figure 4. Change Approval Workflow...........................................................................................16
Figure 5. Change Request Swimlane...........................................................................................17
Figure 6. Linking Key Processes to IT Change Management.......................................................19

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 3 of 22

Analysis

1.0

Governance Introduction

1.1 Mission
The documentation of IT change management governance should provide succinct guidance for
everyone to follow when a change is introduced that could affect client service. The change
management process is intended to manage any change that might prevent a system from
behaving as the client expects or from delivering the services stated in the service-level
agreement. Typically, the IT change management process will apply to all situations or proposed
alterations to an IT service. Any deviations require a change record that can be tracked through
the process until a successful change is installed. Because any change may have complications,
each change should be addressed in the same manner.

1.2 Strategy and Objectives

The fundamental strategy for IT change management process governance is to ensure that all
changes are implemented without any negative impact on customer service. Sample strategies
and objective statements include:
Identify and apply best practices in defining common processes for change throughout
an organization.
Develop common change management processes within an organization, including
roles and responsibilities by functional group and the governance group for managing
strategic direction.
Allow change while maintaining or improving system availability.
Determine whether the amount of lead time affects the success or failure of
nondisruptive changes.
When lead time is important, identify sensitive types and volumes of changes to reduce
disruptions.
Reduce the number of changes requiring "backout" due to inadequate preparation.
Provide complete change documentation to shorten problem determination risk time.
Determine a better method of identifying and categorizing changes into levels of risk.
Display the number of and types of changes planned in the short and long term.
Increase the accuracy of predications regarding the impact of change.
Ensure that every record has technical and management accountability to provide a
compliance audit trail.
Establish a process to ensure that records are consistently reviewed for technical merit
and business readiness, while allowing for flexibility based on business needs.
Avoid conflicts by managed scheduling.
Audit change activity and understand the reasons for failing to comply with processes.

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 4 of 22

1.3 Scope
The IT change management process encompasses the companywide computing environment.
This includes any alteration to any IT asset or configuration item (CI) in the production
environment, such as:

A database administrator reorganizing a table

A server technician rebooting a server

An application programmer updating code to fix a bug

A project manager scoping server hardware replacements for mission-critical

applications

A security manager implementing a new policy for user administration

IT change management includes the tasks necessary for planning, testing and implementing
alterations to minimize effects (integrating with configuration and release management
processes).

2.0

Change Management Definitions, Roles, Classifications

and Procedures

2.1 Change Definition

Change definition governs the development of all the change policies and the execution of
changes to any aspect of the IT and communications environment. It enables controlled changes
while preserving the integrity and service quality of the production environment.

2.2 Change Policy Document Management

This section specifies the ownership and document tracking information. It is the official guide and
reference for an organization's IT change management process policy and is the definitive source
for all IT change activity or revisions to the policy document (see Figure 1).
Figure 1. Revision History
Revision History
Version

Status

Date

Author/
Reviser

Changes/
Justifications

1.00

1.01
Source: Gartner (February 2008)

2.3 Change Management Guiding Principles

The change management process policy statement provides a set of guidelines for all aspects of
the IT organization. This policy is integral to a disciplined methodology, and each IT department
must adopt it from design to implementation.
Publication Date: /ID Number:
9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 5 of 22

The use of these guiding principles can seem simplistic if not properly detailed. To help focus the
organization on what will be critical for change management policy, Gartner recommends that
guiding principles be articulated at several levels:

Guiding Principle: What is the key point?

Rationale: Why is it important to draw attention to this?

Implications: How does this principle affect behavior through the process?

Policies: What rules of engagement need to be established to ensure compliance?

The next section provides examples of some guiding principles.

2.3.1

Change Agility Principle

Change management processes and procedures must be flexible and agile enough to
accommodate emergencies.

2.3.2

Rationale:

To support problem management, emergency changes must be provided for within

the change process.

To expedite change for emergency situations, the change must follow documented
processes.

Implications:

Emergency changes follow an expedited process flow.

Emergency changes must be tracked and trended.

Emergency changes must be a low percentage of overall change.

Policies:

All changes, including emergency changes, will be qualified, authorized and

reviewed.

Emergency changes will be generated from high-priority problem tickets or have

adequate business justification and authorization.

Common Change Management Principle

All changes implemented in the production environment will follow the change management
process.

Rationale:

To ensure that all staff and changes are compliant.

To ensure complete adherence by all staff to change processes and activities, all
changes will be tracked, trended, monitored and analyzed for compliance, success
and efficiency.

Implications:

Change management must be a global policy that is adhered to by all groups and
resources.

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 6 of 22

Policies:

All teams will be responsible for adhering to change management processes.

All changes will be handled through the change management processes.

2.4 Define Individual Roles and Responsibilities

Identifying who participates, at what points in the process and their level of participation is often
referred to as RACI modeling Responsible = participates, Accountable = owns the function,
Consulted = advisory role, Informed = notified of work.
In addition to helping organizations communicate participation, RACI models help identify
gaps/overlaps in participation that often wreak havoc with organizational performance. Over time,
the many interpretations of the IT change management process evolving to new functional roles
are who "owns" specific processes/tasks.
RACI and other personnel models can help define the new roles to support IT change
management. In the end, disciplined people are needed for the successful implementation and
execution of IT change management.
An example of basic roles are included in the next section.

2.4.1

Change Process Owner

For large organizations, this might be the management team sponsor with change process
development and organizational leadership responsibility. In small and midsize businesses, one
person can take the change owner and manager roles. The change process owner:

Is responsible for the end-to-end success of the change process

Drives continuous improvement for change management

Liaises with other process owners to establish integration and collaboration

Develops and delivers senior leadership of change management strategies and IT-wide
communication plans

2.4.2

Change Process Manager

The change process manager is the policy guardian for the change management process, and is
responsible for standards issuance and revision of procedures or forms. He or she also:

Executes, manages and reviews change management process activities on a daily basis

Chairs the change advisory board (CAB) and the emergency change advisory board (ECAB)

Communicates enhancements/modifications to the change management community

Provides training on the change management process

2.4.3

Change Owner/Requestor

This person initiates a request for change (RFC) and may reside within the business unit or the IT
organization.

2.4.4

Change Implementer

This person is responsible for packaging and executing the RFCs.

Publication Date: /ID Number:
9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 7 of 22

2.4.5

Change Coordinator/Administrator

This person is responsible for assisting in RFC documentation review for an IT group, department
or division. He or she is sometimes referred to as a change agent, coordinator or administrator.

2.4.6

CAB Member

This person attends scheduled meetings or sends a deputy, and is empowered to make decisions
on behalf of the area he or she represents. The CAB may ask participants to take on
responsibilities such as a change technical reviewer a CAB member who provides technical
guidance during CAB assessment and authorization stages of one or more RFCs. This role
usually requires broad technical knowledge from the overall IT service to the CI level.

2.5 Define CAB and E-CAB Roles and Responsibilities

The CAB is a cross-functional group set up to evaluate change requests for business needs,
priorities, costs/benefits, and potential effects to other systems or processes. Typically, the CAB
will make recommendations for implementation, further analysis, deferment or cancellation.
Minimal staffing for the CAB will be change owner, change manager/agent, representative from
configuration management and a change technical reviewer. The CAB generally meets weekly to
review RFCs.
The E-CAB tends to be a smaller group (sometimes a subset of personnel from the CAB) to
review and approve emergency decisions.

2.5.1

CAB Guiding Principles

Sample CAB guiding principles include:

The CAB is comprised of at least one representative and alternate from each IT
functional area and appropriate non-IT functional areas, including line-of-business
representatives. The enterprise system management group maintains member listings
on the change intranet site. The change specialist and CAB decide whether more or
fewer groups are represented.

CAB members, representatives or alternates will communicate to their respective IT

functional areas on a timely basis and provide any follow-up activities.

The change manager will schedule regular meetings of the CAB to be attended by the
designated representative or alternate from each identified functional area.

Changes may be represented at a CAB meeting by the change owner/requestor,

implementer and the change coordinator/administrator.

If the owner or a designated substitute does not represent a change that requires
representation at a CAB meeting, then the change is postponed and the change
specialist informs the owner.

The CAB is not allowed to stop a change because of disagreement with the technical
methods proposed by subject-matter experts assigned to a specific change request.

The CAB or change coordinator can postpone a change if it is determined that the
change does not follow change policy or is logistically unworkable. The change
specialist informs the owner.

2.6 Define RFCs, Types, Categories and Classifications

Business or IT personnel can initiate an RFC. This wide range of potential change initiators and
change activity requires consistent and complete guidance regarding documenting an RFC.
Publication Date: /ID Number:
9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 8 of 22

Fundamentally, the change record becomes the source of truth regarding information from the
initial documentation RFC to the subsequent recording of data as it progresses through the RFC
life cycle. Therefore, it is essential to pre-define the various attributes of an RFC. The IT change
management policy document needs to ensure that appropriate definitions and procedures are
described to cover the range of potential RFCs.
The formal change request includes a description of the change, components affected, business
needs, cost estimates, risk assessment, resource requirements and the approval status.

2.6.1

Change Types

To ensure standardized methods and procedures, a common taxonomy is required to define the
various RFC attributes. Even with IT Infrastructure Library (ITIL) recommendations, names and
definitions vary. The identification of these attributes is critical because it determines the
appropriate procedures for dealing with a particular type of RFC, such as emergency RFCs,
which may have different authorization and documentation requirements. The following examples
leverage basic ITIL concepts:

Emergency: A change request to repair a failure or imminent failure. Typically, this is

associated with a critical priority (severe impact and urgency) problem ticket that affects
production, causes outages or significant degradation in business, or is accompanied by
sufficient business justification. In most cases, this request is executed with limited
documentation and is outside the standard change schedule time.

Standard (pre-approved): A pre-approved change that is low risk and adheres to an

approved, typically well-tested procedure or work instruction. It is relatively common and
is the accepted solution for a specific requirement. It should be documented on a master
list of approved standard changes.

Normal: If a change is neither standard nor emergency, then it is categorized as normal.

An RFC should be categorized as normal. Therefore, the RFC is not a repeatable,
previously documented change (standard), is not the result of a critical priority problem
management ticket and is not accompanied with sufficient justification (emergency). The
use of the term "normal" may be easily confused with "standard." Some organizations
will use the terms "planned" and "unplanned" to enhance the description of normal
RFCs.

Planned: A change request submitted within policy requirements for documentation,

review and lead time

Unplanned: A change request not compliant with policy for documentation, review
and lead time

To assess the impact of an RFC on an IT service, a matrix evaluation is executed via a set of
categories (impact, risk and priority). There is a relationship among impact, risk and priority
from philosophical and mechanical perspectives.

2.6.2

Priority

Based on an ITIL definition, this classification identifies the relative importance of an RFC. The
RFC priority status is based on RFC classification variables, with input from the change manager.
Typically, this assignment is used to sequence an RFC to address an incident or problem that
needs to be resolved, based on impact and urgency. This can also be used to meet business
demands, such as the implementation of an enhancement to an application. Typical priority level
descriptions include:

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 9 of 22

Low: An RFC is necessary; however, it can wait until the accepted policy release
timelines. The problem has minimal impact or the application change enhancement has
limited business impact.

Medium: An RFC is designed to address a problem of medium-to-low impact. Customer

or IT services are not affected. Business risk is low.

High: The RFC addresses a severe problem that affects production systems and
demands immediate attention. Customer or IT service has been partially disrupted.
Business risk is high to medium (for example, slowed business operations).

Critical: An RFC is justified to address a problem that affects mission-critical production

systems. Customer or IT service has been disrupted. Business risk is high (for example,
immediate financial impact).

2.6.3

Risk

Risk defines the potential disruption of business operation associated with a given change
request. A risk is measured by the probability of a threat or the vulnerability of the IT service to
that threat. Typical risk definitions are:

None: The RFC has no potential for disruption.

Low: Business operations may be interrupted or delayed with little impact to

commitments.

2.6.4

Requires no work outage

Affects only one noncritical application or system

Affects a limited number of clients

Involves changes that are made during nonproduction hours

Medium: Business operations may be interrupted or delayed, which affects

commitments.

Requires a limited outage

Affects a few applications or one mission-critical application

Requires a business application redesign or enhancement

Affects greater than X clients (use impact for guidance)

High: Business operations may be interrupted or delayed, resulting in financial impact to

the business.

Requires a widespread outage

Affects multiple business-critical applications

Requires a new business application or a major redesign

Affects more than X clients (use impact for guidance)

Impact

Impact measures the pain caused by a defective IT service. In most cases, variables such as
geography, users and so on help identify the scale. Typical impact classification definitions are:
Publication Date: /ID Number:
9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 10 of 22

2.6.5

Low:

Affects one to a few end users

Affects a few CIs (for example, one to 10 desktops and one server)

Notification is needed for one IT department

Medium:

Affects multiple customers

Affects CIs

Notification is needed for a few IT and business departments

High:

Affects multiple departments and sites

Affects multiple and/or a variety of CIs (for example, desktops and servers, multiple
services and/or a mission-critical service, such as three mission-critical applications,
50 servers and 250 desktops)

Notification is needed for multiple IT departments and business sites

Additional Categorization and Classification

Accurate information regarding the IT service and CIs enables the CAB to assess the affected
and potential collision of a proposed RFC. To improve consistency from a data integrity and
workflow perspective, this section offers guidance on common IT services, assets and/or CI
groups.

Development: Application development covering application activity from mainframe to

Web applications

Infrastructure: This typically covers network devices and other WAN "plumbing,"
including:

Data network circuits (WAN and LAN)

Data network devices (routers, switches, hubs and firewall components)

Voice components (PBXs, phone switches and mail devices)

Specialized printers (metal tag and so forth)

Plant/site power maintenance/outages

Plant physical inventories

Plant work shutdowns

Operations: Server, database and overall production, including:

Servers (Unix, Intel, AS/400, Linux and OS Patching/Upgrades)

Database upgrades (Oracle, Progress, AdaBas and DB2)

Data cleanup (dump/reloads, archival, purging, mass data loads or modifications)

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 11 of 22

Mainframes

Storage (arrays, local disks, tape/cartridge devices and firmware upgrades)

Partners: Outsourcers or other third-party partners covering outsourced or multisourced

services

Security: Security processes covering security policy improvements, such as

authentication

Service: IT services from strategy to continual improvement

Support: Service desk

Based on the various attributes documented in the RFC record, these groups define the change's
impact on the infrastructure, users or business. The change complexity and resources required,
and analysis of risk, impact and priority, are measured to determine the category. These are
aligned with specific procedure models that detail the steps needed to handle review and
authorization:

Major: Major changes potentially affect the department or entire company. They may
affect multiple CIs. Multiple IT departments and multiple business sites need to be
notified.

Significant: These changes may affect a group or department and multiple CIs.
Notification is needed for a few IT departments and business departments.

Minor: These changes affect a few users and CIs (for example, one to 10 desktops or
one server). Notification is needed for one IT department.

Standard: A pre-approved change that is low risk and adheres to an approved, typically
well-tested procedure or work instruction, is relatively common and is the accepted
solution for a specific requirement.

2.6.6

Documenting RFCs

Documenting an RFC enables organizations to manage the process flow and control changes.
Also, documentation creates a record that will retain the complete history of a given change.
Different types of RFCs will require different degrees of data documentation. However, there
tends to be a baseline of required data based on type class, category and the service affected.
Typical baseline RFC record data fields include:

Change owner and implementer as defined in the policy document.

Class, category, priority, risk and impact as defined in the policy document.

Change type as defined in the policy document.

CIs: The requesting group should provide a list of items to the remote group for input
into the inventory or configuration management database on a regular basis.

Brief description: A short description or title that summarizes the change.

Business justification: A reason to perform a change, or the negative impact to the

business if a change is not performed.

Change schedule: Includes targeted implementation.

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 12 of 22

Backout plan: Included within request (specific field) or attached as an external

document.

Approver: Key groups and individuals required to provide approval prior to the
implementation.

Closure: The requestor closes request. If the person makes the request on behalf of a
business unit, then he or she must receive acknowledgement from that unit once the
issue is closed.

2.6.7

RFC Documentation Principles

All changes have a business justification, documented resource and a defined feasible
technical solution.

Unless previously exempted, any change to the IT production environment requires a

change request in the change system.

Maximum use of templates must occur for standard and repetitive changes.

Use established change priorities as guidelines in the decision. The change manager is
the neutral arbiter for assignment review. If an agreement cannot be reached with the
change manager, then appeal to the next-most-senior level of management.

For specified change types, such as high risk/high impact, changes require documented
plans for testing, implementation, backout, notification and verification of success.
Operating or support procedures, such as rerun instructions, problem resolution scripts
and other information, may also be required, and support staff must be involved.

Emergency changes are usually the result of a problem and require a problem ticket.

Emergency changes require appropriate prior notification. However, formal approvals

may be obtained after the fact. A post-review must be conducted for all emergency
changes.

2.7 Process Workflows

Pre-defined change process models offer the needed procedural guidance for an RFC. The
exercise of defining the various attributes of a change will dictate the established workflow path it
follows. Figure 2 provides an example of the "macrostages" of a process flow diagram that
presents the key tasks needed to be performed to successfully deploy a change.

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 13 of 22

Figure 2. Change Management Process

Document
Document
Change
Change

Assess
Assess
Change
Change

Authorize/Reject
Authorize/Reject
Change
Change

Schedule/Implement
Schedule/Implement
Change
Change

Review
Review
Change
Change

Close
Close
Change
Change

Source: Gartner (February 2008)

It is important to follow IT change management workflow to synchronize with release and

configuration management process workflows. The diagram in Figure 3 demonstrates key
intersection points between configuration and release management with a normal RFC workflow.
Note that it also includes defined procedure models for the RFC categories listed in Section 2.6.5.

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 14 of 22

Figure 3. RFC Integrative Process Workflow

Change Requestor
Reports and
Audit

RFC Document
Yes

Emergency?

Go to emergency
workflow

No
Identify
CIs

Assess Change

No

Yes Minor
Approve/
Reject Change

Significant

Major

CAB

CAB and Exec. Team

Change Mgr.

Schedule/
Implement
Change

Change
Development

Update
Records

Configuration
Management
Change
Review
Capture
Release
Baselines

Build Change

Release
Management

Test Change
Change Mgr.
Yes
Review
Change

Success?

Working?

No

Backout Change
Audit CIs

No

To Start

Review
Updated
Records

Yes
Close Change
Statistics and Reporting
Source: Gartner (February 2008)

The macrostages can be decomposed to specific activity or task flows. Figure 4 represents an
example of an approval stage and the established tasks required to complete it. Note the task
level integration with configuration management that acknowledges the update to configuration
management based on the RFC approval.

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 15 of 22

Figure 4. Change Approval Workflow

Assessment

Correct
Approvers?

No

Modify
Approver List

Yes
Evaluate RFC
and Impact
Assessment

Collect
Individual
Approvers

CAB Review
and Approval
if Needed

Approved?

No

Return to
Requestor

Yes

Update RFC
Status

Configuration
Management
Scheduling

Source: Gartner (February 2008)

For some change management policies, workflows can be very detailed and cover processes,
tools and individual roles. These tend to be presented in a "swimlane" structure (see Figure 5).

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 16 of 22

Research
ID Number:

Publication Date:

Figure 5. Change Request Swimlane

Minor Change Workflow

External
Interface
Minor
Change

Change
Requestor

Status: Document

Status: Classify

Status: Assess

Create Minor
Request for
Change

Determine RFC
Implementation
Date/Time

Complete RFC and

Forward to Mgr. for
Approval

Change
Authorization
Approver

RFC "Not
Approved"
Status: Document
Meet With
Requestor/
Owner to Resolve
Issues

Status: Approve
Mgr. Receives and
Reviews RFC
for Approval

Close
RFC

Yes
Can Issue Be
Resolved?

No

No
Approve
RFC?
Yes
Status: Schedule

Change
Coordinator

Change
Implementer

Tools/Data

Place RFC as
Submitted in
Calendar

Status: Implement
Assign Submitted
RFC to Change
Coordinator

RFC to
Implem.

Notify Requestor of
Submission Approval

Change Management Tool

Source: Gartner (February 2008)

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein
has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no
liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials
to achieve its intended results. The opinions expressed herein are subject to change without notice.

Research
Publication Date:

3.0

ID Number:

Integrative Process Partners

This section identifies integration exchanges between IT change management and other core IT
processes. Although these integration points are critical for long-term IT change management
maturity and effectiveness, many supporting process partners can be at varying degrees of
maturity within the IT organization. This small list focuses on a few key processes where high
levels of integration will be required and may require IT change management re-engineering
efforts as the process integration evolves.
Figure 6 is not exhaustive and is a typical representation of ITIL-specific process integrations.
This can include facilities, manufacturing plant processes, internal audits, third-party vendors and
so on. The figure describes the typical key processes and integration points specific to inputs or
outputs to IT change management.

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior
written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable.
Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no
liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader
assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed
herein are subject to change without notice.

Figure 6. Linking Key Processes to IT Change Management

IT Service Support

IT Service Delivery

Incident
Management

Service-Level
Management

Link record and historical

knowledge with the change
record.

IT Change
Management

Problem
Management

Capacity
Management
TBD fiscal 200X.

Configuration
Management

Financial
Management

Link CI knowledge to change

record. Support impact and risk
analysis.

Link RFC to release record.

Provide test, implement and
backout plan touchpoints.

Availability
Management
TBD fiscal 200X.

Link record and historical

knowledge with the change
record.

Release
Management

Ensure that business costs and

requirements are shared.

TBD fiscal 200X.

Project Management
Link project production
deliverable to RFC.

Service Continuity
Management
Place documented disaster
recovery workflows under
change control. Use ITCM for
disaster recovery test
communication.

Source: Gartner (February 2008)

3.1 Business Continuity Management and Disaster Recovery

Business continuity management (BCM) maintains and restores mission-critical business
processes, personnel and facilities, with the goal of ensuring emergency preparedness and
business resiliency. BCM includes six major components:

Risk management and mitigation

Disaster recovery

Business recovery

Business resumption

Contingency planning

Crisis management

Disaster recovery management restores access to production applications and data following a
partial or complete interruption of data center operations. It is fundamental to successful BCM,
Publication Date: /ID Number:
9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 19 of 22

whose focus is the overall resumption of business operations following the occurrence of one or
more disruptive events.
The design of these procedures and plans should be under strict change control to ensure that
they are consistent and accurate, and that all stakeholders are aware of changes. In the case of
disaster recovery activity, testing activity can leverage IT change management for communication
and may be required to submit a change request.

3.2 Configuration Management

Configuration management maintains information about CIs from individual technical domains to
IT services. Configuration management should provide guidance regarding how to collect and
federate the wide variety of configuration information into a logical model of service by identifying,
controlling, maintaining and verifying the versions of CIs in existence. A configuration
management database maintains, federates and reconciles CI data into a single IT services view
to support RFC analysis. IT change management access to accurate configuration information
enables IT staff to assess the impact of proposed changes and to track results.

3.3 Incident and Problem Management

Incident management's purpose is to restore normal service operation as quickly as possible and
to minimize the adverse impact on business operations, thus ensuring service quality and
availability.
Problem management minimizes the adverse impact of incidents and problems on the business
that are caused by errors within the IT infrastructure, and to prevent recurrence of incidents
related to these errors. Problem management is a key process because changes are often
required to implement a fix to a known error. Thus, problem management will generate RFC
activity and contribute to CAB activity.

3.4 Project Management

Project management is a collection of processes focused on the disciplined management of IT
projects. The Project Management Body of Knowledge Guide and PRINCE2 offer industry
methodologies suitable to manage IT projects covering the organization, control and
management of a project. Integration with change management processes will provide analysis
and control of identified changes to the IT production environment from project deliverables.

3.5 Release Management

Release management coordinates the many sources involved with a significant release of
hardware, software and associated documentation across a distributed environment.

3.6 Examples of Key Policy Integration

4.0

Release events must be reviewed, scheduled, tracked and measured. Any changes
identified as emergency, off-calendar or that have missed required lead times are
approved and negotiated by the IT change manager and executive CAB.

All changes will be adequately tested in the acceptance environments prior to

implementation in production. If a test or acceptance environment is not available, then
the risk level of the change will be increased appropriately.

Schedule/Calendar

IT change management should coordinate the production and distribution of a change schedule
and a projected service impact or availability. A change schedule, formerly referred to as a
Publication Date: /ID Number:
9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 20 of 22

forward schedule of change in ITIL v.2, contains information about future changes, as well as
those that have already been implemented.

4.1 Scheduling Key Policy Attributes

Changes will be implemented at predetermined times appropriate to business processes

and the functions and cycles they support. All new projects will adhere to these
schedules.

Changes must adhere to the approval lead times published in this process guide.

Changes that must be moved from a status of "scheduled" or "in progress" to

"postponed" revert to a status of "requested" and go through the entire CAB review
process again.

4.2 Change Measurement

Metrics are pivotal in managing and monitoring the IT change management process. They
baseline a process, determine the effect of process improvements, identify areas where the
process may be ineffectual or broken, and assess improvements.

4.3 Critical Success Factors

All changes are tracked.

Post-mortem changes are done consistently and reported.

Process workflows will be integrated within IT operations and application development

tools.

4.4 Quality and Efficiency Metrics

Number and percentage of emergency changes

Number and percentage of successful changes

Application performance and availability: planned/unplanned downtime associated with

changes and the mean time to repair Severity Level 1 or Level 2 problems

Ratio of problem- and defect-associated changes

Change volume: looking for month-to-month spikes

Change activity: higher volume or percentage by department, type or item

Change backouts: higher by department, type or item

Problem/defect: higher by department, type or item

Cost of change

4.5 Compliance and Control

Audit key policy attributes:

Unless a person is classified as exempted implementer or policy approver, he or she

cannot approve or implement changes.

Changes must be submitted in a change control tool by day and time, in compliance
with policy lead times, to be considered for review in the weekly CAB meeting.

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 21 of 22

5.0

After implementing a change, the change implementer should set the status to "post
review," add any appropriate notes about the implementation to the change request
and execute appropriate communication regarding the status of the change.

RFC closure requires verification that an approved RFC was executed according to
documentation. This can be done via various change management roles in concert
with auditing or configuration management tools.

Communications, Coordination and Education Methods

5.1 Key Meetings

For meetings to be effective, they must occur consistently. All attendees should be aware of the
meeting's goals, objectives and expected outcomes. Attendees should be clear on their roles.
Examples of common meetings include:

Daily change manager review

CAB weekly significant and major RFC review

Problems caused by change weekly review

5.2 Cross-Departmental Collaboration and Coordination

This area should cover the expected methods of collaboration and coordination among IT
departments, partners and the business. Examples of policy guidance include:

Coordination with support groups that perform changes must be done with adequate
lead time for the support group to schedule resources. When resources are not available
to implement all requested changes in the desired time frames, the support group
manager and change owner decide on resource allocation.

Prior to review by the change review team, project teams, support groups, business
partners and the change specialist plan and coordinate changes.

5.3 Training Programs

The training and education of the change management process must eliminate inefficiencies and
quality gaps, and enable consistent process skills. Change management training must be
consistent across all areas of the organization. Sample training methods include:

A semiannual IT change management workshop led by the change process owner

Key IT change management meeting led by the IT division attending ITIL certification

Quarterly luncheon meetings to review the IT change management policy

Publication Date: /ID Number:

9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 22 of 22