Attachment 5 Change Management Process Guide.pdf

United States Department of Agriculture Rural Development Technology Office

Technology Office Production Support and Operations Change and Configuration Management Guide

Version 4.1

March 3, 2025

Prepared by:

Rob Burtelow, Branch Chief, Production Support Operations Trudy Grimm, Change Management Lead, Production Support Operations i

Technology Office Production Support and Operations Change Management Process Guide ii

Version History

Version Date Description Author

0.01 Draft 10/14/19 Initial Draft Document Brent Todd

0.02 Draft 7/1/2021 –

12/16/2021

Additions and Revisions to make the CMG up to date with current policies and procedures

Trudy Grimm & Barb Dry

Final Version 1.0

12/17/2021 – 2/4/2022

Final changes and updates after meeting with DM&E, RD Management, and Audit

Trudy Grimm

Version 2.0 9/1/22 – 4/6/23 Title Cover Page:

Updated title to Change and Configuration Management Guide from Change Management Process Guide

Version History page:

Updated with current date and changes made by section

Reviews and Approval page:

Updated names and titles including the addition of Security reviewing/approving

Section 1.1:

Added last sentence in paragraph per Cyber Security’s request: RD’s Change and Configuration Management policy and procedures are reflected within this guide

Section 1.4:

Changed RD to O&M for the section name

Added OM Delta and OM Inflation Reduction Act to the ‘Project’ categories SET Code Change section: updated verbiage to reflect Cyber Security approval, email with agreed upon user acceptance & Test Script completed with name/date of tester & Project/Change Request & Release type numbers; added bullet for Mainframe releases

SET Code Change section: updated verbiage to reflect Cyber Security approval, email with agreed upon user acceptance and Test Script completed with name and date of tester and Project/Change Request and Release type numbers; added bullet for Mainframe releases

SET Data Change section: added bullet for Mainframe releases

Trudy Grimm iii

CERT Only Releases section: updated with requiring TRB approval and removed rollback plan from list of requirements Mainframe Requirements section: updated first paragraph with last sentence referencing prior approval required for Friday releases; updated with the last paragraph to reflect whom to contact if access is needed and/or questions;

removed previous URL

Standard Service Request section: updated with the first paragraph to replace Issue Type/Release Package (SSR) with (CERT to PROD and PROD only, etc.); updated under SSR sentence on whom to contact if questions regarding PII or CUI data; updated last paragraph to reflect whom to contact if access is needed; removed previous URL

DM&E section – Entire section revised to reflect updated current policies

Section 2.2:

Release and Deployment Management section: updated third bullet to reflect who to contact if access is needed and removed the URL

Baseline Configurations, Configuration Management Controls and Security section: updated 1st bullet to reflect who to contact if access is needed and removed the URL;

updated 2nd bullet at the end of the paragraph with four sentences regarding PFCS and included who to contact if access is needed; added 3rd bullet; updated 4th bullet to reflect who to contact if access is needed and removed three URLs; updated 6th bullet with revised first sentence, removed the URLs and removed references to AASM and UAM; updated 7th bullet and removed two URLs; updated 8th bullet with correct email addresses

Section 3.1:

Technical Review Board section: updated1st paragraph to reflect whom to contact if access is needed and removed URL; updated TRB list of groups by removing top bullet that listed Cybersecurity Representative/SME

Section 3.2:

Updated TRB Meetings section: updated the end of the first paragraph with two sentences regarding who are sent email invites, when meetings are held, and added two bullets iv

Section 6:

Process, Activities, Sub-Process Activities and Descriptions section: updated second paragraph to reflect whom to contact if access is needed and removed URL

Appendix A:

Updated Table for all APPROVALS AND RELEASE REQUIREMENTS to include verbiage for Cyber Security Approvals and documents, email with agreed upon user acceptance, and Test Script completed with name and date of tester

Appendix B:

Updated list of applications

Appendix H:

Added Support Hours to the Appendix Name; removed Weekly Releases section; renamed Custom Releases section to Routine and updated all custom words to routine;

renamed Unscheduled Releases Section to Emergency and updated all unscheduled words to emergency, added first sentence to require approval from PSO Branch Chief, and added last sentence to describe emergency change; added new paragraph at the bottom for During and After-Hours Support

Appendix J:

Updated table to include OSB and PMB

Appendix K:

Removed page of previous URLs Version 3.0 1/2/24 -

6/30/24 Changes required since last year’s first document:

Version History page:

Updated with current date and changes made by section name and number

Reviews and Approval page:

Updated names and titles including addition of Security name and approval

Section 1.4:

Added the word eighth in first paragraph and the categories of OM Delta (OMDELTA) and OM Inflation Reduction Act (OMIRA) v

Edited 3rd paragraph and removed the sentence for removing the URL listed at the end of the section. Added the sentence to contact Change Mgmt. for access and or/questions

Under SET Code definition, removed the last sentence on responsibilities for changes in the Production environment;

on 3rd bullet list added second sentence regarding Mainframe Endevor Migration form and User Acceptance Signature; on 4th bullet listed removed release type number for Test Script form

Changed Non-Code Change definition

Changed Change/Configuration Request definition

Changed Standard Service Request definition

DM&E section – This was revised extensively due to the recent updates

Section 1.5:

New section to cover Exceptions

Section 1.6:

Updated document review updates from annual to semi-annually

Section 2.2:

Under Baseline Configurations section, added seventh bullet for RD’s mainframe system not utilizing BitBucket

Section 2.3:

Removed Event and Problem management from high-level process flow

Section 3.1:

Removed prioritization of changes from first sentence in first paragraph

Section 5.0:

Change in Table 5, changed Change Owner to Change Requestor vi

Section 6.4:

Changed the order of the two descriptions between 4.02 and 4.03

Section 6.5:

Removed the first bullet and PIR Figure 6.5, since PIR is not being conducted

Updated third bullet in first set of bullets to reflect current work for 2024 in two spots

Updated fifth bullet in second set to remove within budget from sentence

Appendix A:

Updated all Quick Start columns to reflect all changes for artifacts, approvals and descriptions that were updated in Section 1.4 for both O&M and DM&E

Appendix I:

Updated Change Definition to add last statement for documenting

Updated Configuration CI (CI) to add last statement for documenting

Version 4.0 11/4/24 - 2/6/25

Version History page:

Updated with current date & changes made by section

Reviews and Approval page:

Updated names and titles

Section 1.1:

Spelled out O&M in 2nd sentence and included DM&E spelled out and the abbreviation

Section 1.4:

DM&E section – This was revised to include all types of releases and verbiage for SDLC 3.0

Section 1.5:

Changed 2nd sentence to include distinction for both O&M and DM&E: SED Director or their acting for O&M and/or their acting for DM&E. Add 2nd paragraph to cover the Salesforce community shells vii

Section 2.2:

Baseline Configurations, Configuration Management Controls and Security – bullet 1. Changed sentence to state:

On SharePoint, this data can be found with one folder for each app which includes each app’s data sheets and consolidated information including both the AHPS and Visio diagrams, respectively. Bullet 6 – edited the 2nd sentence and removed DISC

Section 2.4:

Edited first paragraph to include both O&M and DM&E.

Add third sentence to reflect DM&E process

Section 3.0:

Changed the Typical Approval Level and Description for Major from ADCIO to SED Director

Appendix A:

Updated all Quick Start columns to reflect all changes for artifacts, approvals and descriptions that were updated in Section 1.4 for both O&M and DM&E

Appendix H:

Change mainframe to financial system and added: all others that lead into financial systems, to the first two bullets.

Added the third bullet for Salesforce and added three additional bullets regarding freezes

Version 4.1 2/27/25 – 3/3/25

Version History page:

Updated with current date and changes made by section name and number

Section 1.4:

DM&E Section – Revised the artifacts and approvals for SDLC 3.0 sections; added abbreviations/acronyms where applicable

Appendix A:

Updated DM&E processes to include additions for SDLC 3.0

Appendix J:

Added PRC, SDD, SDLC, SED & SGR for acronyms viii

Reviews and Approval

Review

Name Role Signature

Glenn Duncan

Assistant Chief Information Security Officer

Tony Sanchious

Technology Office Assistant Deputy Chief Information Officer/System Owner

Brent Todd Systems Engineering Division Director

Approval

Name Role Signature

Janell Duke Technology Office Assistant Chief Information Officer ix

Table of Contents

1. Introduction

1.1. Purpose

1.2. Scope

1.3. Definitions of Requests in Scope

1.4. Operations & Maintenance (O&M) & Development Modernization & Enhancement (DM&E) - Project and Issue Types, Definitions, Approvals, and Requirements

1.5. Exceptions

1.6 Document and Process Review and Update

2. Process Overview

2.1. Goals and Objectives

2.2. Relationships to Other Processes

2.3. High-Level Process Model

2.4. Process Description

2.5. Critical Success Factors and Key Performance Indicators

3. Technology Office Change Type Definition and Approvals

3.1. Technical Review Board

3.2. TRB Meetings

4. Emergency Change Process Description

5. Roles and Responsibilities

6. Process Activities, Sub-Process Activities and Descriptions

6.1. Record

6.2. Review

6.3. Assess and Approve

6.4. Coordinate

6.5. Close

6.6. Emergency Change Sub-Process

Appendix A: Quick Start Reference and Process Guide for O&M and DM&E Change Requests and Releases

– Non-Emergency

Appendix B: RD Application List

Appendix C: Change Management Procedures for creating Change Requests and Release Packages

Creating a Change Request following the steps from the JIRA Process SOP guide:

x

Creating a Release Package following the steps from the JIRA Process SOP guide:

Appendix D: RACI Matrix

Appendix E: Referential Documentation

Appendix F: O&M vs. DM&E Decision Rubric

Appendix G: Impact, Urgency, and Priority Levels

Impact, Urgency and Priority Figure G: Impact, Urgency, and Priority Table

Appendix H: Freezes, Scheduled Outages, Releases, and Support Hours

Freezes

Scheduled Outages

Routine Releases

Emergency Releases

During and After-Hours Support

Appendix I: Glossary

Appendix J: Acronyms xi

List of Figures

Figure 1: Relationships between ChM, RDM, and CfM Processes Figure 2: Change Management Process Flow Figure 3: 'Record' Sub-Process of the ChM Process Figure 4: 'Review' Sub-Process Activities of the ChM Process Figure 5: 'Assess and Approve' Sub-Process Activities of the ChM Process Figure 6: 'Coordinate' Sub-Process Activities of the ChM Process Figure 7: 'Emergency' Change Sub-Process Flow

List of Tables

Table 1: Change Type Matrix Table 2: Change Management Process Activities Table 3: Change Management CSFs and KPIs Table 4: Change Type and Approval Matrix Table 5: Change Roles and Responsibilities Table 6: 'Record' Sub-Process Activities Table 7: 'Review' Sub-Process Activity Descriptions Table 8: Assess and Approve' Sub-Process Activity Descriptions Table 9: 'Coordinate' Sub-Process Activity Descriptions Table 10: 'Close' Sub-Process Activity Descriptions Table 11: Emergency Change Sub-Process Activity Descriptions

1. Introduction

1.1. Purpose

The Rural Development (RD) Technology Office (TO) Production Support and Operations (PSO) Change Management (ChM) Process Guide establishes and documents the enterprise management process for the Technology Office organization. The ChM Process implementation and execution for the Technology Office Operations and Maintenance (O&M) and Development, Modernization, and Enhancement (DM&E) aligns with the content of this guide. The use of this guide ensures Technology Office IT Service Management (ITSM) activities are executed in a uniform and measurable manner. RD’s Change and Configuration Management policy and procedures are reflected within this guide.

1.2. Scope

The scope of the Technology Office Change Management Process Guide includes the management of all service requests and changes to the environment managed by the RD Technology Office. Changes include any addition, modification, or removal that could influence IT services managed by the RD Technology Office. These procedures will be performed every time a customer has a change request for services that the Technology Office O&M group manages.

1.3. Definitions of Requests in Scope

A Change Request is defined as a service request for any addition, modification, or removal that may or may not be pre-approved and that could influence IT services managed by the RD Technology Office. These requests require a completed Change Request intake and may incur additional cost. Change Requests are created in the ITSM tool for creating and tracking Change Requests, Release Packages, Incidents and Projects. The scope includes IT services, configuration items, processes, and documentation.

There are three types of Change Requests:

Change Type Description

Major Changes affecting the enterprise infrastructure, enterprise services, or services affecting multiple customers and require review and approval by the ADCIO.

Norma l Changes affecting single Service Lines for which the TRB, O&M Management, and Change Managers / Coordinators have responsibility for an approval.

Standard Service Request

Changes that are low risk, frequently occurring, regular and routine in nature, and does not incur additional cost. These requests have pre-defined implementation/installation procedures, comply with the standardized environments, and comply with security management policies, and are pre-approved by a Branch Chief and the TRB.

Table 1: Change Type Matrix

1.4. Operations & Maintenance (O&M) & Development Modernization & Enhancement (DM&E) - Project and Issue Types, Definitions, Approvals, and Requirements

O&M

There are eight ‘Project’ categories to choose from when creating a Change Request in the ITSM tool.

These categories are:

• RD SET (O&M) (RSO)

• RDDE Data Intelligence (RDI)

• Production Support Operations (PSO)

• RD SET O&M SF Reconnect (RSOSFR)

• Standard Service Requests (SSR)

• RD Compliance & Operations (RCO)

• OM Delta (OMDELTA)

• OM Inflation Reduction Act (OM IRA)

A majority of O&M’s ‘Project’ tickets fall under three categories: RD SET (O&M) (RSO), RDDE Data Intelligence (RDI), and Production Support Operations (PSO). For the two ‘Project’ categories, RD SET (O&M) (RSO) and RDDE Data Intelligence (RDI), most ‘Issue Type’ selections are categorized as SET Code Change, SET Data Change and SET Non-Code Change. For the ‘Project’ category, Production Support Operations (PSO), there are several release package categories to choose from but a majority fall under CERT to PROD Deployment Request and Change/Configuration Request.

Further details including the intake process can be found in the Change Management SOP for Submitting Change Requests and Deployment Service Requests in JIRA. Please contact RD Change Management for access (RD.CM@USDA.GOV) and/or questions related to this document.

The Change Management process allows these ‘Project’ and ‘Issue Type’ tickets to follow the automated ITSM tool workflow. These ‘Issue Type’ definitions, approvals and release package requirements include:

• SET Code Change – An application source or code change for any of the following: new functionality, improvement, defect, enhancement, or upgrade to an existing system or a correction due to a previous release package. All Code Changes must have a separation of duties requiring two separate individual(s) to be involved. If one individual is responsible for finding/addressing the issue and testing the fix, it must not be the same individual releasing the change in the Production environment.

Requires TRB approval and the Issue Type/Release Package (CERT to PROD Deployment Request, PROD Only Deployment Request, Mainframe Endevor Deployment Request, Mainframe Non-Endevor Deployment Request, etc. (see Mainframe Releases at the bottom of this section) must include the below requirements before sending to Change Management for approval (if Emergency TRB approval, two business days are given to complete the documentation):

o Cyber Security approval including Application Scan Questionnaire (ASQ) if being released to Production and is scannable o O&M Deployment Decision approval o User Acceptance form digitally signed or email with agreed upon user acceptance including the Project/Change Request and Release type numbers that are listed in the ITSM tool; if Mainframe, Endevor Migration Request with digital User Acceptance Signature is permitted o Test Script form completed with name of tester, date tested, and Project/Change Request number(s) that are listed in the ITSM tool o If Mainframe, digitally signed Library Action form and/or other forms digitally signed dependent upon the application. See Section 1.4 under Mainframe Releases o Deployment Request Instruction form or include applicable instructions in the ITSM tool ticket under “Deployment Notes”

• SET Data Change – An application data change is transparent to the user and requires no change to the source code. Requires TRB approval and the Issue Type/Release Package (CERT to PROD Deployment Request, PROD Only Deployment Request, etc.) must include the below requirements before sending to Change Management for approval (if Emergency TRB approval, two business days are given to complete the documentation):

o O&M Deployment Decision approval o If Mainframe, digitally signed Library Action form and/or other forms digitally signed dependent upon the application. See Section 1.4 under Mainframe Releases o Deployment Request Instruction form or include applicable instructions in the ITSM tool ticket under “Deployment Notes”

• Non-Code Change – Work involving the resolving of an issue that doesn’t require a change to code, configuration, or data. TRB or Change Management approval is not required.

mailto:RD.CM@USDA.GOV

• Change/Configuration Request –A request for an infrastructure change, platform/application configuration change, or an operating system upgrade or patch; does not meet the definition of an application code or data change described in this document. Requires TRB Approval and the release package must include the below requirements before sending to Change Management for approval (if Emergency TRB approval, two business days are given to complete the documentation):

o Deployment Request Instruction form or include applicable instructions in the ITSM tool ticket under “Deployment Notes”

• Cert Only Releases - For the ‘Project’ category, Production Support Operations (PSO) with the Issue Type/Release Package, CERT Only Deployment Request, TRB approval is required. The release package must include the below requirements before sending to Change Management for approval:

tool ticket under “Deployment Notes”

• Mainframe Releases – Includes the above requirements for SET CODE or SET DATA changes and requires the following attachments that are dependent upon the application release. Contact RD Change Management with any questions regarding the completion of these forms. Any Mainframe release scheduled for a Friday turnover, must have the Operation and Scheduling Branch (OSB) consent via email before sending to Change Management for approval.

o Library Action Request o Generation Data Group Index Request (GDG Index Req) o Dictionary Action Request (Dictionary Action Req) o Data Administration Element List (Data Admin Element List) o DB2-DBA Action Request (DB2-DBA Action Req) o Run Request Form (Run Request Form) o Test Script Form (Test Script Template)

Detailed steps on creating all Change Requests and Release Packages including Mainframe in the ITSM tool can be found in the RD Change Management directory of documentation. Please contact RD Change Management for access (RD.CM@USDA.GOV) and/or questions relating to the completion of the forms.

Standard Service Request

Another ‘Project’ category is the Standard Service Requests (SSR) and the Issue Type/Release Package (CERT to PROD Deployment Request, PROD Only Deployment Request, etc.). The Change Management process requires the SSR to follow the automated ITSM tool workflow and the ‘Issue Type’ definition, approvals, and release package requirements include:

• SSR – A change that is a reoccurring maintenance task to ensure continuity of operations; a non-functional configuration change, requires no change to the source code or requires very limited change to the source code that doesn’t impact the running application. Follows documented, repeatable, and established tasks. Does not change or alter a customer’s account value or dollar amount and does not affect how Personally Identifiable Information (PII)/Controlled Unclassified Information (CUI) data is collected, used, pushed/pulled, stored, or accessed. Questions regarding PII or CUI data should be directed to RD Cybersecurity at RDPRIVACY@USDA.GOV. Requires Branch Chief and TRB Approval and the release package must include the below requirements before sending to Change Management for approval:

tool ticket under “Deployment Notes”

Detailed steps on creating Standard Service Requests in the ITSM tool can be found in the RD Change Management directory of documentation. Please contact RD Change Management for access (RD.CM@USDA.GOV) and/or questions.

mailto:RDPRIVACY@USDA.GOV mailto:RD.CM@USDA.gov

DM&E

Development, Modernization, and Enhancement (DM&E) change requests and releases follow a different workflow in the Information Technology Service Management (ITSM) tool and require different approvals and requirements. The System Development Lifecycle (SDLC) 3.0 process guide is the governance of the DM&E process when the initial Change Request and/or Project is created in the ITSM tool. DM&E project requests have their own intake process requiring a Project Review Committee (PRC) for SDLC 3.0 or a Stage Gate Review (SGR) for SDLC 2.0. The Portfolio Management Branch (PMB) also govern their process with the SDLC Information Technology SGR process guide. While the SDLC 3.0 process guide is the governance, the SDLC 2.0 is still being followed for some remaining Change Requests and Projects.

Access to the SDLC process guide and any questions should be directed by contacting PMB at

SM.USDA.RD.PMB (RD.PMB@USDA.GOV).

During the intake for a Change Request, an Operations and Maintenance (O&M) versus DM&E decision rubric may be used to determine the ‘Change Request Type’ in the ITSM tool. This rubric will help determine whether the Change Request Type will follow the O&M versus DM&E workflow. If the Change Request is determined to be DM&E, it is submitted as a DM&E Change Request type, and it will go to “DM&E Backlog Review” status where it will wait for DM&E management direction to proceed. If the Change Request is determined to be O&M, it is submitted as an O&M Change Request Type and will follow the normal O&M workflow for the Technical Review Board (TRB) approval. Additional information regarding the TRB and the rubric is later explained in this document in Section 2.4 and Appendix F.

A DM&E Deployment Service Request (DSR) will follow similar steps as other releases during the intake process in the ITSM tool. However, it has different approvals and requirements.

Release Types for SDLC 2.0 and 3.0

• DM&E SGR Release for work approved under the DM&E SDLC 2.0

• DM&E PRC Release for work approved under the DM&E SDLC 3.0

• DM&E Warranty/Hypercare Release for work approved under the Warranty/Hypercare period

• DM&E Emergency release for work to resolve a production emergency outside the release cycle

DM&E Releases for SDLC 2.0 and 3.0:

A DM&E release is for work approved under the DM&E SDLC 2.0 or 3.0 approval process. These releases cover standard configuration, code, or data changes for the release period.

If a DM&E release needs to be created for work approved under the DM&E SDLC, the Project Manager will choose the appropriate ‘Project Type’ and then choose one of three ‘Issue Types’ in the ITSM tool.

These ’Issue Types’ are DM&E Only – Cert Only, DM&E Only – Cert to Prod, and DM&E Only – Prod Only. The release package must include the below requirements and requires these ‘Issue Types’ to follow the ITSM tool workflow including the appropriate approvals and requirements before sending to Change Management for approval:

• DM&E Only - Cert Only for 2.0:

o Linked to ITSM User Stories, Epics, Capabilities, or Themes, etc.

o Development SGR minutes showing Review Board approval o Deployment Request Instruction form or include applicable instructions in the ITSM tool ticket under “Deployment Notes”

• Cert to Prod or Prod Only for 2.0:

o Linked to ITSM Project Stories, Epics, Capabilities, or Themes, etc.

o Deployment SGR minutes showing Review Board approval o Digitally signed User Acceptance form or an email with agreed upon user acceptance including the Project/Change Request and Release type numbers that are listed in the ITSM tool o Test Script form with name of tester(s), date(s) tested, and Project/Change Request numbers that are listed in the ITSM tool o Cyber Security approval including linking the RD Cyber Security (RS) Application Scan Questionnaire (ASQ) if being released to Production and was scanned o Cyber Security approval of the Security Impact Analysis (SIA) mailto:PMB@USDA.GOV

• DM&E Only - Cert Only for 3.0:

o Linked to ITSM User Stories, Epics, Capabilities, or Themes, etc.

o Deployment readiness meeting minutes, showing PRC approval for the release phase o Deployment Request Instruction form or include applicable instructions in the ITSM tool ticket under “Deployment Notes”

• Cert to Prod or Prod Only for 3.0:

o Linked to ITSM Project Stories, Epics, Capabilities, or Themes, etc.

o Deployment readiness meeting minutes, showing PRC approval for the release phase o Digitally signed User Acceptance form or an email with agreed upon user acceptance including the Project/Change Request and Release type numbers that are listed in the ITSM tool o Test Script form with name of tester(s), date(s) tested, and Project/Change Request numbers that are listed in the ITSM tool o Cyber Security approval including linking the RD Cyber Security (RS) Application Scan Questionnaire (ASQ) if being released to Production and was scanned o Cyber Security approval of the Security Impact Analysis (SIA)

DM&E Warranty/Hypercare Release for SDLC 2.0 and 3.0:

A DM&E release is for work approved under the DM&E SDLC 2.0 or 3.0. These releases cover configuration, code, or data changes, or fixes defects during the Warranty/Hypercare period. The Warranty/Hypercare period is a contractual period for which the vendor will resolve any bug fix related to the change/updated code or make minor enhancements typically for a specified period upon completion of the release.

The Project Manager will specify ‘Warranty/Hypercare Release’ when creating the ticket in the ITSM tool and will choose the appropriate ‘Project Type’ and then choose one of three ‘Issue Types’ in the ITSM tool.

These ’Issue Types’ are DM&E Only – Cert Only, DM&E Only – Cert to Prod, or DM&E Only – Prod Only. The release package must include the below requirements and the ‘Issue Types’ must follow the ITSM tool workflow including the below approvals before sending to Change Management for approval:

• DM&E Only - Cert Only for 2.0:

o Linked to ITSM User Stories, Epics, Capabilities, or Themes, etc.

o Deployment SGR minutes showing Review Board approval o Deployment Request Instruction form or include applicable instructions in the ITSM tool ticket under “Deployment Notes”

• DM&E Only - Cert to Prod or DM&E Only - Prod Only for 2.0:

o Linked to ITSM User Stories, Epics, Capabilities, or Themes, etc.

o Deployment SGR minutes showing Review Board approval for the related DM&E release that the Warranty/Hypercare release is related to in the ITSM tool o Email approval from the SDD Director approving the deployment o Digitally signed User Acceptance form or an email with agreed upon user acceptance including the Project/Change Request and Release type numbers that are listed in the ITSM tool o Test Script form with name of tester(s), date(s) tested, and Project/Change Request numbers that are listed in the ITSM tool o Cyber Security approval including linking the RD Cyber Security (RS) Application Scan Questionnaire (ASQ) if being released to Production and was scanned o Deployment Request Instruction form or include applicable instructions in the ITSM tool ticket under “Deployment Notes”

• DM&E Only - Cert Only for 3.0:

o Linked to ITSM User Stories, Epics, Capabilities, or Themes, etc.

o Deployment readiness meeting minutes, showing PRC approval for the release phase

DM&E Only - Cert to Prod or DM&E Only - Prod Only for 3.0:

o Linked to ITSM User Stories, Epics, Capabilities, or Themes, etc.

o Deployment readiness meeting minutes, showing PRC approval for the release phase o Email approval from the SDD Director approving the deployment o Digitally signed User Acceptance form or an email with agreed upon user acceptance including the Project/Change Request & Release type numbers listed in the ITSM tool o Test Script form with name of tester(s), date(s) tested, and Project/Change Request numbers that are listed in the ITSM tool o Cyber Security approval including linking the RD Cyber Security (RS) Application

Scan Questionnaire (ASQ) if being released to Production and was scanned

• Combined DM&E & O&M release for auditing and contractual purposes includes the requirements for these types of releases:

If an O&M release includes code modified by the DM&E team, link to applicable O&M approvals.

DM&E code to include for 2.0:

o Link to the User Stories for which the code change was completed o Deployment SGR minutes showing Review Board approval o Email approval from the SDD Director approving the deployment

DM&E code to include for 3.0:

o Link to the User Stories for which the code change was completed o Deployment readiness meeting minutes, showing PRC approval for the release phase o Email approval from the SDD Director approving the deployment

O&M code to include:

o All applicable approvals and requirements

If a DM&E release includes code modified by the O&M team, link to applicable DM&E approvals.

DM&E code to include:

o All applicable approvals and requirements

O&M code to include:

o Link to TRB approved code or data change request o Email approval from the SED Director approving the deployment o Deployment Request Instruction form or include applicable instructions in the ITSM tool ticket under “Deployment Notes”

DM&E Emergency Release:

A DM&E Emergency Release is for a defect or enhancement break-fix in Production during the warranty period that cannot wait for the next Warranty/Hypercare Release.

The Project Manager will state ‘Emergency Release’ when creating the ticket in the ITSM tool and will choose the appropriate ‘Project Type’ and then choose one of three ‘Issue Types’ in the ITSM tool. These ’Issue Types’ are DM&E Only – Cert Only, DM&E Only – Cert to Prod, or DM&E Only – Prod Only. The release package must follow the normal release package requirements outlined in this document and these ‘Issue Types’ must follow the ITSM tool workflow including the appropriate approvals before sending to Change Management for approval.

This process should follow the Emergency Release path as outlined in this document with the exception that instead of TRB approval, the release requires joint sign-off from the SDD Director, SED directors and ACIO via email or comments in the ticket in the ITSM tool. All applicable approvals and documentation should match that of the above DM&E Warranty/Hypercare release listed in the document.

Access to the SDLC and any questions should be directed by contacting PMB at SM.USDA.RD.PMB (RD.PMB@USDA.GOV). See Appendix A for a quick start reference and process guide on these types of O&M and DM&E Change Requests and Releases.

1.5. Exceptions

All changes for both O&M and DM&E are managed and approved through the Change Management process described in this document. If this process cannot be followed an exception approval email from the SED Director (or their acting) for an O&M release or the SDD Director (or their acting) for a DM&E release is required. Once the exception is granted, Change Management will process the change and document the approved exception. Two business days will be given to complete the required documentation described in this guide.

Exceptions shall also include DM&E releases for Salesforce community shells. These releases require only an email approval from the PMB Branch Chief in lieu of an SGR or PRC approval. Change Management will process the change and document the exception noting the email approval is the only requirement.

1.6 Document and Process Review and Update

This document will be reviewed and updated semi-annually each May and November by Change Management with designated O&M and DM&E members. The management and modification of this document is governed by the RD Technology Office Production Support and Operations ChM Process.

Direct any questions or comments concerning this document to RD Change Management or the Production Support Operations Branch Chief.

2. Process Overview

2.1. Goals and Objectives

Ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, to minimize the impact of change-related incidents upon service quality and to improve the day- to-day operations of the organization. This includes all changes made to IT services and service components. This process ensures that appropriate change request details are accurately recorded.

The objectives of the ChM Process are to:

• Control IT infrastructure changes through standardized repeatable methods and procedures.

• Support the efficient and effective handling of change requests.

• Provide accurate and timely information on change requests.

• Minimize the negative impact of changes on the IT environment and operations.

• Reduce incidents and problems caused by change requests.

• Provide accurate assessment of the cost of proposed change requests before they are incurred.

• Improve the quality of IT services.

2.2. Relationships to Other Processes

All ITIL process areas are interrelated. Those processes most closely related to the Change Management Process are Release and Deployment Management (RDM) and Configuration Management (CfM). The ChM, RDM, and CfM Process interrelationships are depicted in Figure 1.

mailto:rd.pmb@usda.gov

Figure 1: Relationships between ChM, RDM, and CfM Processes

Release and Deployment Management

• Approved Changes: RDM awaits approval of change requests prior to development, testing, and deployment. An approved change request includes deployment and back out plans.

• Release Results: The ChM Process does not finish when a change is incorporated into a release.

The RDM Process provides the ChM Process with key outcomes throughout the release cycle, such as gate reviews at specific points in the RDM process and any issues arising from testing or deployment of changes. This information is used by ChM to determine follow-on actions, which may include the backout of changes and Post Implementation Review. A Post Implementation Review is initiated at the discretion of ChM and Project Manager.

• All software releases and mainframe elements are built and tracked in various ITSM tools. If access is needed for any of the ITSM tools, please email the RD Help Desk (RD.HD@USDA.GOV).

Please include the access required in the subject line and other necessary information for a ticket to be created on your behalf.

Baseline Configurations, Configuration Management Controls and Security

• Rural Development tracks in the ITSM tool and on SharePoint application baseline configurations for code sets, data sets, non-code changes, configuration hardware and software version changes.

On SharePoint, this data can be found with one folder for each app which includes each app’s data sheets and consolidated information including both the AHPS and Visio diagrams, respectively. If access is needed, please email the RD Help Desk (RD.HD@USDA.GOV). Please include the access required in the subject line and other necessary information for a ticket to be created on your behalf.

• Rural Development utilizes Bitbucket software as the database repository for code management.

RD utilizes GIT (Global Information Tracker) as a VCS (version control system). GIT is an open-source distributed version control system designed to handle anything from small to large projects with speed and efficiency. PFCS (Program Funds Control System) is currently not storing code management in the BitBucket database repository. As of January 2023, PFCS source code along with migration instructions are stored in a directory on a shared drive. Data remains forever in this directory and code changes are retained for one year. During fiscal year end after October 1st each year, each instance will get cloned to Production at that time. If access is needed for PFCS, please email the RD Help Desk (RD.HD@USDA.GOV). Please include PFCS in the subject line and other necessary information for a ticket to be created on your behalf.

• RD management and customers are reviewing all current applications to ensure:

o BitBucket is being utilized as a database repository for code management and o Guidelines are being reviewed to ensure proper term length for code retention

• Additional procedures for both DM&E and O&M Branching and Merging concepts and version control for code support can be found by emailing the RD Help Desk (RD.HD@USDA.GOV).

Please include access required in the subject line and necessary information for a ticket to be created on your behalf.

• To increase traceability, all source control changes that occur in Bitbucket will reference all corresponding ITSM tool ticket IDs as part of each commit. Operational roles are identified in both DM&E and O&M Branching guide concept documents and lists specific instructions to support the code development. These guidelines are documented, formally reviewed, and agreed-upon by management on a yearly basis and when information systems change over time.

• In case of a failed code change, RD would reconfigure as needed or will open a ticket in the ITSM tool to address the issue. Each application will be brought up by RD who will then reconfigure as needed utilizing GIT as a VCS and checked back into Bitbucket. A list of all RD’s applications can be found in Appendix B.

Change Management

Release Results

Approved

Changes

Release Management

Approved Changes

Updates to Services

Service Relationships

Configuration Management Service

Relationships mailto:RD.HD@USDA.GOV

• RD’s Mainframe system does not utilize Bitbucket. However, Mainframe changes and data are held live on the Mainframe system and made through Endevor. Endevor is utilized as a configuration management system for the Mainframe.

• Change Management implements their Configuration Management & Security policies and procedures following the National Institute of Standards & Technology for Configuration Management of Information Systems (NIST SP 800-128) & USDA DR 3520-002.

• Any questions regarding RD Security polices and/or for general information, may be sent to:

O Information Assurance at RDSECURITYENGINEERING@USDA.GOV o Incident Response Team at MOSTLIRT@USDA.GOV o Privacy at RDPRIVACY@USDA.GOV

2.3. High-Level Process Model

The ChM Process consists of five distinct sub-processes and integrates with the Release and ChM Processes. The workflow in Figure 2 depicts the process activities that collectively enable and underpin the ChM Process. For additional details, see Appendix C: Change Management Procedures.

End User IT Support Group

1.0 Record

Incident Management

2.0 Review

3.0 Access and

Approve

4.0 Coordinate

5.0 Close

End

Configuration Management

DM&E SDLC/Project Lifecycle

Release and Deployment

Management

DM&E

DM&E

O&M

Figure 2: Change Management Process Flow mailto:RDSECURITYENGINEERING@USDA.GOV mailto:MOSTLIRT@USDA.GOV mailto:RDPrivacy@USDA.GOV

Table 2 below contains descriptions for each of the ChM Process activities.

Number Process Activity Description

1.0 Record A change request is submitted through approved channels. Information pertinent to the change request is required to accurately select the change type as well as to categorize and prioritize the change request. This classification also aids in determining the approval authority for the request.

2.0 Review Information regarding a change request is reviewed to determine whether sufficient information is available to deem the change request is complete and consistent with current documentation standards. This information may be included in the change request directly or in the accompanying supporting documentation.

3.0 Assess and

Approve

The Technical Review Board reviews the change request and accompanying supporting documentation for accuracy, validating the change type. Based on the change request’s change type, it is directed to the correct approval authority. Recommendations regarding the change request are provided prior to adjudication.

4.0 Coordinate A change request is coordinated with Release Management to ensure that the requirements of the change request (customer requirements, IT requirements, security requirements, scheduling, resource demands, etc.) are fully addressed.

As the change request is implemented, ChM verifies that it is stable within the IT environment.

5.0 Close After successful implementation of a change request, a Post Implementation Review may be conducted in specific circumstances to determine ‘lessons learned’ from the change implementation. A Post Implementation Review can be initiated at the discretion of ChM and Project Manager. The review is used to identify strengths, weaknesses, successes, and issues including:

• Potential ChM process improvements

• Mitigation of issues with similar future changes during the development and deployment of the change, and schedule and resource concerns.

Table 2: Change Management Process Activities

2.4. Process Description

The Technical Review Board assesses all O & M proposed changes to the IT infrastructure. These changes are submitted as change requests and reviewed. All O&M change requests must be reviewed, assessed, and approved prior to the change being introduced into the environment. All DM&E change requests must be approved prior to the change through the SDLC review process described in Section 1.4 in this document.

Change Requests are triaged on whether it is an O&M vs. a DM&E Change Request Type before the change request is submitted to the TRB by the Reporter. The O&M vs. DM&E Decision rubric is used in the triage process to assist in making that determination (Appendix F). If it is determined and voted on by the TRB to be an DM&E request, the request will go to “DM&E Backlog Review” status where it will wait for DM&E management direction to proceed. If it is determined and voted on by the TRB to be an O&M request, the request will follow the O&M workflow process. If the TRB is unable to decide on whether a change request is O&M vs. DM&E, the Systems Engineering Division Director will make the final approval. The level of approval, responsibility, and information necessary for change request review and assessment is based on this rubric. The review and assessment criteria may also include the impact, urgency, and priority of the change. Assessment information may include backout strategies, security concerns, implementation challenges, and cost estimates. Further information on the impact, urgency, and priority may be found in Appendix G.

For most changes, once an assessment of the change has been completed, the approval for the change request is provided by the approval authorities. Input is provided to the Technical Review Board (TRB) by Subject Matter Experts (SMEs) to ensure that all members fully understand the specifics of the change request. Examples of supporting documents that may be necessary are listed in Appendix E: Referential Documentation.

After implementation, ChM notifies pertinent stakeholders and performs any necessary Post Implementation Review prior to closing the change request.

2.5. Critical Success Factors and Key Performance Indicators

Critical Success Factors (CSFs) are defined as process or service-specific goals that must be achieved if a process or service is to succeed. Key Performance Indicators (KPIs) are used to gauge the effectiveness of the service or process performance or progress toward achieving defined CSFs. Metrics are used to measure performance against stated KPIs and describe how measurement is to occur. CSFs and KPIs are determined from input by the client, governing bodies, and industry best practices, and are reported to leadership.

The CSFs and KPIs listed in Table 3 are used to gauge the effectiveness and efficiency of the ChM Process.

The analysis of these CSFs and KPIs are input into assessing current state against a baseline and identifying potential improvement opportunities.

Critical Success Factor Key Performance Indicator

Metric

Changes are processed in a timely manner:

Determines the timeliness and efficiency of the ChM Process by reviewing number of open changes and the length of time before a change request is approved.

Change Request aging Average number of days between change request submission and change request approval

Change Request processing time

Average number of days, by change type, between change request approval and change request closure

Compliance to the change process:

Determines the effectiveness of the process by demonstrating the number of rejected change requests, tracking the trends in the monthly change request totals, and demonstrates the level of adoption throughout the enterprise via the number of changes made outside the process.

Submitted Change Requests

Total number of change requests opened during a reporting period

Rejected Change Requests

Percentage of change requests rejected after initial submission for insufficient information

Unauthorized changes Number of discovered unauthorized changes implemented outside of the change and release management processes

Table 3: Change Management CSFs and KPIs

3. Technology Office Change Type Definition and Approvals Levels of approval are commensurate with change type determined by multiple factors that a change may pose to the environment. Requests are created in the ITSM tool for Change Requests, Deployment Service Requests, Standard Service Requests, Incidents, and Projects. Approval levels are established as guidelines to place the decision making at the appropriate level, and as such may be changed or adjusted if additional information is identified. Table 4 briefly describes these approvals.

Change Type Typica

Approval Level

Descriptio n

Major SED Director Changes affecting the enterprise infrastructure, enterprise services, or services affecting multiple customers and require review and approval by the SED Director.

Norma l O&M & PSO Management

Changes affecting single Service Lines for which the TRB, O&M Management, and Change Managers / Coordinators have responsibility.

Standard Service Request

Branch Chief and TRB

Changes that are low risk, frequently occurring, regular and routine in nature, and does not incur additional cost. These requests have pre- defined implementation/installation procedures, comply with the standardized environments, comply with security management policies, and are pre-approved by the Branch Chief and the TRB.

Table 4: Change Type and Approval Matrix

3.1. Technical Review Board

The Technical Review Board (TRB) exists to support the approval of changes and to assist ChM in the assessment. The Technical Review Board Charter outlines the authority of the TRB and the process. Access to the TRB Charter and the TRB Member List can be obtained by contacting RD Change Management

(RD.CM@USDA.GOV).

The Change Manager/Coordinator submits the change request to be approved to the TRB Chair to be added to the agenda for the next meeting. The administrative functions of the TRB are described in detail in the Technology Office TRB Charter.

When a TRB is convened, in addition to the members defined in the Charter, attendees should be invited who can ensure that all changes within the scope of the TRB are adequately assessed. To achieve this, the TRB needs to include people with a clear understanding across the entire range of stakeholder needs. It is important to emphasize that the TRB:

• Is composed according to the changes being considered. SMEs are invited to attend as needed to support a change.

• Should involve stakeholders as attendees when necessary.

• Should reflect both users’ and customers’ views.

• May include external customer liaisons for at least part of the time.

This is intended to ensure that the composition of the TRB will be flexible, to represent business interests when changes are proposed. It will also ensure that the composition of the Emergency TRB (ETRB) can provide the ability—from a business perspective and from a technical standpoint—to make appropriate decisions in any conceivable eventuality.

Technical Review Board (TRB) – Consists of representatives from all functional areas:

• Data Engineering Representative/SME

• Enterprise Architecture Representative/SME

• Help Desk Representative/SME

• Quality Assurance Representative/SME

• Production Support Operations Representative/SME

• Cyber Security/Privacy…