Change Management Policy

Policy Owner: Manager, Performance Achievement

Policy Sponsor: ITSM Steering Committee

The policy owner has the responsibility and authority to execute and monitor the defined and established Change Management process.

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

This policy provides the formally documented expectations and intentions used to direct decision making and ensure consistent and appropriate development and implementation of processes, standards, roles, activities, etc., with regard to this policy.

1. PURPOSE

The purpose of this policy is to ensure that any changes to the Postal Service Technology Environments are managed through an established process.  USPS will utilize the best practice framework (i.e., ITIL) for the implementation of Change Management within the Postal Service Technology Environments. 

Change Management is the process that controls the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.
The goals of the Postal Service Change Management policy include the following: 

• Establish and enforce a standard process for planning, approving, implementing, and reporting changes to Postal Service Technology Environments.

• Establish clearly defined best practice processes to ensure compliance with PCI, SOX, and other legal or regulatory requirements.

• Prevent or minimize risks to the Postal Service Technology Environments from the change request being implemented.

2. SCOPE

This policy applies to all Postal Service personnel and contracted vendors involved in activities that cause or require changes to technology solutions within the Postal Service Technology Environments.

This policy also applies to those IT environments designated by the ITSM Steering Committee, including, but not limited to, applications, data, network, platforms, middleware services, computing facilities, and systems management. The Change Management policy also applies to the design, configurations, and parameters.

3. POLICY

The following policy is established for Change Management:

• All USPS IT organizations must use the currently approved documented change management process to document, prioritize, control and approve all technology solution changes and will be reported, recorded, managed and appropriately communicated through the approved Change Management tool.

1. A change request is required for any change to the environment(s) that are subject to the policy as designated by ITSM Steering Committee. 

2. Modifications that alter the original scope of a submitted change request are not permissible. In the event a task or change related item needs modification within the original scope, management approval is required. 

3. A change request must be submitted in a complete format with a defined scope, implementation date and time, and instructions.  “Umbrella” and “placeholder” change requests are not accepted.

4. A back out plan is required for all production changes.

5. The implementation plan must provide step-by-step procedures which state the necessary details on how to implement a change. An implementation plan must refer to the back-out plan and must include a communications plan which may include IT and business contacts.

6. Changes that have a direct impact to business operations need to have business notification and/or approval through normal communications.

7. All Cfg-Item changes require updating the CMDB and conforming to the configuration management policy and process.

• Prior to gaining initial access to the Change Management tool, individuals must complete appropriate training that is designated to their Change Management role.

• This policy will complement and not supersede compliance policies such as CIRT, SOX, PCI, and TSLC.

4. EXCEPTIONS

Any requests for exceptions to this policy must be submitted in writing and will be reviewed on a case by case basis. Exceptions shall be permitted only after documented approval from the ITSM Steering Committee.

5. POLICY COMPLIANCE AND MONITORING

Change Requests (CRs) will be audited on a periodic basis by the Change Management team for policy compliance.

The appropriate IT executive manager will be notified of any individual who violates the policy and may be subject to review and further actions.

6. POLICY REVIEW

The Change Management Policy will be reviewed on the following basis:

• Annually, by the Change Management Process Owner
• Upon an update to the Change Management Process and/or tool
• Upon request of the ITSM Steering Committee

7. DEFINITIONS

• Back Out Plan: A plan used in the event that a change moved into production causes unwanted results and the system must be returned to a previous functional version to restore business operations.
  

• Change Management: Controls the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.
  

• Change Request (CR): A formal request for change to any component of an IT infrastructure or to any aspect of an IT Service which is to be made to the USPS IT Production Environment.
  

• CMDB: A CMDB is an abbreviation for the term “Configuration Management Database” which is used, to store configuration records throughout a lifecycle. The configuration management system maintains one or more configuration management databases, in which; each database stores attributes of configuration items, and the relationships with other configuration items.
  

• Configuration Item (Cfg-Item): A Cfg-Item is an abbreviation for the term “Configuration Item” which refers to any service asset component that needs to be managed in order to deliver an IT service. Information about each Configuration Item is recorded in a configuration record within the configuration management system and is maintained throughout its lifecycle by service asset and configuration management. Configuration Items are under the control of change management. They typically include IT services, hardware, software, buildings, people and formal documentation, such as process documentation and service level agreements.
  

• CI (Critical Incident): A CI is an abbreviation for the term “Critical Incident” which refers to the highest priority assigned to an Incident. A Critical Incident is defined as an incident whose impact involves any one of the following:  is extensive or widespread, affects multiple locations, potential significant loss of revenue, or potential significant impact to other business operations with no workaround available. The target for restoration for this priority is As Quickly As Possible (AQAP) or no longer than 2 hours.
  

• Documentation: Documentation that affects Configuration Items that are in-scope for IT Service Management or governance of IT Service Management. For example, TSLC artifacts are not in- scope, but enterprise release management documented processes are in scope.
  

• In-Scope Environments & Applications: Pertains to those environments and/or applications, regardless of parent environment, that are subject to the change management policy and associated processes.
  

• ITSM Steering Committee: An executive body responsible for the guidance and direction of USPS IT Service Management.
  

• Implementation Plan: A detailed plan explaining the activities necessary to implement the change request into the production and/or CAT environment.
  

• Production Environment: All system, process and documentation components used in IT production and CAT systems and any other production equivalent environment.

8. SUPPORTING DOCUMENTATION

• Change Management Process
• Change Management Escalated Approval Process

For access to the following documents, contact the US Postal Service. See Publication 5, Let's Do Business for further information about local US Postal Service contacts.

• Change Management Tool User’s Guide
• Change Management Prioritization Matrix
• Change Request Requirements for DEV, CAT and Production
• Compliance Documents for CIRT
• Compliance Documents for TSLC and SOX

9. REVISION HISTORY