PL-12_HHS System Change Management Process.docx

HHS System Change Management

HHS System Change Management Process Version 3.4

Contents

1 Introduction

1.1 Purpose

The purpose of the change management process is to control the lifecycle of all changes within the agreed upon scope and to enable beneficial changes to be made with minimal disruption to IT Services.

Definition of a Change: A Change is the addition, modification, or removal of anything that could have an effect on IT services.

1.2 Objectives

The objectives of change management are to:

· Respond to the customer's changing business requirements while maximizing value and reducing incidents, disruption, and re-work.

· Respond to Program and IT requests for change that align the service with the Program needs.

· Ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented, and reviewed in a controlled manner.

· Ensure that all changes to configuration items (CIs) are recorded in the configuration management database. This repository contains relevant information about all significant assets, their configurations, and service dependencies to other CIs. (Future objective)

· Mitigate overall business risk.

1.3 Scope

This document describes the process for managing and controlling all changes to the production environment in the HHS System.

For the purposes of this document, a change will include the addition, modification to or removal of:

· Hardware

· Device drivers

· Firmware

· Middleware

· Operating System

· Application or Database software

· Network configurations

· Network infrastructure

· Facilities (e.g., electrical, UPS)

· Access infrastructure (e.g., Active Directory, DNS, etc.)

Examples:

· A network engineer needs to replace end of life network hardware with newer-generation hardware with improved functionality.

· A support technician needs to apply the monthly Microsoft patches or perform other monthly maintenance.

· Upgrading to the latest version of Microsoft Office, SharePoint, or Outlook.

· A support technician needs to replace a defective router or switch in a network segment.

· A security manager requesting a configuration and documentation change in response to a newly discovered vulnerability. (e.g., blocking attachments with an .exe or .scr extension)

· Change requests may also be made proactively or as a result of activities in Incident, Problem, or many other Service Management processes.

1.4 Change Management Process Requirements

In order for Change Management to be effective, there are requirements the system should adhere to while doing business as usual and a Change Management Policy that should be followed at all times. This includes the following:

· All requests for change (RFC) must be recorded in the Remedy tool (ITSM system) as a change request (CRQ record).

· All changes must be authorized by the proper level of authority before they are implemented.

· All changes that impact or modify a configuration item come within the scope of the Change Management process.

· All RFCs will be assessed for risk, impact, and urgency.

· All RFCs, except for Standard changes, require successful completion of pre-implementation testing. In those cases where there is no test environment, post-implementation testing and validation must be performed in lieu of pre-implementation testing.

· All RFCs, except for emergency and expedited Changes must be submitted in time for proper assessment and CAB review prior to authorization and implementation of the change.

· All emergency change requests must be filled out and submitted within 24 hours following the implementation of the emergency change.

· All changes that have been pre-approved as Standard changes may not be reviewed during the weekly CAB meeting. A summary of these changes will be provided as informational/advisory only to the CAB.

1.5 Change Management Roles

In Change Management, there are some important roles with certain responsibilities that must be performed in order for Change Management to be successful. They are as follows:

The HHSC CAB consists of members from various Service Delivery and Operational Support areas, as well as Security, from within HHSC only.

1.6 Change Classifications

Changes as defined in Change Management fall into one of the following classifications or classes. The definition for each is found below:

· In response to business or user demands

· To fix faults (Incidents or Problems)

· To upgrade a system (for example, a new release of software or hardware upgrade)

· To introduce new (or remove old) CIs.

Normal Changes are planned well in advance of implementation and proceed in an orderly fashion through each of the Change Management process stages, including CAB review and approval.

· Upgrading the firmware on a server or network switch

· Power source changes to network equipment

· Adding, replacing or decommissioning a server

· Changes would proactively prevent a Major Incident or outage

· Changes are deemed critical to the Program by the customer and need to be in place earlier than previously agreed lead-times.

· In order to mitigate an actual or potential incident or outage

· An issue is discovered during testing

· An unforeseen change in support of a critical project

· A time-sensitive change in support of governmental regulations or legal requirements

· Critical security patching

· Expedited by the Agency due to a legitimate risk to the Agency's Program if the change is not performed.

All expedited changes require Service Owner approval. All Normal Change process steps should be followed when conducting an Expedited Change. All associated activities, outputs, and approvals are required with an Expedited Change, including full CAB approval.

· Correcting a significant application defect that is affecting customers and can't wait until the next scheduled release.

· Blocking certain email attachments due to a potential security threat

· Out of band server patching for a critical vulnerability

· Blocking certain email attachments due to a realized and ongoing security threat

A change model will be followed for each standard change to ensure consistency of approach.

· Monthly security patching for servers and PCs.

· Upgrading routers at regional offices.

· Installing a UPS at a regional office.

2 Process Description

2.1 The Change Management Lifecycle

Change Management has defined stages in its lifecycle as the request for change moves through the Change Process.

Process stages include:

· Change Initiation and Recording

· Who raised the need for the change?

· What is the reason for the change?

· What is the return or value required from the change?

· Change Review and Authorization (Approval to Proceed)

· What are the risks involved in the change?

· What is the service impact of the change? (e.g. who will be affected and for how long?)

· Change Planning and Scheduling (Approval to Implement)

· What resources are required to deliver the change?

· Who is responsible for the build, test and implementation of the change?

· What is the relationship between this change and other changes?

· When will the change occur and how long is the change window?

· What is the documented back-out and remediation plan in case the change is unsuccessful?

· What are the triggers for the back-out plan?

· How can we ensure the back-out plan can be completed within the change window?

· Change Implementation

· What is the actual work being performed and who will perform it?

· Change Completion and Closure

· Was the change successful? If not, why not?

· Should a Post Implementation Review (PIR) be scheduled to improve on future changes of this type?

· Did we get the benefits we expected?

The change management process outlines each of the stages above and includes a continuous improvement element at the end. Each stage is broken into a number of activities that are comprised of detailed tasks.

A graphical overview of the lifecycle stages for the Change Management process is outlined in the flowchart below:

3 Change Management Process Normal Change Normal Changes are the most common changes managed by the Change Management process. They require full assessment and authorization including CAB Approval.

3.1 Change Initiation and Recording

This procedure provides details for the activities needed to create and log a Request for Change (RFC) once the need for a change has been identified. It covers the activities needed to complete the initial recording of impact, urgency and priority assessment as well as the Classification of the Change.

· An RFC is recorded in a Remedy CRQ record by the Change Coordinator. The RFC is based on a program or technical need.

· Any reactive change as part of incident resolution should follow the Change Management process and must be recorded in Remedy by the Change Coordinator.

It is essential that a thorough approach be undertaken during the assessment of risk and business continuity, impact, resource requirements, and change approval. This is necessary in order to maintain a proper balance between the need for change and the potential negative impact of change.

Procedural Steps

1. Gather change information and open a CRQ. For step by step procedures, use this document.

a. The Change Coordinator gathers all change information and supporting documentation required to open an RFC. This usually involves working closely with the requester and other technical support teams.

b. The Change Coordinator should collect as much information as needed to fully support a successful change.

2. Complete Initial Recording of the RFC

a. Choose the Coordinator Group and Coordinator. This defaults to the person opening the CRQ.

b. The Change Location should reflect the physical location where the change will take place. This defaults to the physical location of the Change Coordinator.

c. In the template field, enter HHS and a list of templates will appear. Select the correct template based on the classification of the change and agency impact.

d. Enter a short Summary for this request that provides a description of the requested change. This field is limited to 100 characters.

e. Complete the required information in the Notes field provided by the template (e.g. Change Description, Business Justification, Risk Assessment, Service Impact Assessment, Build Plan, Implementation Plan, Test Plans (pre-implementation and post-implementation), Back-out Plan, and Communication Plan. For a complete definition of each required entry, see Appendix B.

f. Enter any attachments in the Work Detail section.

g. Choose the appropriate Manager Group (i.e. Enterprise Change Management) and Change Manager.

3. Assess Change Class, Impact, Urgency and Risk Level

a. The Change Coordinator then populates the Class of change, Change Reason, the Impact, Urgency, and Risk Level fields in the CRQ accordingly. To assess risk level, go to Appendix C and use the risk matrix to decide on the proper risk level.

4. Add Requester Information

a. Enter the name of the person who requested the change. Select "Requested For" from the left pane under Quick Actions. Requester information can only be modified during this initial stage of the request.

5. Add Classification Information

a. Operational and Product categories should be added at this point. Select the Categorization tab.

b. Complete all Operational and Product category tiers. Tier1 of the Operational Categories (Change) has been provided by the template. Complete Tier 2 and 3 for both categories.

c. Choose the product name.

6. Relate Other Remedy Records or CIs

a. On the Relationships Tab, relate any incidents, problems, work orders, or other change requests that are associated with this change. For instance, if this change is designed to resolve an incident, relate the incident number. If this is a Standard change, relate the original approved CRQ to this new one. To review the Standard Change Log use either the ECM Standard Change Log or the HHSC Standard Change Log to find the correct CRQ.

b. The Change Coordinator should relate all CIs that will be affected by this change. (Note: This will be a requirement once a CMDB is established)

7. Schedule the Change

a. On the Date/System tab, enter the scheduled start and end dates and times.

b. The change window should be wide enough to include any back-out time if a reversal of the change is necessary.

8. Technical Peer Review

a. A technical peer will be required to review the CRQ for accuracy and completeness. After the review, the peer should create a work detail entry stating they have reviewed it.

9. Manager Review

a. The Change Coordinator’s manager will be required to review and approve the CRQ. The manager should create a work detail entry stating they approve the CRQ.

10. Submit Change

a. The Change Coordinator submits the request to the Change Manager by selecting the "Next Stage" button at the bottom of the CRQ.

b. Once selected, the status should change from "Draft" to "Planning in Progress".

c. The deadline for submitting changes is 2:00 pm on Monday.

3.2 Change Review and Authorization (Approval to Proceed)

This phase ensures the CRQ has been documented appropriately and impact/risk has been properly evaluated. In addition, it ensures the overall Implementation Plan has been reviewed and includes the appropriate level of detail for the change.

Procedural Steps

1. Confirm Classification:

a. The Change Manager reviews the change and corrects the classification if necessary. (See Section 1.6 for change classifications)

2. Review Change and Contingency Plans

a. The Change Manager reviews the Notes field to ensure all required information is included and adequate for the level of risk reflected in the change. (See Appendix B for what information is required in the Notes field.)

3. Risk Assessment/Service Impact Assessment

a. The Change Manager reviews the risk and service impact assessments to identify if any additional steps or information is needed to manage risk or convey the expected impact. The Change Manager then works with the Change Coordinator to include these in the CRQ.

b. The Change Manager reviews the suggested date and time for the change. Depending on the expected impact or other conflicting changes, the Change Manager may require an alternative date/time.

c. The Change Manager may decide to cancel or postpone the change for various reasons. If this is done, the CRQ is updated with the reason and returned to the Change Coordinator who informs the Change Requester.

3.3 Change Planning and Scheduling (Approval to Implement)

In this stage, the Change Coordinator prepares to present the proposed change to the CAB during the next scheduled CAB meeting.

Procedural Steps

1. Prepare for CAB Review

a. If all documentation supporting the change has been included, the Change Manager will change the status to "Scheduled for Approval" and prepare the CRQ for the next CAB meeting.

b. The Change Coordinator or other person knowledgeable of the change must present the change to the CAB and answer any questions concerning the change that may be asked.

c. If approved by the CAB, the Change Manager moves the CRQ to the "Scheduled" stage.

d. If the change is rejected, the RFC is returned to the Change Coordinator for updating the record with the reason(s) and the Change Requester is informed. The status of the RFC is then changed to "Cancelled".

e. If the CAB requests additional information before giving their approval, the Change Coordinator updates the change record and takes steps to gather the additional information. Once the additional information is received, a vote by email for approval is initiated by the Change Manager.

3.4 Change Implementation

During this stage, the Change Implementer and any other technical support teams involved with the change, perform the work that was approved in the Change Plan and authorized by the CAB within the approved Change window.

1. Implementation Activity

a. The Change Coordinator provides the Change Implementer and other technical support teams if needed, with the implementation tasks and plans.

b. The Change Coordinator also oversees the activities and updates the change record once the implementation tasks have been completed.

c. When all implementation tasks are complete, the Change Implementer ensures post-implementation testing has occurred to validate all services are operating as expected.

d. Following post-implementation testing and validation, the Change Implementer documents if the change was successful, successful with issues, or unsuccessful by entering a Work Detail entry.

i. If the change was successful, the Change Coordinator updates the CRQ accordingly.

ii. If the change was successful with issues, the Change Coordinator updates the CRQ and lists any issues that were identified.

iii. If the change was unsuccessful, the Change Implementer performs the back-out plan to restore everything as it was before the change was undertaken, validates all services are available, then updates the CRQ accordingly. Reasons why the change failed should be documented in the CRQ.

e. In all cases, the Change Coordinator ensures the change record is updated with the final disposition of the change.

3.5 Change Completion and Closure

After a change is completed, the Change Coordinator ensures all follow-up actions are performed by those assigned and responsible for the actions. The status of the CRQ is then changed to "Completed".

1. Post Implementation Review

a. If the outcome of a change is questionable, a Post Implementation Review (PIR) might be requested.

b. A PIR can be used to determine if the change met the objectives of the Change Requester along with determining if the expected value of the change was delivered.

c. A PIR is also valuable for a change that failed and was backed out to learn valuable lessons and improvement opportunities for similar changes requested in the future.

d. Scheduling a PIR will be the responsibility of the Change Manager. A PIR can be requested by anyone involved with the Change Management process.

2. Review of the Change Record

a. The Change Manager reviews the change record for completeness.

b. The Change Manager determines if there are any lessons learned that can help increase the likelihood of successful changes of a similar type in the future. These improvements can be made to any stage of the Change Lifecycle.

3. Record Closure

a. Once all follow-up actions have been performed, the CRQ will be closed by the Change Manager 7 days following the completed date. This delay allows for updates to be made to the CRQ if necessary. Once closed, no updates or modifications can be made to a Remedy CRQ.

3.6 Graphical Overview of a Normal Change

Emergency Change

3.7 Change Initiation and Recording

When an incident is reported due to a break-fix situation and a service is experiencing an outage or is severely impacted, there may be a need to initiate an Emergency Change prior to recording a CRQ record in the system. Following the Emergency Change and service restoration, a CRQ must be created within 24 hours of the change with all the same required information as a Normal change. (Note: If an active Cyber Threat is occurring, please see Appendix H.)

The accepted notification process should be followed when a high priority or critical incident occurs that is service impacting. This will include a distributed communication to the affected agencies and is drafted in a standard format by the Service Owner or delegate with assistance from the Team Operations Coordinator and approved by the Service Owner's Director.

3.8 Change Review and Authorization (Approval to Proceed)

Procedural Steps

1. Creating an Emergency Change Plan

a. The Change Coordinator creates an emergency change plan to address the issue. The Change Coordinator will collaborate with the Service Delivery team as needed to acquire the necessary technical expertise required for remediation.

b. If at all possible, the solution should be tested prior to implementation into the production environment.

c. Due to the nature of an emergency change, pre-implementation testing cannot always be achieved so much rigor must be placed on the post-implementation testing. A complete and detailed back-out plan needs to be incorporated in the change plan in the event the change is unsuccessful.

d. After the Change Coordinator develops the emergency change plan and documents it in the emergency email template, the Change Coordinator will send the completed template to the Service Owner for approval. Once approved, the Change Coordinator will then send to the Change Manager. The Change Manager will first review it to ensure all required information is included and then send it to the CAB for approval via email.

The email template must include all the following information:

· A high level description of the change along with the name of the agency requesting it.

· Why is this considered an emergency change? Why can’t it wait for the regularly scheduled CAB meeting?

· A Remedy Incident number is required.

· Provide low level details around the change along with the name of the agency that will actually perform the change.

· The risk level of the change and why the risk level was chosen.

· The impact of the change and which agencies will be impacted.

· The scheduled start and end date/time of the change.

e. An emergency CRQ must be created within 24 hours of implementation to record the change.

f. Note: All emergency changes must be authorized by the Service Owner before implementation.

3.9 Change Planning and Scheduling (Approval to Implement)

1. Emergency Change Advisory Board (ECAB)

a. The ECAB will consist of the following individuals:

· System Services Director (for Critical priority issues)

· Executive Management Team representing each agency (for Critical priority issues)

· Regular approving CAB members (for all other priority issues)

· Change Manager

· Others as required by the severity of the issue, up to and including the CIO.

b. The System Services Director and Executive Team will provide the approval for emergency changes (Critical priority incidents) and offer guidance around the change window. Regular approving CAB members will provide approval for all other priorities. The approval for the change will be made either verbally or via email, along with any additional requirements involving the change such as a revised change window.

c. The Change Manager communicates the approval to move forward with the change via email to the CAB distribution list and informs the Change Coordinator of any revised schedule requested by the ECAB.

Emergency Changes Not Requiring CAB Approval Emergency Changes may be performed without CAB approval if all (3) of the following conditions are met:

1. The equipment or service is already down or severely degraded, there is no additional service disruption expected while repairing or implementing the emergency change, or a cybersecurity threat is actively occurring.

2. Verbal approval by the Service Owner of the affected system or by the CISO in the event of a cybersecurity attack has been provided with written approval to follow.

3. An Incident ticket exists in Remedy recording the event. If after hours and the technician doesn't have access to Remedy, a voicemail left for the Service Desk reporting the event and requesting a ticket be opened will be sufficient.

Notification of the emergency change will still be sent to the CAB distribution list after the change has been implemented but no vote will be required.

Emergency Changes Requiring CAB Approval

ECM CAB Approval before implementing an Emergency Change is required if any of the (3) conditions listed above are not met or if the change needed for remediation will negatively impact an agency.

Approval Process When seeking CAB approval, an email notification requesting a vote for approval will be sent by the Change Manager to the CAB distribution list. CAB approvers will have 30 minutes to respond via email. If no response is received, the Change Manager will attempt to reach the primary and alternate approvers by text or voice. If there is no contact made, the Change Manager will escalate to his or her Director who attempts to contact the Approver's Director.

Note: Following the implementation of any Emergency Change, a CRQ must be created in Remedy within 24 hours of the change.

3.10 Change Implementation

During this stage, the Change Implementer and any other technical support teams involved with the change, perform the work that was approved in the Change Plan and authorized by the CAB within the approved Change window.

1. Implementation Activity

a. The Change Coordinator provides the Change Implementer and other technical support teams, if needed, with the implementation tasks and plans.

b. The Change Coordinator oversees the activities and updates the change record once the implementation tasks have been completed.

c. When all implementation tasks are complete, the Change Implementer ensures post-implementation testing has occurred to validate all services are operating as expected.

d. Following post-implementation testing and validation, the Change Implementer documents if the change was successful, successful with issues, or unsuccessful by entering a Work Detail entry.

i. If the change was successful, the Change Coordinator updates the CRQ accordingly.

ii. If the change was successful with issues, the Change Coordinator updates the CRQ and lists any issues that were identified.

iii. If the change was unsuccessful, the Change Implementer performs the back-out plan to restore everything as it was before the change was undertaken, validates all services are available, then updates the CRQ accordingly. Reasons why the change failed should be included.

e. In all cases, the Change Coordinator ensures the change record is updated with the final disposition of the change.

3.11 Change Completion and Closure

After a change is completed, the Change Coordinator ensures any follow-up actions are performed by those assigned and responsible.

If not already created, the Change Coordinator creates a CRQ in Remedy and documents all relevant information that is required in a Normal change. The status of the CRQ is then changed to "Completed".

1. Post Implementation Review

a. If the outcome of a change is questionable, a Post Implementation Review (PIR) might be requested.

b. A PIR can be used to determine if the change met the objectives of the Change Requester along with determining if the expected value of the change was delivered.

c. A PIR is also valuable for a change that failed and was backed out to learn any valuable lessons and improvement opportunities for similar changes requested in the future.

d. Scheduling a PIR will be the responsibility of the Change Manager. A PIR can be requested by anyone involved with the Change Management process.

2. Review of the Change Record

a. The Change Manager reviews the change record for completeness.

b. The Change Manager determines if there are any lessons learned that can help increase the likelihood of successful changes of a similar type in the future. These improvements can be made to any stage of the Change Lifecycle.

3. Record Closure

a. Once all follow-up actions have been performed, the CRQ will be closed by the Change Manager 7 days following the completed date. This delay in closing is in the event updates need to be made to the change. Once closed, no updates or modifications can be made to a Remedy CRQ.

3.12 Graphical Overview of an Emergency Change

Expedited Change

3.13 Change Initiation and Recording

Procedural Steps If an urgent, non-emergency change is needed before the next scheduled Change Advisory Board meeting, an Expedited Change must be requested. Expedited changes require a detailed Business Justification that must be included in the CRQ. An expedited email template must be completed with the following information:

· A high level description of the change along with the name of the agency requesting it.

· Why it is being considered an expedited change? Why can’t it wait for the regularly scheduled CAB meeting?

· Provide the Remedy Incident number if applicable.

· Provide low level details around the change along with the name of the agency that will actually perform the change.

· The risk level of the change and why the risk level was chosen.

· The impact of the change and which agencies will be impacted.

· The scheduled start and end date/time of the change.

Change coordinators must receive approval from the Service Owner before it will be considered for submission to the CAB for approval. Any expedited changes that do not meet these requirements will be postponed until the next scheduled CAB meeting.

1. Gather change information and open a CRQ:

a. The Change Coordinator gathers all change information and supporting documentation required to open an RFC. This usually involves working closely with the requester and other technical support teams.

b. The Change Coordinator should collect as much information as needed to fully support a successful change.

2. Complete Initial Recording of the RFC

a. Choose the Coordinator Group and Coordinator. This defaults to the person opening the CRQ.

b. The Change Location should reflect the physical location where the change will take place. This defaults to the physical location of the Change Coordinator.

c. In the template field, enter HHS and a list of templates will appear. Select the correct template based on the classification of the change and agency impact.

d. Enter a short Summary for this request that provides a description of the requested change. This field is limited to 100 characters.

e. Complete the required information in the Notes field provided by the template (e.g. Change Description, Business Justification, Risk Assessment, Service Impact Assessment, Build Plan, Implementation Plan, Test Plans (pre-implementation and post-implementation), Back-out Plan, and Communication Plan. For a complete definition of each required entry, see Appendix B.

f. Enter any attachments in the Work Detail section.

g. Choose the appropriate Manager Group (i.e. Enterprise Change Management) and Change Manager.

3. Assess Change Class, Impact, Urgency and Risk Level

a. The Change Coordinator then populates the Class of change, Change Reason, the Impact, Urgency, and Risk Level fields in the CRQ accordingly. To assess risk level, go to Appendix C and use the risk matrix to decide on the proper risk level.

4. Add Requester Information

a. Enter the name of the person who requested the change. Select "Requested For" from the left pane under Quick Actions. Requester information can only be modified during this Initiate stage of the request.

5. Add Classification Information

a. Operational and Product categories should be added at this point. Select the Categorization tab.

b. Complete all Operational and Product category tiers. Tier1 of the Operational Categories (Change) has been provided by the template. Complete Tier 2 and 3 for both categories.

c. Choose the product name.

6. Relate Other Remedy Records or CIs

a. On the Relationships Tab, relate any incidents, problems, work orders, or other change requests that are associated with this change. For instance, if this change is designed to resolve an incident, relate the incident number.

b. The Change Coordinator should relate all CIs that will be affected by this change. (Note: This will be a requirement once a CMDB is established)

7. Schedule the Change

a. On the Date/System tab, enter the scheduled start and end dates and times.

b. The change window should be wide enough to include any back-out time if a reversal of the change is necessary.

8. Technical Peer Review

a. A technical peer will be required to review the CRQ for accuracy and completeness. After the review, the peer should create a work detail entry stating they have reviewed it.

9. Manager Review

a. The Change Coordinator’s manager will be required to review and approve the CRQ. The manager should create a work detail entry stating they approve the CRQ.

10. Submit Change

a. The Change Coordinator submits the request to the Change Manager by selecting the "Next Stage" button at the bottom of the CRQ.

b. The status should now change from "Draft" to "Planning in Progress".

3.14 Change Review and Authorization (Approval to Proceed)

This phase ensures the RFC has been documented appropriately and impact/risk has been properly evaluated. In addition, it ensures the overall Change Plan has been reviewed and includes the appropriate level of detail for build, test, implementation, back-out and communication based on the level of impact and risk.

Procedural Steps

1. Confirm Classification:

a. The Change Manager reviews the change and corrects the classification if necessary. (See Section 1.6 for change classifications)

2. Review Change and Contingency Plans

a. The Change Manager reviews the Notes field to ensure all required information is included and adequate for the level of risk reflected in the change. (See Appendix B for what information is required in the Notes field.)

3. Risk Assessment/Service Impact Assessment

a. The Change Manager reviews the risk and service impact assessments to identify if any additional steps or information is needed to manage risk or convey the expected impact. The Change Manager then works with the Change Coordinator to include these in the CRQ.

b. The Change Manager reviews the suggested date and time for the change. Depending on the expected impact or other conflicting changes, the Change Manager may require an alternative date/time.

c. The Change Manager may decide to cancel or postpone the change for various reasons. If this is done, the CRQ is updated with the reason and returned to the Change Coordinator who informs the Change Requester.

3.15 Change Planning and Scheduling (Approval to Implement)

In this stage, the Change Coordinator determines the detailed tasks involved in the change and the amount of time required to complete each task. If the total time to complete the change has been altered, the scheduled start and end times should be adjusted accordingly.

Procedural Steps

1. Prepare for CAB Review and Approval

a. Since Expedited changes fall outside the cycle of the regularly scheduled CAB meeting, approval and review of the change by the CAB will occur by email.

b. If approved by the CAB, the Change Manager moves the CRQ to the "Scheduled" stage.

c. If the change is rejected, the RFC is returned to the Change Coordinator for updating the record with the reason(s) for rejection and the Change Requester is informed. The status of the RFC is changed to "Cancelled".

d. If the CAB requests additional information before giving their approval, the Change Coordinator updates the change record and takes steps to gather the additional information. Once the additional information is received, a vote by email for approval is conducted.

3.16 Change Implementation

During this stage, the Change Implementer and any other technical support teams involved with the change, perform the work that was approved in the Change Plan and authorized by the CAB within the approved Change window.

1. Implementation Activity

a. The Change Coordinator provides the Change Implementer and other technical support teams if needed, with the implementation tasks and plans.

b. The Change Coordinator also oversees the activities and updates the change record once the implementation tasks have been completed.

c. When all implementation tasks are complete, the Change Implementer ensures post-implementation testing has occurred to validate all services are operating as expected.

d. Following post-implementation testing and validation, the Change Implementer documents if the change was successful, successful with issues, or unsuccessful by entering a Work Detail entry.

i. If the change was successful, the Change Coordinator updates the CRQ accordingly.

ii. If the change was successful with issues, the Change Coordinator updates the CRQ and lists any issues that were identified.

iii. If the change was unsuccessful, the Change Implementer performs the back-out plan to restore everything as it was before the change was undertaken, validates all services are available, then updates the CRQ accordingly. Reasons why the change failed should be included.

e. The Change Coordinator updates the change record with the final disposition of the change.

3.17 Change Completion and Closure

After a change is completed, the Change Coordinator ensures all follow-up actions are performed by those assigned and responsible for the actions.

1. Post Implementation Review

a. If the outcome of a change is questionable, a Post Implementation Review (PIR) might be requested.

b. A PIR can be used to determine if the change met the objectives of the Change Requester along with determining if the expected value of the change was delivered.

c. A PIR is also valuable for a change that failed and was backed out to learn any valuable lessons and improvement opportunities for similar changes requested in the future.

d. Scheduling a PIR will be the responsibility of the Change Manager. A PIR can be requested by anyone involved with the Change Management process.

2. Review of the Change Record

a. The Change Manager reviews the change record for completeness.

b. The Change Manager determines if there are any lessons learned that can help increase the likelihood of successful changes of a similar type in the future. These improvements can be made to any stage of the Change Lifecycle.

a. Once all follow-up actions have been performed, the CRQ will be closed by the Change Manager 7 days following the completed date. This delay in closing is in the event updates need to be made to the change. Once closed, no updates or modifications can be made to a Remedy CRQ.

3.18 Graphical Overview of an Expedited Change

Standard Change Standard changes are pre-authorized by Change Management due to known levels of low risk involving the change, the fact that similar changes have been done successfully in the past and Standard Changes follow a Change Model to insure the consistency of approach. These changes are made to infrastructure or services and their outcomes are well known.

Once a change has been approved by the CAB to become a Standard change, similar changes in the future still require a CRQ but all required information will not be necessary if the change is related to the original approved Standard change.

Standard changes expire one year after approval and must be re-approved by the CAB to continue as a Standard change.

3.19 Change Initiation and Recording

This procedure provides details for the activities needed to create and log a Request for Change (RFC) once the need for change has been identified.

Procedural Steps

1. Gather change information and open an RFC:

a. The Change Coordinator gathers all change information and supporting documentation required to open an RFC. This may involve working closely with the requester and technical support teams.

2. Complete Initial Recording of the RFC

a. Choose the Coordinator Group and Coordinator.

b. Enter a short Summary for this request that captures at a high level, what is being changed.

c. Enter details in the Work Detail section. For a comprehensive list of what should be included in the Work Detail section, see Appendix B.

d. Choose the appropriate Change Manager.

3. Assess Change Class, Impact, Urgency and Risk Level

a. Choose "Normal" for the change class. Once approved by the CAB to become a standard change, the Change Manager will change the class to "Standard".

b. The Change Coordinator will then populate the Change Reason, Impact, Urgency, and Risk Level fields in the CRQ accordingly.

4. Add Requester Information

a. Enter the name of the person who requested the change. Select "Requested For" from the left pane under Quick Actions. Requester information can only be modified during this initial stage of the request.

5. Add Classification Information

a. Operational and Product categories should be added at this point. Select the Categorization tab.

b. Complete all Operation and Product category tiers.

c. Choose the product name.

6. Relate Affected CIs

a. On the Relationships Tab, relate any incidents, problems, work orders, or other change requests that are associated with this change. For instance, if this change is designed to resolve an incident, relate the incident number. (Note: Once a change has been approved to become a Standard change, all future CRQs must have the original Standard CRQ related to it.)

b. The Change Coordinator should relate all CIs that will be affected by this change. (Note: This will be required once a CMDB is established)

7. Schedule the Change

a. On the Date/System tab, enter the scheduled start and end dates and times.

8. Submit Change

a. The Change Coordinator then submits the request to the Change Manager.

3.20 Change Review and Authorization (Approval to Proceed)

This phase ensures the RFC has been documented appropriately for a Standard Change.

Procedural Steps

1. Confirm Classification:

a. The Change Manager reviews the change and ensures the change is indeed an accepted Standard Change and that it is documented correctly.

b. The Change Manager also reviews the Summary and Notes section of the change to make sure it documented appropriately. See Appendix B for what is expected in the Notes section.

2. Risk Assessment

a. The Change Manager may decide to cancel or postpone the change if there appears to be a conflict with another higher priority change. If this is done, the RFC is updated with the reason and returned to the Change Coordinator who informs the Change Requester.

3.21 Change Planning and Scheduling (Approval to Implement)

In this stage, the Change Coordinator determines the detailed tasks involved in the change and the amount of time required to complete each task.

Procedural Steps

1. Validate Change Information:

a. The Change Coordinator reviews the change information for accuracy.

2. Task Assignment

a. The change is formally passed to the Service Delivery team and other technical teams involved in performing the change. This is done by assigning tasks within the CRQ for the work efforts required for the change.

b. The Change Coordinator checks the availability of required resources and their ability to meet the desired implementation date.

3. Testing Activity Progress

a. Since this is a Standard Change, the test plan is repeatable and has already been documented and approved from previous changes.

3.22 Change Implementation

During this stage, the Change Implementer and other technical support teams (if needed), perform the work that was approved in the Standard Change.

1. Implementation Activity

a. The Change Coordinator provides the Change Implementer and other technical support teams if needed, with the implementation tasks and plans.

b. The Change Coordinator also oversees the activities and updates the change record once the implementation tasks have been completed.

c. When all implementation tasks are complete, the Change Implementer ensures post-implementation testing has occurred to validate all services are operating as expected.

d. Following post-implementation testing and validation, the Change Implementer documents if the change was successful, successful with issues, or unsuccessful by entering a Work Detail entry.

i. If the change was successful, the Change Coordinator updates the CRQ accordingly.

ii. If the change was successful with issues, the Change Coordinator updates the CRQ and lists any issues that were…