Checklist Request for Change RFC: Difference between revisions

From IT Process Wiki
mNo edit summary
mNo edit summary
Line 14: Line 14:
'''Source''': Checklist "Request for Change - RFC" from the [https://en.it-processmaps.com/products/itil-process-map.html ITIL Process Map V3]
'''Source''': Checklist "Request for Change - RFC" from the [https://en.it-processmaps.com/products/itil-process-map.html ITIL Process Map V3]


<p>&nbsp;</p>


The ''Request for Change (RFC)'' is formal request for the implementation of a Change. A Request for Change is to be submitted to [[Change Management]] for any non-standard Change (a set of standard/ routine Changes is usually defined by Change Management; these are minor Changes which do not require submission to the Change Management process).


A Change is backed by a Change Owner, holding a budget for its implementation. In many cases the Change Owner is identical with the RFC initiator. Typically Changes are owned by [[Roles within ITIL V3|Service Management roles]] (e.g. the Problem Manager or Capacity Manager) or by IT management.


The '''Request for Change (RFC)''' is formal request for the implementation of a Change. A Request for Change is to be submitted to Change Management for any non-standard Change (a set of standard/ routine Changes is usually defined by Change Management; these are minor Changes which do not require submission to the Change Management process).
The RFC is a precursor to the [[Change Management#Change Record|Change Record]] and contains all information required to approve a Change. Further information is added as the Change progresses through its lifecycle.


A Change is backed by a Change Owner, holding a budget for its implementation. In many cases the Change Owner is identical with the RFC initiator. Typically Changes are owned by Service Management roles (e.g. the Problem Manager or Capacity Manager) or by IT management.
The level of detail depends on the size and likely impact of the Change. Often there will be references to further documents containing more detailed information, e.g. a detailed Change proposal. As major Changes are typically implemented as projects, the RFC often takes on the role of what is also known as a "Project Charter".


The RFC is a precursor to the Change Record and contains all information required to approve a Change. Further information is added as the Change progresses through its lifecycle.
'''A Request for Change contains the following information:'''
 
The level of detail depends on the size and likely impact of the Change. Often there will be references to further documents containing more detailed information, e.g. a detailed Change proposal. As major Changes are typically implemented as projects, the RFC often takes on the role of what is also known as a “Project Charter”.


<p>&nbsp;</p>


# Unique ID
# Unique ID
Line 30: Line 32:
# Change Owner
# Change Owner
# Initiator of the RFC (if not identical with Change Owner)
# Initiator of the RFC (if not identical with Change Owner)
# Proposed Change priority (e.g. “Very High (Urgent Change), “High”, “Normal”, “Low” - may be overruled by Change Management during Change assessment)
# Proposed Change priority (e.g. "Very High (Emergency Change)", "High", "Normal", "Low" - may be overruled by Change Management during Change assessment)
# Description of the Change being applied for
# Description of the Change being applied for
## Summary description
## Summary description
Line 38: Line 40:
### Benefits
### Benefits
### Consequences if the Change is not implemented
### Consequences if the Change is not implemented
### References (e.g. to a Problem Record triggering this RFC)
### References (e.g. to a [[Problem Management#Problem Record|Problem Record]] triggering this RFC)
## Business areas on the client-side affected by the Change
## Business areas on the client-side affected by the Change
## Services affected by the Change
## Services affected by the Change
## IT infrastructure components (CIs) affected by the Change
## IT infrastructure components ([[Checklist CMS CMDB|CIs]]) affected by the Change
## Technology aspects (is a new technology being introduced?)
## Technology aspects (is a new technology being introduced?)
# Risks during the implementation of the Change  
# Risks during the implementation of the Change  
Line 53: Line 55:
## Cost estimate (itemized for bigger Changes)
## Cost estimate (itemized for bigger Changes)
# Statement as to whether a budget is allocated and cleared for this Change
# Statement as to whether a budget is allocated and cleared for this Change
# If applicable, index of additional supporting documents (e.g. the Service Design Package for major additions or modifications to services)
# If applicable, index of additional supporting documents (e.g. the [[Service Level Management#SDP|Service Design Package]] for major additions or modifications to services)
# Approval or rejection
# Approval or rejection
## Date
## Date
## Person/ body in charge of the approval (Change Manager/ CAB/ EC)
## Person/ body in charge of the approval ([[Roles within ITIL V3#Change Manager|Change Manager]]/ [[Roles within ITIL V3#Change Advisory Board (CAB)|CAB]]/ [[Roles within ITIL V3#Emergency Change Advisory Board (ECAB)|ECAB]])
## Change reviewers
## Change reviewers
## Priority assigned by Change Management
## Priority assigned by Change Management

Revision as of 11:32, 4 September 2011

<seo metakeywords="request for change process, itil rfc process, change request checklist" metadescription="The Request for Change (RFC) is formal request for the implementation of a Change. A Request for Change is to be submitted to Change Management ..." />

DE - ES - Checklist Request for Change RFC - Template Request for Change RFCdiese Seite auf Deutschesta página en español
DE - ES - Checklist Request for Change RFC - Template Request for Change RFC


ITIL Process: ITIL V3 Service Transition - Change Management

Checklist Category: Checklists ITIL V3 Service Transition

Source: Checklist "Request for Change - RFC" from the ITIL Process Map V3

 

The Request for Change (RFC) is formal request for the implementation of a Change. A Request for Change is to be submitted to Change Management for any non-standard Change (a set of standard/ routine Changes is usually defined by Change Management; these are minor Changes which do not require submission to the Change Management process).

A Change is backed by a Change Owner, holding a budget for its implementation. In many cases the Change Owner is identical with the RFC initiator. Typically Changes are owned by Service Management roles (e.g. the Problem Manager or Capacity Manager) or by IT management.

The RFC is a precursor to the Change Record and contains all information required to approve a Change. Further information is added as the Change progresses through its lifecycle.

The level of detail depends on the size and likely impact of the Change. Often there will be references to further documents containing more detailed information, e.g. a detailed Change proposal. As major Changes are typically implemented as projects, the RFC often takes on the role of what is also known as a "Project Charter".

A Request for Change contains the following information:

 

  1. Unique ID
  2. Date of submission
  3. Change Owner
  4. Initiator of the RFC (if not identical with Change Owner)
  5. Proposed Change priority (e.g. "Very High (Emergency Change)", "High", "Normal", "Low" - may be overruled by Change Management during Change assessment)
  6. Description of the Change being applied for
    1. Summary description
    2. Business case
      1. Reason for the Change to be implemented
      2. Costs
      3. Benefits
      4. Consequences if the Change is not implemented
      5. References (e.g. to a Problem Record triggering this RFC)
    3. Business areas on the client-side affected by the Change
    4. Services affected by the Change
    5. IT infrastructure components (CIs) affected by the Change
    6. Technology aspects (is a new technology being introduced?)
  7. Risks during the implementation of the Change
    1. Identified risks
    2. Counter-measures (e.g. reversion procedure)
    3. Back-out strategy for the case of a failed Change implementation
  8. Predicted/suggested time schedule for the implementation
  9. Estimate of resources for the implementation
    1. Required personnel resources (from which areas?)
    2. Estimated work effort for the required personnel resources
    3. Cost estimate (itemized for bigger Changes)
  10. Statement as to whether a budget is allocated and cleared for this Change
  11. If applicable, index of additional supporting documents (e.g. the Service Design Package for major additions or modifications to services)
  12. Approval or rejection
    1. Date
    2. Person/ body in charge of the approval (Change Manager/ CAB/ ECAB)
    3. Change reviewers
    4. Priority assigned by Change Management
    5. Restrictions
    6. If applicable, reasons for rejecting the RFC