ESBD_365998_1721660208929_13 Attachment L- PRO-503-01 Change Management.pdf

SERVICE MANAGEMENT MANUAL

Change Management

Change Management

Process and Procedure Document

Doc. No.: PRO-503-01 Version: 10.0

Version Date: 1/5/2024

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 2 of 60

Table of Contents

1 Introduction

1.1 Process Purpose

1.2 Scope

1.3 Policy Statements

2 Process Description

3 Procedures

3.1 Change Initiation and Recording

3.1.1 Change Initiation and Recording Overview

3.1.2 Procedural Steps

3.2 Develop and Test Change

3.2.1 Develop and Test Change Overview

3.2.2 Procedural Steps

3.3 Finalize Assessment of Change

3.3.1 Finalize Assessment of Change Overview

3.3.2 Procedural Steps

3.4 Obtain Approval to Proceed

3.4.1 Obtain Approval to Proceed Overview

3.4.2 Procedural Steps

3.5 Enterprise Change Approvals

3.5.1 Enterprise Change Approvals Overview

3.5.2 Procedural Steps

3.6 Enter on Change Schedule and Communicate

3.6.1 Enter on Change Schedule and Communicate Overview

3.6.2 Procedural Steps

3.7 Obtain Approval to Implement Change

3.7.1 Obtain Approval to Implement Change Overview

3.7.2 Procedural Steps

3.8 Change Implementation

3.8.1 Change Implementation Overview

3.8.2 Procedural Steps

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 3 of 60

3.9 Implementation Review and Change Sign-Off

3.9.1 Implementation Review and Change Sign-Off Overview

3.9.2 Procedural Steps

3.10 Post Implementation Review and Change Closure

3.10.1 Post Implementation Review and Change Closure Overview

3.10.2 Procedural Steps

4 Roles and Responsibilities

4.1 Description of Roles and Responsibilities

4.2 RACI Definition Chart

4.2.1 Change Initiation and Recording: RACI Chart

4.2.2 Develop and Test Change: RACI Chart

4.2.3 Finalize Assessment of Change: RACI Chart

4.2.4 Obtain Approval to Proceed: RACI Chart

4.2.5 Enterprise Change Approvals: RACI Chart

4.2.6 Enter on Change Schedule and Communicate: RACI Chart

4.2.7 Obtain Approval to Implement Change: RACI Chart

4.2.8 Change Implementation: RACI Chart

4.2.9 Implementation Review and Change Sign-Off: RACI Chart

4.2.10 Post Implementation Review and Change Closure: RACI Chart

5 Appendices

5.1 Lead Times

5.1.1 CAB Report Lead Time

5.1.2 Lead Times for Type = Normal

5.1.3 Lead Times for Type = Expedited, Emergency, and Standard

5.1.4 Lead Time to Close

5.2 Customer Notifications

5.2.1 CI Contact List

5.2.2 Notification Subscriptions

5.2.3 Enterprise Changes

5.2.4 CAB Workbench

5.3 Customer-Managed Change Requests

5.4 Definitions

6 Document Control

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 4 of 60

6.1 Revision History

6.2 SP Process Owner Approval

6.3 QA Review and Approval

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 5 of 60

1 Introduction

1.1 Process Purpose

The primary goal of the Change Management process, according to Information Technology Infrastructure Library (ITIL) standards, is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes in order to minimize the impact of any related incidents upon service.

Changes to the Information Technology (IT) infrastructure may be reactive. Change Management can also proactively seek to improve efficiency and effectiveness.

This document defines the process for managing change tickets from initiation and recording to completion and closure.

1.2 Scope

This process pertains to all changes being managed in accordance with the Change Management Process.

Typically, it covers any change or possible change (e.g., relating to a proposal) affecting:

• Hardware,

• System software,

• Application software,

• Communication equipment and software, and

• Documentation and procedures regarding the management and maintenance of the supported systems.

Department of Information Resources (DIR) and all Shared Technology Services (STS) Customers are in scope for Change Management Process. All changes made to the individual Customer’s environments, as well as all changes made on shared environments and enterprise level changes are subject to Change Management Process.

1.3 Policy Statements

• A change is defined as any addition, modification, movement, or deletion that impacts the IT infrastructure or IT services. This includes all configuration items defined as in-scope.

• All Requests for Change (RFC) must be recorded in ServiceNow.

• All changes that impact or modify a configuration item come within the scope of the Change Management process to ensure compliance of the Configuration Management Database

(CMDB).

• All RFCs shall be assessed for risk, impact, and urgency.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 6 of 60

• All RFCs entered into the Change Management System, excluding standard changes, require successful completion of testing prior to the implementation. In the case where there is no test environment, post Implementation testing/validation can be performed.

• Any RFC, except for emergency changes, must be submitted in time for an appropriate pre-assessment prior to the authorization and implementation of the change.

• Business justification must be documented within the change request when a change is being rejected and occurs at any stage. This includes rejection from Multi-sourcing Services Integrator (MSI) Change Manager, Service Component Provider (SCP) as well as STS Customer.

• Change tasks will be opened within the change request to engage other support groups.

• Post implementation testing results are required to be provided and documented in the implementation task within the change request upon completion, and prior to moving the change to Review.

• Changes that require Customer communication plans will be marked within the RFC, and communication will be issued from ServiceNow. Failure to execute the Customer communication plan will result in the change being marked as a failed change.

• In the case where an unexpected outage or issue occurs during a change window or the actual impact is different than what was communicated to the Customer, then the SCP must immediately contact the Customer for awareness. The communication that is sent out by the SCP needs to be documented within the change ticket and should reference acknowledgement by the Customer whether it be through a verbal response or through email.

• Incidents may be opened during the change window to engage other support groups.

Incidents that are resolved within the allotted change window and did not impact other STS Customers are considered successful changes.

• All changes must be authorized before being implemented.

• Unauthorized changes, which have been executed without approval, will require the Change Coordinator to create and complete a proper RFC so that the failed change can be properly represented in the ticketing system.

• Service Level Agreement (SLA) exceptions cannot be filed for changes that are closed with a Sub-State Code of Process not followed.

• Third-party vendors should be engaged prior to the start of the change to ensure assistance will be available if needed during the implementation window.

• An Enterprise Normal change will require a Service Delivery Manager approval.

• Emergency Change Policy Statements o All emergency changes must be submitted for approval no more than 72 hours following the associated incident remediation. These are changes which are related to a Priority

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 7 of 60

(P)1/P2 incident where a break/fix incident required immediate resolution. The Change Coordinator must submit the emergency change request and relate the P1/P2 incident.

o Email notification will be sent out by ServiceNow to the affected STS Customers of the emergency change once the change enters Review state.

o Only emergency change requests will be allowed outside of the weekly Change Advisory Board (CAB) cycle for change requests that do not meet the lead time and/or the expedite change request policy.

o In the event that a change will be required to resolve a P1/P2 incident but will be scheduled at a later date/time (greater than 1 business day), then the change must follow the normal or expedite process.

• Standard Change Policy o Standard changes are pre-approved by Change Management. Because standard changes are pre-approved, they are not reviewed in the weekly Customer CAB meetings.

o Standard changes are low to zero-risk, transparent to other Customers and are usually related to routine maintenance in either the Production, Development, or User Acceptance Testing (UAT) environments.

o All standard changes must meet agreed upon criteria as follows.

o Usually initiated by the support organization o Low risk to Customer o Repeatable documented change with tasks that are well known o Pre-authorized: authority is given in advance o All subsequent standard changes that are executed within the approved environment must have an outcome of a change status of Successful. If one instance of the change is subsequently executed as Unsuccessful, Backed Out, or Successful with Issues, and has impacted the Customer’s ability to conduct day-to-day business, then the change cannot be considered as a standard change and is removed from the Standard Change List.

• Texas.gov Standard Change Policy o All potentially affected Customers must approve standard change candidates by a Customer Representative via the weekly DIR-Tx.Gov CAB meeting.

o If a Customer would like to reject a standard change proposal, then that rejection must be made during the weekly DIR-Tx.Gov CAB meeting by a Customer Representative. Rejections will not be accepted by email.

o Failure to attend the weekly DIR-Tx.Gov CAB meeting during the standard change review period will be counted as an implied approval for the Customer.

o The primary communication of an upcoming standard change candidate will be handled by the SCP implementing the change.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 8 of 60 o The MSI Change Management team will include, as part of the DIR-Tx.Gov CAB meeting notification, a disclaimer that a standard change candidate will be discussed in an upcoming CAB meeting.

• Expedited Change Policy o Expedited changes as a result of poor planning and/or time management will not be allowed. The expedited change must meet the below stated criteria and therefore meet the requirement as a true business need for DIR/Customer. Any expedited changes that do not meet the requirements as stated will not be approved and must wait until the DIR/Customer’s next scheduled CAB meeting.

o Additional approval from the assignment group’s Service Delivery Manager (SDM) is required for expedited changes.

o The request for change will be complete, audit compliant, and in Authorize status with the required Tower Leads and Service Delivery Manager’s approvals in order to proceed.

o All reasonable effort will be made to bring the expedited change request forward before 3 PM Central Time (CT) of the requested business day.

o Any expedited changes that do not meet the requirements as stated will not be approved and must wait until the DIR/Customer’s next scheduled CAB meeting.

• Maintenance Schedule entries can be deleted, and Blackout Schedules can be added at a minimum of 60 days in advance.

• Implementation has to be conducted within the approved change window with ServiceNow tracking the actual start and end times of changes as close to reality within the approved planned time window. In addition, changes cannot be moved into Implement state until after the approved planned start time.

• Change window extensions can be requested by the Change Assignee prior to the window ending. MSI Change Management should not be contacted to extend the change window or to seek approval to extend the change window. The request will instead be made by the Change Assignee and come from within ServiceNow via the Extend Implementation Window button, and requires a new end date/time, and justification before an email is sent from ServiceNow for approval. The change may proceed forward past the original end date once an approval has been obtained. A change window can be extended up to three times within ServiceNow to remain a successful change but if more time is required to complete the work beyond the extended date, then the change window can be extended further with approval but the change will be closed as Successful with Issues.

o Pre-approved window extensions are enabled when included within the RFC and approved by the Customer.

o For enterprise and DIR-Tx.gov changes, DIR will provide their approval to extend the change window, and, if required, may request multiple window extensions without a change being marked as Successful with Issues. Notifications of an enterprise change

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 9 of 60 window being extended will be sent out by ServiceNow and/or MSI Change Management to all affected Customers.

o Rejected Window Extension Requests will stay in the Implement state instead of returning to the New state.

• In the event that a change will not be implemented and must be cancelled, the Change Coordinator must use the Stop Implementation option as soon as possible, no less than one hour prior to the start of the approved window, to ensure any Customer resources that may have been scheduled for the change are notified of the cancellation. The Customer confirmation of the cancellation is automatically documented in the change request within ServiceNow. Failure to follow the process and proper communication will result in the change being marked as a failed change.

• During the Closure process, if Change Management determines that there is missing information required for a change to be closed such as the Post Implementation Review (PIR) Tab, then an email will be sent by MSI Change Management to the Change Assignee and the Assignment Group lead requesting that the change be updated. There will be a 10-day turnaround to either update the change or respond back to Change Management.

Failure to meet this 10-day turnaround will result in the change being closed as failed with a sub-state code of Process not Followed.

• Data Sensitive Documentation Policy o Files which include, but are not limited to, Excel spreadsheets, Word documents, screenshots, emails, and other forms of media that are attached to an email by either the MSI or SCP, and which these files contain data sensitive information such as network information [Internet Protocols (IP), Macintosh (MAC) address, Global Unique Identification Number (GUID), etc.], financial data, critical server information, and other Customer data [Personal Health Information (PHI), Personally Identifiable Information (PII), Federal Tax Information (FTI), etc.) must be password-protected.

o Data-sensitive files that contain multiple Customer’s information, such as a spreadsheet containing IP addresses that will be emailed, must be parsed out by Customer and password-protected.

o Files that are attached to a ServiceNow Service Request that involve a shared asset must be password-protected.

• Stale Change Policy o Changes that have passed their recorded planned end date and/or have not been updated in 30 days are considered Stale.

o 30 days is taken from the Updated Date field of the change request.

o Changes in the request state of New, Assess and have either passed their planned end dates or have no dates and have not been updated by the Change Assignee in 30 days will be cancelled by Change Management. Prior to cancellation, the Change Management team will email both the Change Assignee and the line manager

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 10 of 60 requesting an update. If no update is received after one business day, then the change will be cancelled. If work is still needed, then a new change ticket will need to be created.

o Prior to cancelling any change, the Change Assignee must reach out to the Customer who requested the change to inform them of the cancellation and obtain their approval to cancel. If a change is being cancelled by MSI, then the communication to the Customer will come from the MSI Change Management team.

o Changes in the request state of Scheduled or Implement and have passed their planned end date need to be moved by the Change Assignee to the request state of Review within two business days from the planned end date. Failure to move the change to Review will result in a failed change with a Sub-State Code of Process not Followed.

• Enterprise Change (Enterprise Maintenance Windows – EMW) Policy

Enterprise changes are used when a change is requested/needed for shared resource(s) impacting multiple Customers and authorized by DIRE on behalf of all Affected Customers.

Must meet the following criteria to be considered an Enterprise Change:

o Six or more STS Customers with ServiceNow Approval Groups o Note that DIRA should be counted as a DCS Customer o Enterprise Change? = ‘Yes’ in Change Request for Normal or Expedited Changes o Class = DCS Shared AND using Enterprise Maintenance Window (EMW) for STS Enterprise CAB

OR

o Class = Application for Texas.gov CAB

New Enterprise Tab is adjacent to the Notes Tab with default Required fields.

o Additional required fields are contingent upon responses.

o The Enterprise Tab will appear when Enterprise? = ‘Yes’ for Normal or Expedited Changes.

o Three Sections:

1. Disruption Window

2. Risks if Not Implemented

3. Enterprise Communication o SCPs will leverage the STS IT Freeze/Maintenance Calendar when scheduling out their EMW changes.

o Enterprise Maintenance Windows are established six times a year falling on even months (Feb, Apr, Jun, Aug, Oct, Dec), and are broken into two weekends, third weekend of the month for Austin Data Center (ADC) and fourth weekend of the month for San Angelo Data Center (SDC).

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 11 of 60 o Odd months are reserved (Jan, Mar, May, Jul, Sep, Nov) for rescheduled or expedited EMW changes and should only be used if absolutely necessary. The six-week lead time and normal data center schedules still apply.

o EMW changes (CHG) are required to be in Assess status and fully compliant six weeks prior to the planned start date defined in the change request within ServiceNow.

o Change will remain in Assess status for the first two weeks to allow time for discussions/negotiations that may be needed between the Customer and the SCP in response to an EMW change request.

o Should a Customer have concerns regarding the EMW change during the two-week review stage and those concerns are not addressed prior to the change moving to Authorize, then the Customer Executive Director should present those concerns to the DIR Chief Operating Officer (COO) for resolution.

o Notification and confirmation checkpoints will be sent out automatically by ServiceNow to IT Directors based on the Affected Customers listed on the EMW change ticket. These notifications will occur within a six-week period at two-week intervals (6, 4, 2 weeks out) prior to the planned start date.

o DIR will approve all EMW change requests on behalf of the Customers once the CHG enters Scheduled for Approval status.

o Should a Customer request to delay a scheduled enterprise change that has already been approved by DIR and moved to Scheduled status, then the Customer’s Executive Director must contact the DIR COO to state their business case (justification) for the delay.

o Dissenting Customers must be presented with opposing perspectives, and the impacts of deferring the enterprise change from other Customers who have already approved, and who have planned resources around the change. This information should be presented in the STS Shared CAB meeting, as well as the monthly Information Technology Leadership Committee (ITLC) meeting.

o In the event that an enterprise change is rejected and rescheduled at the direction of an STS Customer, then the ITLC will require a root cause analysis (RCA) to be performed by the dissenting Customer, with corrective actions that are identified and implemented to eradicate conditions which led to the rejection. The root cause analysis will be presented in the monthly ITLC meeting by the STS Customer who requested the rejection.

o An RCA will not be required if a reschedule is requested due to circumstances beyond the control of the Customer such as an active security threat (physical or virtual), state mandated freeze or a natural disaster which includes but are not limited to (weather events, building fires, and power outages). An RCA would also not be required if multiple Customers have rejected an EMW change.

o In the event where the SCP requests an approved EMW CHG to be rescheduled, then communication is required to be sent out. This will be automatically done within ServiceNow.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 12 of 60 o If it is determined by the SCP that an enterprise maintenance window is not needed, then the SCP must reach out to the MSI Change Management team as soon as possible so that the enterprise calendar on the STS Portal and the STS IT Watch/Freeze Schedule can be updated.

o An expedited EMW CHG due to poor planning is not allowed and will be required to follow the established lead time as stated above.

o A representative from every SCP is required to attend the Enterprise CAB meeting.

o Enterprise critical maintenance changes (security patches, cyber threats, malware removal, etc.) will follow this same EMW process with the exception of the six week period notification.

• Enterprise Expedited Changes o If it is determined by either DIR or an SCP that immediate enterprise work is required, then an expedited enterprise change can be initiated. This expedite request can come directly from DIR, SCP, or could be spun off from an active Priority 1 or 2 incident. Some examples of critical work include, but are not limited to, a security vulnerability, a potential hardware failure on a multi-tenet device such as a switch or storage area network (SAN), or a lack of redundancy on an enterprise device.

o If DIR is initiating the expedited enterprise change, then communication needs to be sent out by a DIR representative to the SCP who will be implementing the change [includes Customer Relationship Managers (CRMs), Assignment Group, and Service Delivery Managers (SDMs)], to MSI Change Management, and to the Enterprise Relationship Managers (ERM) informing them of the impending expedite. The communication should contain as much detail as possible on the issue, why it is needed, asset(s) involved, and the target date of implementation.

o If an SCP is initiating the expedited enterprise change then communication must be sent to the Department of Information Resources-Enterprise (DIR-E) Representatives, CRMs, and MSI Change Management informing them of the impending expedite. The communication should contain as much details as possible on the issue, why it is needed, expected impact, asset(s) involved, affected Customers, and the target date of implementation.

o Once the SCP has all of the required information for the work and communication has been sent out; the SCP will create an expedited change request and move the change to Authorize/CAB Readiness for Change Management review.

o An Emergency Enterprise CAB meeting will be scheduled immediately by MSI Change Management once the expedited change has been reviewed for compliance and the change moved to Authorize/CAB Review.

o The purpose of the Enterprise E-CAB is to discuss the details of the change, the business justification, detailed impact assessment, date/time of implementation, and to allow the affected Customers to ask questions and express any concerns they have. No Customer approval is given during this call.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 13 of 60 o After the E-CAB has ended, DIR may either approve or reject the change.

o If a Customer does not agree with the change, either with the work being performed or the date/time of the implementation, then the escalation path would be followed as outlined in the EMW policy.

o After the E-CAB has ended, communication going forward is handled by the SCP implementing the change. This includes bridge calls and post implementation emails.

o The expedited enterprise change should be updated by the SCP frequently as soon as updates occur.

• In the event that an SCP will require another SCP(s) to implement a change:

o the requesting SCP will submit a request via the Service Request Catalog, o Service Catalog Tasks (SCTASKs) will be assigned for each SCP involved with the request, o the SCP Requester will coordinate with the SCPs assigned to each SCTASK, o the SCPs assigned to the SCTASK will create a change based on the specifications of the service request and coordination with the SCP Requester, and o changes created from the SCTASK by the SCP will be classified as EMW or enterprise changes and must follow the EMW process outlined in this document.

• SCPs impacted by a change being performed by another SCP must be included on the change request as an Affected Customer. Impacted SCPs must review and approve the change request before the change can move forward for MSI review. Failure to approve/reject the change after three business days will result in the change being automatically approved.

• In the event that an impacted SCP rejects another SCP’s change because of a need to address a conflict or because a change is lacking information, then MSI Change Management will quickly escalate to both DIR and the MSI Service Delivery Manager to inform them of the rejection. A meeting will be scheduled by MSI with all parties involved to seek a resolution for the rejection. DIR has the authority to override an SCP’s rejection for enterprise changes.

• Conflicts between multiple SCP changes are either detected by the SCP during the creation of the change or by MSI Change Management during the review stage. Conflicts can be detected by either the Conflict Detection tool within ServiceNow or through the Enterprise Change Calendar. Detected conflicts should be worked out prior to the change being approved for implementation. In the event that a resolution cannot be found to resolve a conflict, then escalation to both the MSI Service Delivery Manager and DIR-E should be initiated by MSI Change Management. If changes are made to the Implementation Plan, Change Window, etc., in response to a conflict, then those should be captured in the change request. Confirmed conflicts will also be announced in CAB by the MSI Change Manager.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 14 of 60

Each STS policy and procedure is aligned to the National Institute of Standards and Technology (NIST) SP 800-53 standard security framework. The following controls apply to this document.

• Configuration Management: CM-1, CM-8

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 15 of 60

2 Process Description

The Change Management lifecycle is designed to prevent unauthorized changes being promoted into the live environment, thereby endangering the service being provided. While there are a number of process stages that a change must progress through before it is allowed to go-live, the process must be flexible enough to accommodate all types or classes of changes (refer to Appendix 5.4 Definitions for the types of changes).

Process stages include:

• Change Initiation and Recording,

• Change Review and Authorization (Approval to Proceed),

• Change Planning and Scheduling (Approval to Implement),

• Change Implementation, and

• Change Completion and Closure.

Start

3.1 Change

Initiation and Recording

3.2 Develop and

Test Change

3.3 Finalize

Assessment of

Change

3.4 Obtain

Approval to

Proceed

3.5 Enterprise

Change

Approvals

3.6 Enter on

Change Schedule and Communciate

3.7 Obtain

Approval to Implement

Change

3.8 Change

Implementation

End

3.9 Implementation

Review and Change Sign-Off

3.10 Post

Implementation

Review and Change Closure

Change Management Overview Flowchart

This process outlines each of the stages above and includes a continuous improvement stage for the Change Management process. Each stage is broken into a number of activities that are comprised of detailed tasks.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 16 of 60

3 Procedures

3.1 Change Initiation and Recording

The purpose of this procedure is to provide details of the activities undertaken to create and log an RFC once a need for change has been identified. It covers the activities needed to complete the initial recording, impact, urgency and priority assessment and classification of the change.

• Request for Change is created by SCP Change Coordinator, based on request from DIR/STS Customer/SCP via a service request.

• Any change as part of the incident resolution should follow Change Management process and is recorded in the ServiceNow by the SCP Change Coordinator.

• SCP Change Coordinator may also generate change requests proactively or as a result of activities in the Problem Management, Service Level Management, or any other processes.

In order to respond appropriately to an RFC, it is essential that a considered approach is undertaken in respect of the assessment of risk and business continuity, impact, resource requirements, and change approval. This is essential to maintain a proper balance between the need for change and the potential negative impact of the change.

WI-503-01 Create, Classify, and Submit RFC provides guidance to create a change, classify and determine the impact, urgency, and risk of the change.

3.1.1 Change Initiation and Recording Overview

Change Initiation and Recording

Ch an ge R eq ue st er

/A ss ig ne e Pr oc es s I nt er fa ce s

Change Initiation and Recording

Start

1. Gather Change Information and

Supporting Documentation

Obtain Authorization to Implement

Develop and Test Change

2. Determine if Standard Change

Standard Change?

4. Complete Initial Recording of RFC

5. Relate Affected CIs

6. Assess Change, Impact, Urgency, and Risk of the

Change

7. Add Details and Business

Justification

CMDB

Changes Needed?

8. Propose Changes to a CI9. Submit Change

10. Assign Change to Build and Test Teams

3. Apply Change Template

Yes

No

Yes

No

Change Initiation and Recording Overview Flowchart https://dirsharedservices.service-now.com/sp?id=managed_docsv1&path=0b05d28bdb5308d025236a5b8a9619c6

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 17 of 60

3.1.2 Procedural Steps

1. Gather Change Information and Supporting Documentation

The SCP Change Coordinator gathers the change information and supporting documentation required to generate the Request for Change (RFC). This activity can involve consultation with DIR/STS Customer/SCP Change Implementer/SCP Change Coordinator, technical resources, other support teams, or ServiceNow records to ensure that all of the required information can be sourced.

When the information is available, the SCP Change Coordinator then accesses the change tool to create the RFC.

Note: ServiceNow change request should be created for all change requests affecting Production, Development, Test, Pre-Prod/Training, and UAT environments.

2. Determine if Standard Change

Once the tool is opened, the SCP Change Coordinator determines if the change is a standard change (pre-authorized change).

• Standard Change?

o If Yes, continue to Step 3.

o If No, continue to Step 4.

3. Apply Change Template

The SCP Change Coordinator applies the change template to the change request and completes RFC detail. Change template includes information such as Short Description, Detail Description, Risk, Impact, Urgency, Category, and Tasks.

4. Complete Initial Recording of RFC

Using the information gathered in Step 1, the SCP Change Coordinator populates the input screen(s) of ServiceNow to create the initial RFC. Mandatory and optional information are included. The SCP Change Coordinator should supply as much information as possible to support the requested change.

Note: When change requests are raised as a resolution to an incident or problem record, the source record number should be related. In this manner, the link between the incident/problem and its resolution is readily apparent creating the required audit association/trail.

Note: Request for Change (with type of Normal) follows the defined lead times for submission. Refer to Appendix 5.1 Lead Times for details on lead time.

5. Relate Affected CIs

Every change request has to have at least one configuration item (CI) related to the change request. The configuration item will automatically pre-populate additional information within the change request, like Impact, Assignment Group, and Affected Customers.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 18 of 60

Missing or incorrect CI information pertaining to the asset will be the responsibility of the Change Coordinator to correct in the CMDB. Change Coordinator will complete the necessary documentation and submit the CMDB update with the RFC accordingly.

6. Assess Change, Impact, Urgency, and Risk of the Change

The SCP Change Coordinator determines the change class, urgency, environment, confirms the service impact via the Impact Assessment, and priority. Additionally, the SCP Change Coordinator has to determine whether a change requires an outage window and additional business notification to be sent out. Once complete, the information is added to or updated in the RFC record.

7. Add Details and Business Justification

The SCP Change Coordinator has to provide a short and detailed description of the change request. Every change request requires business justification to be provided. It is critical to clearly understand why a change is required.

• CMDB Changes Needed?

o If Yes, continue to Step 8.

o If No, continue to Step 9.

8. Propose Changes to a CI

The SCP Change Coordinator has to determine whether the CMDB will require to be updated after the change. If Yes, they will need to propose all required changes and submit them for review.

9. Submit Change

The SCP Coordinator submits the request to the Change Manager in line with agreed lead-times.

10. Assign Change to Build and Test Teams

The Change Coordinator then assigns the change activities and associated plans to the relevant Change Builders and Testers (Technical Teams) to allow the initiation of the planning activities. The Change Coordinator ensures the RFC is updated with the assignment information and planning output, as necessary.

On completion of these activities, or where indicated, move to Procedure 3.2 Develop and Test Change.

3.2 Develop and Test Change

This procedure documents the activities involved in the build and testing of the change prior to seeking approval to implement.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 19 of 60

Note: In cases where there is no test environment, post implementation testing/validation can be performed.

3.2.1 Develop and Test Change Overview

Develop and Test Change

SC

P

Ch an ge

Co or di na to r

SC

P

Ch

Bu ild er s

SC

P

Ch

Te st er s

Pr oc es s I nt er fa ce s

Change Review and Authorization

1. Oversee Development

Activity

Change Initiation and

Recording

Is Development

Complete?

Obtain Approval to Implement

Change

2. Undertake Development

Build Activities

3. Refer Development Issues

5. Oversee Testing Activity

Is Testing Complete? 7. Refer Test Issues

8. Review and Address Test Issues

No

Yes No

Yes

4. Review and Address

Development Issues

6. Undertake Change Test

Activities

Finalize Assessment of

Change

Develop and Test Change Overview Flowchart

3.2.2 Procedural Steps

1. Oversee Development Activity

The SCP Change Coordinator oversees the build activity undertaken by the SCP technical teams. The MSI Change Manager monitors the progress of the build to ensure that the activities are completed. The SCP Change Coordinator ensures that the change request is updated with the progress and outcome of the build activity.

Note: The build can consist of both parallel and linear tasks and the order in which the tasks are completed as detailed in the associated plan(s).

2. Undertake Development Build Activities

The SCP Technical Teams initiate and continue work on the assigned build activities.

The Change Build and Test policy provides information.

The SCP Change Builder determines if the build activity is complete and updates the change request accordingly.

• Is Development Complete?

o If Yes, continue to Step 6.

o If No, continue to Step 3.

3. Refer Development Issues

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 20 of 60

If there are issues with a build task(s), the SCP Change Builder(s) refers these back to the SCP Change Coordinator.

4. Review and Address Development Issues

The SCP Change Coordinator reviews the issues and ensures the change request is updated accordingly. In consultation with the appropriate SCP Technical teams and Change Implementers, an action plan is made to address the issues raised.

5. Oversee Testing Activity

The SCP Change Coordinator oversees the build activity undertaken by the Testers. The MSI Change Manager monitors the progress of testing to ensure that the activities are completed.

The SCP Change Coordinator ensures that the change request is updated with the progress and outcome of the testing activity.

6. Undertake Change Test Activities

The SCP Change Testers undertake the testing activity as detailed in the test plan.

Note: Where appropriate, users will be involved in the testing activity. The Change Build and Test policy provides information.

The SCP Change Testers determine if the test activity is complete and update the change request accordingly.

• Is Testing Complete?

o If Yes, move to Procedure 3.7 Obtain Approval to Implement Change.

o If No, continue to Step 7.

7. Refer Test Issues

If there are issues with testing, the Support/Test Team(s) will refer these back to the SCP Change Coordinator and/or the MSI Change Manager.

8. Review and Address Test Issues

The SCP Change Coordinator reviews the issues and ensures that the change request is updated accordingly. In consultation with the appropriate SCP Technical teams and Change Implementers, an action plan is made to address the testing issues raised.

Upon successful completion of the tests, move to Procedure 3.3 Finalize Assessment of Change.

3.3 Finalize Assessment of Change

This procedure documents the activities required to finalize the details of the RFC.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 21 of 60

Note: It is essential that only suitably assessed RFCs are assigned to DIR/STS Customer for progression.

3.3.1 Finalize Assessment of Change Overview

Finalize Assessment of Change

M

SI

C ha ng e

M an ag er

SC

P

Ch di na to r

Pr oc es s I nt er fa ce s

Change Review and Authorization

Start

1. Confirm Classification of Change

Develop and Test Change

Obtain Approval to

Proceed

2. Confirm Change Design and Estimate

4. Review Disaster Recovery

Provision and Plans

5. Identify Capacity and Availability

Implications

6. Finalize Risk

Assessment

3. Create Tasks, Establish Schedules and Plans

7. Finalize Impact

Assessment

Finalize Assessment of Change Overview Flowchart

3.3.2 Procedural Steps

1. Confirm Classification of Change

The MSI Change Manager reviews the scope and content of the RFC to ensure that the provided details are relevant. If necessary, adjustments are made.

2. Confirm Change Design and Estimate

The MSI Change Manager in conjunction with the SCP Change Coordinator Teams performs an assessment to determine and confirm the overall scope, planning, design and estimate for the change. A review of the design solution, estimates, product and service impacts and implementation activities is also conducted. Risk Assessment is not submitted by the SCP Change Coordinator.

3. Create Tasks, Establish Schedules, and Plans

Change Coordinator creates and updates change tasks within the RFC’s Related Lists. It is now decided whether any support from different teams or towers is required to complete the change. All tasks created have to be assigned to the correct resolvers.

Instructions and timelines within the tasks have to be stated clearly.

4. Review Disaster Recovery Provision and Plans

The MSI Change Manager will review the RFC to determine what effect it might have on the current Disaster Recovery (DR) provisions and security plans. When it does, the MSI Change Manager asks the SCP Change Coordinator to consult with the SCP Service Continuity Delivery Team or Security Officer to complete this activity.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 22 of 60

In particular, changes to hardware (e.g. processor and memory upgrades or storage increases, software (e.g. new releases or patches) and backup requirements must carefully be evaluated to see whether disaster recovery provision will be affected and will need to change in light of the change. If a need to update the change request is identified to address amendments to DR requirements the requirements should be incorporated into the change and the associated tasks managed appropriately.

Refer to WI-503-02 Change Assessment Guidelines for guidance on reviewing disaster recovery provision and plans.

5. Identify Capacity and Availability Implications

The MSI Change Manager will also undertake an impact assessment through consultation with the appropriate SCP Technical teams in order to identify if there are any capacity and availability implications. Also, any changes to the Capacity and Availability Management plans, if available, should also be identified.

If a need to update the change to address amendments to the capacity or Capacity Plan is identified, the requirements should be incorporated into the change and the associated tasks (Planning and Build).

Refer to WI-503-02 Change Assessment Guidelines for guidance on identifying capacity and availability implications.

6. Finalize Risk Assessment

The MSI Change Manager now reviews the Risk Assessment to determine if the initial Risk Assessment allocated is correct, using the agreed risk definitions for the engagement. If necessary, the Risk Assessment is amended to reflect the updated RFC.

The Risk Assessment is completed to identify the change risk and identify further actions to take to manage risks during the change. Any changes to risks categories should be in agreement with DIR/STS Customer.

7. Finalize Impact Assessment

The MSI Change Manager will review the Impact Assessment to determine if the impact of the change is clearly defined and concise. The Impact Assessment should reflect both the potential for impact/outage due to the change being implemented, and the risk to the environment of not implementing the change.

On completion of these activities, or where indicated, move to Procedure 3.4 Obtain Approval to Proceed.

3.4 Obtain Approval to Proceed

The purpose of this procedure is to document the activities required to obtain approval from both SCP Approver and MSI Change Manager.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 23 of 60

3.4.1 Obtain Approval to Proceed Overview

Obtain Approval to Proceed

SC

P

Re vi ew

Ap pr ov er s M

SI

C ha ng e M an ag er

SC

P Ch di na to r Pr oc es s In te rfa ce s

Im pa ct ed

S

CP

Ap pr ov er s

Change Review and Authorization

1. SCP

Approval Review

Finalize Assessment of

Change

3. MSI Change Management

Approval Review

Approve Change?

Approve Change?

4. Determine if Change Should be Deferred

Defer Change?

5. Issue Deferral

Notification

6. Cancel Change

Enter on Change Schedule and Communicate

Yes Yes

No

Yes

No

Finalize Assessment of

Change

2. Impacted SCP Approval

Review

Approve Change? No

Obtain Approval to Proceed Overview Flowchart

3.4.2 Procedural Steps

1. SCP Approval Review

The Tower Lead of the SCP Implementing the change request reviews the RFC to ensure technical accuracy and compliance.

The SCP Approvers consider the RFC for approval and approve or reject change.

• Approve Change?

o If Yes, continue to Step 2.

If No, continue to Step 3.

2. Impacted SCP Approval Review

In the event that an SCP will be impacted by a change being performed by another SCP, the impacted SCP will be added as an Affected Customer and will review and validate the

RFC.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 24 of 60

The impacted SCP Approvers consider the RFC for approval and approve or reject change.

• Approve Change?

o If Yes, continue to Step 3.

o If No, continue to Step 4.

3. MSI Change Management Approval Review

The MSI Change Manager reviews and validates the RFC including the Implementation and Back-Out plans, resource requirements and any additional information.

• Approve Change?

o If Yes, continue to Step 6.

o If No, continue to Step 4.

WI-503-07 Guidelines for Change Review and Approval provides information to review and approve an RFC.

4. Determine if change should be deferred

After Change Review, the Approvers decide whether they require more details from the SCP Change Coordinator if the RFC should be deferred.

• Defer Change?

o If Yes, continue to Step 5.

o If No, continue to Step 6.

5. Issue Deferral Notification

The Review Approver(s) may choose to defer the change due to a requirement for additional information. If this decision is made, the RFC is updated with the reasons for rejection and returned to the SCP Change Coordinator. The notification is automatically sent out to the Requester and Assignee of the Change. Additional notifications to both DIR and the MSI Service Delivery Manager are handled by MSI Change Management, in the event a decision to defer is initiated by an impacted SCP.

Return to Procedure 3.3 Finalize Assessment of Change where the SCP Change Coordinator provides additional information and resubmits the change for assessment.

6. Cancel Change

The MSI Change Manager may choose to cancel the change for various reasons. If this decision is made, the RFC is updated with the reasons for the cancellation and returned to the SCP Change Coordinator. Notification is also sent to the Change Requester informing them of the cancellation.

WI-503-04 Cancel Request for Change provides information to cancel the RFC.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 25 of 60

On completion of these activities, or where indicated, move to Procedure 3.6 Enter on Change Schedule and Communicate.

3.5 Enterprise Change Approvals

Enterprise Maintenance Window (EMW) candidates are submitted for technical review and approval to the respective support towers’ Tower Team Lead for relevance and approval happens at least six weeks before the Planned Start Date/Time.

When approved, the EMW stays in the state Assess and the Change Coordinator works with Change Management to update the change request in ServiceNow to be ready for the outstanding approvals (must be requested at least four weeks in advance of the planned implementation start).

All EMW change requests must have the field Enterprise Change? marked as Yes.

The process for the enterprise changes differs on the lead times, but also on the approvals.

Whenever an EMW is scheduled because of the enterprise wide impact, it has to follow a custom approval flow, to ensure proper level of planning and authorization.

3.5.1 Enterprise Change Approvals Overview

Enterprise Change Approvals

M

SI

C ha ng e

M an ag er

D

IR

-E

SC

P Ch di na to r Pr oc es s I nt er fa ce s

SC

P

To w er L ea d

Change Review and Authorization

1. Review

EMW

Change Initiation and

Recording

Approve

EMW?

2. State Changed to Assess, Notification Issued

Approve

EMW?

4. Review

EMW

3. Review Approval

6. Review

EMW

Approve

EMW?

5. Review

EMW

Approve

EMW?

7. EMW

Scheduled

Notification

8. Update and Distribute

Change Schedule

Change Implementation

Yes

No

Yes

No

Yes

NoNo

Enterprise Change Approvals Overview Flowchart

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 26 of 60

3.5.2 Procedural Steps

1. Review EMW

The Tower Lead reviews the complete enterprise change request at least six weeks before the planned start date/time.

• EMW Approved?

o If Yes, continue to Step 2.

o If No, return to Change Initiation and Recording Procedure.

2. State changed to Assess. Notification issued.

Once the EMW is initially approved, an automatic notification is issued. The RFC stays in Assess state. The Change Coordinator can add additional information to the RFC if available.

3. Review Approval

The Change Coordinator ensures the RFC is fully assessed, and all details are captured.

Request for approval is sent.

4. Review EMW

The Tower Lead reviews the complete enterprise change request again (at least 4 weeks before the planned start date/time).

• EMW Approved?

o If Yes, continue to Step 5.

o If No, return to Change Initiation and Recording Procedure.

5. Review EMW

The MSI Change Management reviews the complete enterprise change request to finally assure compliance with the process and ensure all details in the RFC meet the EMW criteria.

• EMW Approved?

o If Yes, continue to Step 6.

o If No, return to Change Initiation and Recording Procedure.

6. Review EMW

DIR reviews the enterprise change request. The RFC is validated. The Scheduling, Business Impact and Descriptions are verified.

• EMW Approved?

o If Yes, continue to Step 7.

o If No, return to Change Initiation and Recording Procedure.

Change Management| Process and Procedure |Version 10.0 |Version Date: 1/5/2024 27 of 60

7. EMW Scheduled Notification

An automatic notification is issued to inform that the EMW has been scheduled.

8. Update and Distribute Change Schedule

The EMW is added to the Change Schedule.

3.6 Enter on Change Schedule and Communicate

This procedure documents the activities required to enter the details of the change on the change schedule and communicate the details to all Stakeholders.

3.6.1 Enter on Change Schedule and Communicate Overview

Enter on Change Schedule and Communicate

M

SI

/S

CP

C ha ng e

M an ag er

SC

P

Ch di na to r

Pr oc es s

In te rfa ce s

Change Planning and Schedule

1. Validate Change

Information

Obtain Approval to Proceed Procedure

Obtain Approval to…