Artifact: Change Request

Relationships

Roles	Responsible: Change Owner	Modified By: Asset Analyst Availability Analyst Availability Manager Capacity Analyst Capacity Manager Configuration Librarian Event Analyst Facilities Business Planner Facilities Management Specialist Incident Owner ITSC Analyst ITSC Manager Problem Owner Release Manager Request Analyst Requestor Security Analyst Service Catalog Designer Service Catalog Manager Service Delivery Manager
Tasks	Input To: Assign Release Owner Create Change Request Define Change Approach Filter, Validate, and Accept Change Gather Continuity Plans Initiate Change Request Submit Change Request	Output From: Assign Release Owner Communicate and Execute Resumption Plan Create and Submit Change Request Create Change Request Create Change Request to Deploy Facility Solution Define Change Approach Deploy Service Catalog Determine Reconciliation Actions Initiate Agreed Corrective Actions Initiate Change Request Initiate Change Request Initiate Change Request Initiate Change Request Initiate Change Request Initiate Change Request Initiate Change Request Initiate Change Request Initiate Change Request Initiate Change Request Initiate Change Request Initiate Change Request Initiate Change Request to Fix Root Cause Review with Stakeholders Route Service Request Submit Change Request Submit Change Request

Description

Main Description	Change Requests (also known as RFCs) are the means for submitting proposed change and actual change activity in the environment. Change Requests can be triggered for a wide variety of reasons, from a broad spectrum of sources. They can be concerned with any part of the environment or with any service or activity.

Illustrations

Templates	Change Request Template

Key Considerations

The various states of a Change Request include the following:

Conceptualized - A change request that is conceptual in nature, may not have been formally created, and has not yet been submitted.
Recorded - The details of a change request, captured in a document or other format defined by the Change Management Framework.
Rejected - Any change request which has been rejected, and sent back to the requestor. Reasons for rejection include:
- Lack of authorization or funding
- The change requested is beyond the scope of Change Management (for example, it is a new requirement)
- The change request is incomplete or in error
- The change request has been assessed as having too high a risk and needs rework

Note: A Change Request, once recorded, is tracked as a Change.

Simple IMACs may be service requests. More complex ones are typically change requests because they require approval.

The following items are normally included in both paper and electronic Change Request forms:

Change Request number (plus cross reference to Problem report number, where necessary)
description and identity of item(s) to be changed (including CI identification(s) if Configuration Management system is in use)
reason for Change
effect of not implementing the Change
version of item to be changed
name, location and telephone number of person proposing the Change
date that the Change was proposed
Change priority
impact and resource assessment (which may be on separate forms where convenient)
CAB recommendations where appropriate (which may be held separately, with impact and resource assessments, where convenient)
authorization signature (could be electronic)
authorization date and time
scheduled implementation (Release identification and/or date and time)
location of Release/implementation plan
details of Change builder/implementer
back-out plan
actual implementation date and time
review date
review results (including cross-reference to new Change Request where necessary)
risk assessment and management
impact on business continuity and contingency plans
status of Change Request- e.g. 'logged', 'assessed', 'rejected', 'accepted', 'sleeping'.