ITS Change Management Process

ITS Change Management

RFC Categories and Requirements

Version v2.0

April 22, 2015

1
Contents
1 Purpose ................................................................................................................................................................................................................... 3
2 RFC Categorization ................................................................................................................................................................................................ 3
Normal Change ....................................................................................................................................................................................................... 3
Emergency Change ................................................................................................................................................................................................ 7
Emergency Latent Change ..................................................................................................................................................................................... 9
Standard Change .................................................................................................................................................................................................... 9
3 RFC Lead Time Requirements ............................................................................................................................................................................. 10
4 RFC Approvals ...................................................................................................................................................................................................... 11

Page 2 of 12
1 Purpose
The purpose of Request for Change (RFC) categorization is to provide an accurate representation of the criticality, risk, and impact of an RFC
based on its category for Peer Reviewers, Service Leads, Deployment Approvers (CCB & ECCB), Managers and Customers.
RFC Categorization is based on a set of requirements and timelines for each category of RFC. An RFC not meeting its category criteria will need
to be revised or re-categorized under the appropriate type.

2 RFC Categorization
RFCs are categorized based on the following criteria and must adhere to the stated requirements. The differentiator between classifications used
for a Standard, Normal, or Emergency RFC is based on the scope, impact, risk, and priority of the change being drafted

Normal Change
A Normal RFC is a planned operational change to an IT service, IT asset, or infrastructure component(s), which carries between a
low to high level of risk and impact.
The level of risk and impact is determined by the RFCs risk score which is calculated using the RFC risk/impact analysis template (see below)
within ITS Service Management System (SMS). A Normal change must be completed within a pre-planned window of time and is coordinated
and implemented via a single technical unit or unified collaboration between multiple technical units. Customers may also participate in the
implementation of a Change, especially in the validation of the success or failure of a change.
Calculation of the risk/impact score is calculated via the weighting of the following questions:

Q# Risk/Impact Description Weight based on answer

1 The Change can be backed out? Yes =0
No =5

2 At some point during this Change the Service will not be Yes =5
available? No =0

3 This type of Change had previously failed on prior Yes = 10

implementations No =0

Page 3 of 12
4 Change is scheduled within a customer approved service Yes = (5)
maintenance window? No =5

5 Change was implemented successfully in the past? Yes = (5)

No =0

6 Change will affect components included in a Change freeze Yes = 25

No =0

7 Can Change be validated at time of implementation? Yes =0

No =3

8 The Change affects a component that other Systems or Yes = 10

Applications are dependent on? No =0

9 The Change affects a critical Service, Application or Yes = 10

Infrastructure component(s) No =0

10 The Change is to a Service or System used by Multiple None = 0

Departments (or Enterprise wide) Single Department or Workgroup =3
Multiple Departments = 6
County Wide = 10

11 Implementation/Validation of the Change requires coordination No = 0

of multiple ITS teams, vendors, and customer departments One other ITS Team / Vendor / Dept. = 2
2 to 3 other ITS Teams / Vendors / Depts. = 4
More than 4 ITS Teams / Vendors / Depts. = 5

12 If the Change is creating a Service Outage, to what extent will Service outages will occur intermittently during the Planned Outage
the Service be affected by the outage window =3

Service outage will occur during the whole Planned Outage

window = 5

There is the possibility of a 10 minute or less Service outage during

the Planned Outage window =2

The Service will be fully functional and will not experience any type of
disruption during this change =0
Score: Total Highest Score Possible = 93
Lowest Possible Score = -10

Page 4 of 12
 High Risk 24+
Medium Risk 10-23
Low Risk <=9

All Normal Changes, regardless of risk score, require at least one peer review from a member of the RFCs
owning team. If required additional peer reviews can be submitted to any staff member or team within
SMS. For a change to be properly evaluated for necessity, technical soundness, risk, and impact to the
organization and our customers, all relevant information must be documented in the RFC. In order to
effectively peer review an RFC, the peer reviewer should use the established guidelines mandated within
the Work Instructions for Drafting a Request for Change document
o Proof of peer review on Normal RFCs must be noted by the owning groups peer reviewer in the notes of the peer review task. Once
the peer review is completed the peer reviewer must click the [Completed] button from within the task and choose Completed as the
closure code. Use of any other closure code will keep the RFC from moving forward
o Changes that impact or interface with other services/technical silos must include at least one secondary peer review from the other
group(s)
o Secondary peer reviews, other than the owning groups reviewer, are responsible for assessing the impact of the change to their
environment
- If an issue is determined by a secondary peer reviewer, they should make accommodations for the anticipated impact, ask
that the change be stopped, rescheduled, and/or escalate by contacting the Change Owner and CAD-CMT with their concerns
The impact/risk score of a Normal Change determines the approval path that it will follow
o A low risk Normal RFC is accepted and approved by the owning teams Service Lead and CAD-CMT. It does not require Change
Control Board (CCB) approval

- Low Risk Normal RFCs require a lead time of 120 hours from the time of submitting for peer review
o A medium to high risk RFC is accepted and approved by the owning teams Service Lead and CAD-CMT, but also requires vetting
at the weekly Change Control Board meetings held at 1pm every Wednesday at the Downey facility. For more information on the
CCB please see this document
o Medium to high risk RFCs require a lead time of anywhere between 8 to 13 days depending on when the RFC is drafted vs. the
next available CCB
The process flow for Normal Changes, based on risk type, can be found on page 1 of this document
An explanation of how medium and high risk RFCs have their lead times documented is visually explained in the next following two images:

Page 5 of 12
Figure 1 - Normal Change Request Timelines

(See page six for second graphic)

Page 6 of 12
Figure 2 - Normal RFC Approval Activities and Timelines

Emergency Change
An Emergency RFC is specifically intended for changes that cannot meet the Normal RFC timelines
An Emergency change uses the Emergency RFC category
All Emergency Changes, regardless of risk score, require at least one peer review from a member of the
RFCs owning team. If required additional peer reviews can be submitted to any staff member or team
within SMS. For a change to be properly evaluated for necessity, technical soundness, risk, and impact to
the organization and our customers, all relevant information must be documented in the RFC. In order to
effectively peer review an RFC, the peer reviewer should use the established guidelines mandated within
the Work Instructions for Drafting a Request for Change document
o Proof of peer review on Emergency RFCs must be noted by the owning groups peer reviewer in the notes of the peer review task.
Once the peer review is completed the peer reviewer must click the [Completed] button from within the task and choose Completed
as the closure code. Use of any other closure code will keep the RFC from moving forward

Page 7 of 12
 o Changes that impact or interface with other services/technical silos must include at least one secondary peer review from the other
group(s)
o Secondary peer reviews, other than the owning groups reviewer, are responsible for assessing the impact of the change to their
environment
- If an issue is determined by a secondary peer reviewer, they should make accommodations for the anticipated impact, ask
that the change be stopped, rescheduled, and/or escalate by contacting the Change Owner and CAD-CMT with their concerns
There is no set lead time for an Emergency RFC (unlike Normal RFCs)
An Emergency Change may be drafted for a variety of reasons:
1) Avoid a Service Disruption (proactive measures taken)
2) Legal / Regulatory reasons
3) The change started as a Normal, but because it was denied or re-scheduled it can no longer meet the Normal RFC timeline
4) Resolve an Incident (*Note, if this reason code is used an associated Incident ticket(s) must be attached to the RFC)
5) Resolve a Problem (*Note, if this reason code is used an associated Problem ticket(s) must be attached to the RFC)
6) Urgent Customer Request (*Note, if this reason code is used an associated Service Request or e-mail from the customer must be
attached to the RFC)
General guidelines when submitting an Emergency change:
o Contact the Change Management Team (CMT) at 562-940-0614 when submitting any Emergency RFC to Change Management
which has a planned implementation start date/time within the next 48 hours
o Emergency RFCs submitted to fix an Incident requires a related SMS Incident ticket
Note: When restoring service for a break/fix incident requiring immediate response, the team may enter the RFC after the fact and
relate/attach the existing incident ticket. This is considered an Emergency Latent RFC and uses the reason code Resolve
Incident
o Emergency RFCs submitted to fix a Problem requires a related SMS Problem ticket
o Emergency RFCs submitted to fulfil an Urgent Customer Request require a related/attached Service Request from the customer
(SMS, RTII, EMS, or Customer e-mail) indicating the justification for the Emergency RFC
o Service Lead & Division Managers approval must be obtained by the Change Implementer within 24 hours of submitting the
Emergency. The Change Implementer has responsibility and accountability at the time the Emergency RFC is submitted to obtain
approvals from their Management. Please contact the Change Management Team (CMT) at 562-940-0614 when you know that
Service Lead and Division Manager approvals have been obtained
o Emergency changes must not be implemented unless you have received the required approvals and they have been documented
within SMS. You are approved to implement your change when the RFC status is changed in SMS to Scheduled
Page 8 of 12
 The process flow for Emergency Changes can be found on page 3 of this document
An Emergency change is not to be used as a result of:
o Poor planning
o The desire of a Change Owner to perform a change outside the approved change window (e.g. when it became convenient)

Emergency Latent Change

An Emergency Latent Change is specifically intended for changes that occur to restore Services during a P1 or P2 incident. In this
situation, a critical Service is down and a fix must be applied immediately to restore Service. The Emergency Latent Change is
drafted after the fact as a record of the change events that occurred during the Service restoration period
An Emergency Latent change uses the Emergency RFC category
Emergency Latent Changes submitted to fix an Incident requires a related SMS Incident ticket. Only the reason code of Resolve an Incident
should be used for an Emergency Latent Change
o Latent (after the fact) changes are to only be used for recording the operational change in cases where the RFC owner was unable to
document the change prior to implementation
o Latent RFCs are required to be drafted in the Change Management System within 48 hours after the implementation of the change
Emergency Latent RFCs do not require a Peer Review, Service Lead approval, or ECCB approval.
Emergency Latent RFCs do require that the implementer perform a Post Implementation Review (PIR) within the PIR tab of the change ticket

Standard Change
A Standard RFC uses a preauthorized change model for a planned operational change to an IT Service, IT asset, infrastructure or
configuration item(s), which carries a low to no level of Risk and Impact, is well understood and has an accepted and established Standard
Operating Procedure (SOP), that addresses a specific change requirement, and the approach is pre-authorized by the CCB and CAD-CMT
Standard changes have a fixed list of requirements to ensure the requested change involves inconsequential or no identified risk. These
requirements must include all specifications listed below:
o The change has proven to be fail-safe through successfully documented implementation at least once in the same environment
using the Low Risk Normal RFC lifecycle
o A Standard Model for the change has been approved and activated through vetting by the CCB, Change Manager, and CAD-CMT
o No service outage is necessary, or a minor outage is pre-authorized by the customer(s) and applicable ITS management staff, and/or
occurs in a pre-defined maintenance window
o Emergency Latent RFCs do not require a Peer Review, Service Lead approval, or CCB approval

Page 9 of 12
 o Customer approval(s) are not required to be obtained by CAD-CMT
o Customer notification(s) are not required to be facilitated by the CAD-CMT (CACNOTIFY e-mails)
o There is no risk or the risk is low, well understood, and documented in detail
A Standard change model, once created, cannot be modified or utilized to accommodate a variation, including the steps to carry out
the change.
Standard change models which are misused or result in a failed change and/or Incident(s), shall be suspended at the discretion of CAD-CMT,
the CCB, and/or ITS Management
A standard change model that has been suspended from use is eligible for re-instatement after again meeting the fixed list of requirements
and approved by the CCB
Misuse is considered to be a willful action by the owner involving improper, incorrect use, or misapplication of the standard change model as
defined below, but not limited to:
o Used for other than the approved activity whether it is related to Change, Incident, or Service Request, etc.
o Application of a change beyond the scope of the established change model
o Used to bypass established Change Management Process and Procedures
Additional information on the creation and lifecycle of Standard RFCs can be located at this document

3 RFC Lead Time Requirements

The Customer Assistance Division Change Management Team (CAD-CMT) maintains the oversight of all RFCs. The lead times described
below are based on requirements obtained by input from ITS customers, management and experience
The purpose of established lead-times is to allow sufficient time for communication to relevant parties, coordination with appropriate support
teams/customers, and appropriate review by Change Control Board(s) (CCBs). Changes submitted outside the established lead-time
requirements will be rejected and need to be rescheduled
RFCs will be handled and processed based on categorization and priority. Qualifiers such as Urgent, Emergency, etc., that are
placed in the title of the RFC by the Change Owner will be disregarded as an indicator of an RFCs priority
The Service Management System (SMS) - Change Management module is setup for support groups to submit an RFC at the beginning of the
Change Life Cycle
An RFC should be drafted (entered into the system) and registered as soon as a support group is aware that a change needs to take place
Sufficient time must be allowed for the change to progress properly through the process, allowing sufficient time for acceptance, peer review,
approval and notification(s) to be sent to customers, (via the CACNOTIFY e-mail account), so that customers and ITS subject matter experts
have ample time to review the RFC, assess risk and have time to make any needed accommodations.
The following timelines apply to the RFCs based on categories and must meet these requirements or be granted an exception by CAD-CMT

Page 10 of 12
 All RFCs must adhere to the following lead time requirements applicable to the associated category.

RFC Lead Times Table

Note: Normal RFCs must meet these lead time guidelines.

RFCs that do not meet established lead times or those that do not follow the Emergency Change
guidelines will be Denied at the discretion of CAD-CMT.

RFC Type / Category Lead Time

A Normal Low Risk RFC must be registered at least five (5) calendar
Normal Low Risk
days in advance of the planned start date/time.

Normal Medium Risk A Normal - Medium risk RFC requires a lead time of anywhere between 8
to 13 days depending on when the RFC is drafted vs. the next available
CCB

Normal High Risk A Normal High risk RFC requires a lead time of anywhere between 8 to
13 days depending on when the RFC is drafted vs. the next available CCB

Standard No lead time necessary and/or as set by the implementing groups OLA.

Emergency Four hours or more depending on urgency and reason

4 RFC Approvals
Evidence of RFC approval is obtained by:
o Reviewing the RFCs approval log within the Change Management System to ensure all approvals have been granted
o The RFC being placed in the phase status of Scheduled by the Change Manager (CAD-CMT).
o The Change Owner receiving an e-mail from SMSNotification@isd.lacounty.gov stating the change has been approved for
deployment
The Change Owner is assigned the primary responsibility for ensuring their RFC is moving through the approval process and
interaction with approvers to guarantee approvals are completed in a timely manner.

Page 11 of 12
Page 12 of 12