Change Management Process

PURPOSESCOPECHANGE CLASSIFICATIONSPROCESSSUPPORTING DOCUMENTATIONREVISION HISTORY

Process Owner: Manager, IT Performance Achievement

Note: An owner must be a PCES-level manager.

PURPOSE

This process is to establish standard Change Management Processes for creating, reviewing, approving, scheduling, and implementing changes within the Postal Service Technical Environment.

United States Postal Service Change Management Process is a structured approach to managing changes. Changes are defined as modifications to the existing United States Postal Service technical components or the introduction of new components to the Technical Environment (business applications and/or system hardware, software, or networks).

PROCESS DESCRIPTION

Change Management is the process that controls the life cycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services and business goals.

The goals of the United States Postal Service Change Management Process are to respond to:

BENEFITS

The benefits of a centralized USPS IT Change Management process are as follows:

Three focus points for IT Change Management are based on people, process, and technology.

SCOPE

The Change Management Process applies to all United States Postal Service employees, contracted vendors, and organizations that introduce or implement changes to the United States Postal Service Technical Environment. It ensures technological changes occur in a uniform and predictable manner. This document is used in conjunction with all IT and Security Policies, Processes, and Standards, including those listed in the Supporting Documentation section.

The scope of the United States Postal Service Change Management Process includes managing the:

CHANGE CLASSIFICATIONS

The Type field in the current Change Management tool will determine how a CR moves through the stages of the Change Management Process. All approvals must be completed prior to implementation unless stated otherwise in the table below.

Type Definition

Applicable Environment(s)

Normal Change
(Scheduled)

A regular change that goes through the entire Change Management process with an implementation scheduled start date of 7 calendar days or greater.

Normal CRs must be fully approved and assigned to implementation team(s) at least two business days before scheduled implementation start date/time.

All
Latent Change Unauthorized/undocumented changes that are discovered after implementation in the Postal environment and require a CR.

Example: These changes are discovered in audits, production environment service disruptions, or Configuration Management Database (CMDB) Auto Discovery.

Latent Change type is not a selectable option in the Type field. This type is enforced in the tool when the planned start date is selected before the current date. A notification is sent to the Requesting Group stating this is a Latent Change.

All
Standard Change
(Special Request)
These changes are for a pre-existing, repetitive function and are on a preapproved standard change request list.

Examples: Reprint report, update JCL instructions, prose, or notifications.

Note: All CRs that impact the PCI Cardholder Data Environment (CDE) require approval and may not be submitted as a Standard Change Request.

All
Expedited Change
(Unscheduled)

A change that must be implemented in less than 7 calendar days.

Expedited CRs must be fully approved and assigned prior to implementation start date/time.

All
Emergency Change A change deemed critical to business continuity and derived from a critical incident. Must be implemented within 8 hours and fully approved within 2 business days of creation. PROD

PROCESS

The Change Management Process consists of the following high-level activities specifically developed to manage the life cycle of change requests. This Change Management process describes Normal Changes. Listed below is a summary of each activity.

  1. Create a Change Request (CR). The Requestor enters all of the required information in the approved IT Service Management tool. This may include, but is not limited to:

    • Associating the CR with related CR(s), Incident(s), and/or Problem Ticket(s).

    • Providing appropriate information so the Configuration Item can be updated.

  2. Review the CR. The Change Manager reviews the new CR and validates the details in the CR.

  3. Schedule and authorize the CR. The Change Manager, in conjunction with the Approvers, schedules the CR and provides approvals.

  4. Implement the CR. The Implementer(s) perform the tasks necessary to complete the CR.

  5. Close the CR. The Change Manager or Change Coordinator closes the CR when all activities have been completed.

  6. Update associated tickets and Configuration Items. The Change Manager updates:

    • Any CR, Incident, and/or Problem Ticket(s) that are associated with the CR.

    • Configuration Items, as appropriate.

  7. Perform a Change Audit. The Change Manager reviews selected CRs to ensure that those CRs include all of the required information and approvals.

  8. Perform a Post Implementation Review. All stakeholders review the closed CR to ensure that it was implemented appropriately, as required.

SUPPORTING DOCUMENTATION

Access Supporting Documentation from ITWEB (internal):

Access Supporting Documentation from USPS.com (external):

REVISION HISTORY

Version
Date
Description
1.0 No date Initial release.
2.0 07.20.2010 Supporting Documentation: Removed the "Change Quick Reference Guide" link from Quick Reference Materials as requested.
3.0 FY12/Q3 This document was made Section 508 compliant and was converted to HTML.
4.0 07.19.2013 Rewritten to remove tool-specific references and updated to address SOX and PCI compliance requirements.
4.1 08.05.2013 Updated Description column in table as follows:
  • Added Applicable Environments for all change classes.
  • Standard Change:
    • Changed Definition from "A recurring change that is for executing a pre-existing preapproved function. These changes are on an approved documented list." to "A change request that does not affect production applications and/or infrastructure. These changes are for a pre-existing, repetitive function and are on a preapproved standard change request list."
  • No Impact Change:
    • Changed Definition from "A change that is required to follow the Change Management Policy but does not affect the IT production environment." to "A change request for non-production environments."
    • Removed example: "Note: Production Equivalent Changes (DEV, SIT, CAT, Training) and Remedy Foundation data."
    • Removed note: "Note: All approvals must be completed prior to implementation."
  • Expedited Change:
    • Removed note: "Note: Any implementation group that approves is also accepting the risk and impact of implementing this change request. In addition, all approvals must be completed prior to implementation."
4.2 08.09.2013 Added link to IT Reporting / Helpful Links.
4.2.1 06.26.2015

Annual Review: The annual review for functional accuracy and current PCI DSS requirements has been completed. CR 84436.

Non-substantive updates:

  • Link to IT Self Help replaced by link to ServiceNow
  • Link to IT Reporting / Helpful Links replaced by link to ServiceNow Change Management User Guide
  • Link to retired Configuration Management Standards deleted
4.3 11.06.2015

Annual Review: The annual review for functional accuracy and current PCI requirements has been completed. CR 122936.

Change Classifications:

  • Changed "Class" to "Type" to reflect current functionality.
  • Removed "No Impact" as it is no longer a valid classification of change.
  • Updated environments to align with current practices.

Process: Added "as required" to Post Implementation Review step.

Support Documentation: Added "Create a Change Request for PCI In-Scope Changes" procedure.

4.4 05.16.2016

Supporting Documentation: Added ServiceNow – Change Management Approval Matrix.
Classification / Change Types table: Added further clarification to the Normal, Latent, Standard, and Expedited Change Types.

4.4.1 06.09.2016 Non-substantive update: Updated the hyperlink to Create a Change Request for PCI In-Scope Changes.
4.4.2 07.22.2016 Annual Review: The annual review for functional accuracy and current PCI requirements has been completed. CR 195809