IT Change Management Policy Documentation Guidelines

ResearchPublication 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........................................................................................................................................... 41.0 Governance Introduction.......................................................................................4

1.1 Mission.....................................................................................................41.2 Strategy and Objectives...........................................................................41.3 Scope.......................................................................................................5

2.0 Change Management Definitions, Roles, Classifications and Procedures............52.1 Change Definition.....................................................................................52.2 Change Policy Document Management...................................................52.3 Change Management Guiding Principles.................................................5

2.3.1 Change Agility Principle...............................................................62.3.2 Common Change Management Principle....................................6

2.4 Define Individual Roles and Responsibilities............................................72.4.1 Change Process Owner..............................................................72.4.2 Change Process Manager...........................................................72.4.3 Change Owner/Requestor...........................................................72.4.4 Change Implementer...................................................................72.4.5 Change Coordinator/Administrator..............................................82.4.6 CAB Member...............................................................................8

2.5 Define CAB and E-CAB Roles and Responsibilities.................................82.5.1 CAB Guiding Principles...............................................................8

2.6 Define RFCs, Types, Categories and Classifications...............................82.6.1 Change Types.............................................................................92.6.2 Priority.........................................................................................92.6.3 Risk...........................................................................................102.6.4 Impact........................................................................................102.6.5 Additional Categorization and Classification..............................112.6.6 Documenting RFCs...................................................................122.6.7 RFC Documentation Principles..................................................13

2.7 Process Workflows.................................................................................133.0 Integrative Process Partners...............................................................................18

3.1 Business Continuity Management and Disaster Recovery.....................193.2 Configuration Management....................................................................203.3 Incident and Problem Management........................................................203.4 Project Management..............................................................................203.5 Release Management............................................................................203.6 Examples of Key Policy Integration........................................................20

4.0 Schedule/Calendar..............................................................................................204.1 Scheduling Key Policy Attributes............................................................214.2 Change Measurement............................................................................214.3 Critical Success Factors.........................................................................214.4 Quality and Efficiency Metrics................................................................214.5 Compliance and Control.........................................................................21

5.0 Communications, Coordination and Education Methods.....................................225.1 Key Meetings..........................................................................................225.2 Cross-Departmental Collaboration and Coordination.............................225.3 Training Programs..................................................................................22

LIST OF FIGURES

Figure 1. Revision History...............................................................................................................5

Publication Date: /ID Number: Page 2 of 22

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

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



Analysis

1.0 Governance Introduction

1.1Mission

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.2Strategy 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.



1.3Scope

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.1Change 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.2Change 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

1.01

1.00

Changes/ Justifications

Author/ Reviser

DateStatusVersion

Revision History

1.01

1.00

Changes/ Justifications

Author/ Reviser

DateStatusVersion

Revision History

Source: Gartner (February 2008)

2.3Change 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.



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.

· 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.

2.3.2 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.

· Policies:



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

· All changes will be handled through the change management processes.

2.4Define 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 (E-CAB)

· 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.



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.5Define 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.6Define 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.



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:



· 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.

· 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)

2.6.4 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:

· 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

2.6.5 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)

· 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.

· 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.7Process 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.



Figure 2. Change Management Process

Document Change

Document Change

AssessChange

AssessChange

Authorize/Reject Change


Schedule/Implement Change


Review Change

Review Change

CloseChange

CloseChange

Document Change

Document ChangeDocument

Change

Document Change

AssessChange

AssessChangeAssessChange

AssessChange









Review Change

Review ChangeReview Change

Review Change

CloseChange

CloseChange

CloseChange

CloseChange


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.



Figure 3. RFC Integrative Process Workflow

Change Requestor

RFC Document

Emergency?Yes

Change Mgr.

Minor

CAB

Significant

CAB and Exec. Team

Major

No

Schedule/ Implement

Change

Go to emergency workflow

Yes

No

Close Change

Yes No

Statistics and Reporting

Release Management

Reports andAudit

IdentifyCIs

UpdateRecords

CaptureRelease

Baselines

ReviewUpdatedRecords

Configuration Management

Assess Change

To Start

Approve/ Reject Change

Change Development

Change Review

Working? Backout ChangeReviewChange

Success?

Audit CIs

Build Change

Test Change

Change Mgr.

YesNo

Change Requestor

RFC Document

Emergency?Yes

Change Mgr.

Minor

Change Mgr.

Minor

CAB

Significant

CAB

Significant

CAB and Exec. Team

Major

CAB and Exec. Team

Major

No

Schedule/ Implement

Change

Go to emergency workflow

Yes

No

Close Change

Yes No

Statistics and Reporting

Release Management

Reports andAudit

IdentifyCIs

UpdateRecords

CaptureRelease

Baselines

ReviewUpdatedRecords

Configuration Management

Assess Change

To Start

Approve/ Reject Change

Change Development

Change Review

Working? Backout ChangeReviewChange

Success?

Audit CIs

Build Change

Test Change

Change Mgr.

YesNo


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.



Figure 4. Change Approval Workflow

ModifyApprover List

Approved?

Scheduling

No

Yes

No

Yes

CorrectApprovers?

Return toRequestor

Assessment

Evaluate RFCand ImpactAssessment

CollectIndividualApprovers

CAB Reviewand Approval

if Needed

Update RFCStatus

ConfigurationManagement

ModifyApprover List

Approved?Approved?

SchedulingScheduling

No

Yes

No

Yes

CorrectApprovers?

CorrectApprovers?

Return toRequestorReturn toRequestor

AssessmentAssessment

Evaluate RFCand ImpactAssessment

CollectIndividualApprovers

CAB Reviewand Approval

if Needed

Update RFCStatus




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).




Figure 5. Change Request Swimlane

RFC toImplem.

Minor Change Workflow

ExternalInterface

ChangeImplementer

ChangeRequestor

ChangeAuthorization

Approver

ChangeCoordinator

Tools/Data

RFC "NotApproved"

Yes

Change Management Tool

MinorChange

No

Yes

No

Notify Requestor ofSubmission Approval

Determine RFCImplementation

Date/Time

Status: Classify Status: Assess

Mgr. Receives andReviews RFCfor Approval

Status: Approve

Meet WithRequestor/

Owner to ResolveIssues

Status: DocumentCloseRFC

Can Issue BeResolved?

ApproveRFC?

Place RFC asSubmitted in

Calendar

Status: Schedule

Assign SubmittedRFC to Change

Coordinator

Status: Implement

Create MinorRequest for

Change

Status: Document

Complete RFC andForward to Mgr. for

Approval

RFC toImplem.RFC toImplem.

Minor Change Workflow

ExternalInterface

ChangeImplementer

ChangeRequestor

ChangeAuthorization

Approver

ChangeCoordinator

Tools/Data

RFC "NotApproved"

Yes

Change Management Tool

MinorChangeMinor

Change

No

Yes

No

Notify Requestor ofSubmission Approval


Date/Time

Status: Classify


Date/Time

Status: Classify Status: Assess


Status: Approve


Status: Approve

Meet WithRequestor/


Status: DocumentMeet WithRequestor/


Status: DocumentCloseRFCCloseRFC

Can Issue BeResolved?

ApproveRFC?


Calendar

Status: Schedule


Calendar

Status: Schedule


Coordinator

Status: Implement


Coordinator

Status: Implement


Change

Status: Document


Change

Status: Document

Complete RFC andForward to Mgr. for

Approval




3.0 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.


Figure 6. Linking Key Processes to IT Change Management

IT Change Management

IncidentManagement

ProblemManagement


ReleaseManagement

IT Service Support IT Service Delivery

CapacityManagement

AvailabilityManagement

FinancialManagement

Service ContinuityManagement

Service-LevelManagement

Link record and historical knowledge with the change record.

Ensure that business costs and requirements are shared.

Project Management

Link RFC to release record. Provide test, implement and backout plan touchpoints.

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

Link project production deliverable to RFC.


Link CI knowledge to change record. Support impact and risk analysis.

TBD fiscal 200X.

TBD fiscal 200X.

TBD fiscal 200X.

IT Change Management

IncidentManagement

ProblemManagement


ReleaseManagement

IT Service Support IT Service Delivery

CapacityManagement

AvailabilityManagement

FinancialManagement

Service ContinuityManagement

Service-LevelManagement


Ensure that business costs and requirements are shared.

Project Management

Link RFC to release record. Provide test, implement and backout plan touchpoints.

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

Link project production deliverable to RFC.


Link CI knowledge to change record. Support impact and risk analysis.

TBD fiscal 200X.

TBD fiscal 200X.

TBD fiscal 200X.


3.1Business 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,



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.2Configuration 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.3Incident 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.4Project 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.5Release Management

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

3.6Examples of Key Policy Integration

· 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.

4.0 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



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

4.1Scheduling 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.2Change 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.3Critical 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.4Quality 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.5Compliance 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.



· 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.

5.0 Communications, Coordination and Education Methods

5.1Key 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.2Cross-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.3Training 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



Documents

IT Change Management Policy Documentation Guidelines