IT/PPS 01.05 - Information Technology - Change Management Policy

POLICY STATEMENT

Texas State University is committed to the effective management and communication of updates, maintenance, and regular releases to help minimize customer impacts.

1. SCOPE

   1. Information Technology (IT) change management is the process of planning, testing, coordinating, and implementing changes to the production environment. The goal of change management is to minimize the risks involved in introducing changes to the production environment, thereby maximizing the availability of services to the customer.

   2. The purposes of the change management process are to reduce unplanned service outages, communicate system changes to IT departments, and provide a documented and efficient process for IT staff to follow.

2. DEFINITIONS

   1. Change – action to modify the state of or implement a new production application or environment.

   2. Change Advisory Board (CAB) – a group of IT staff who vote to approve or deny requests.

   3. Change Management (CM) System – an application built to acquire approval to make changes, track the changes, and create an audit trail.

   4. Change Request – a request made when a change is needed. This request is the starting point for all changes.

   5. Creator or Requestor – the individual who originates a request in the CM system.

   6. Customer Request – a document representing the request made by the customer.

   7. Customer Signoff – a document representing the customers’ affirmation that they have tested the change in a test environment or otherwise assent that it meets the need expressed in the original request.

   8. Expedited Change Requests – a request for a change that is time-sensitive and may have been carried out previously to prevent interruption of a service, corruption of data, or exposure of a critical bug.

   9. IT CAB – contains representatives from the IT organization to ensure a high level of visibility and vote to approve or deny release requests and master standards.

   10. Master Standard – a description of a routine, low-risk change carried out by a team. Once approved, these changes are available for selection in standard change requests.

   11. Normal Change Request – the default change request type. These change requests must be approved by a team CAB before work can begin in a test environment.

   12. Production Environment (PROD) – the setting where software and other products are put into operation for their intended uses by end-users.

   13. Release – the act of carrying out a change in a production environment.

   14. Release Request – a request to make a release into production.

   15. Standard Change Request – a change request referencing an approved, master standard.

   16. Team CAB – assigned to each technical team and vote to approve or deny the team’s normal change requests before work in the test environment can begin.

   17. Test Environment (Test or Qual or Dev) – an environment used for testing before migration to production.

   18. Vote – an individual response by a CAB member to a request.

3. PROCEDURES FOR NORMAL CHANGE

   1. The creator or requestor submits change requests via the CM system and attaches the customer request if the change involves a customer.

   2. Submitting the change request automatically triggers the change to the status of ‘review,’ where voting will take place by the team CAB.

   3. The creator or requestor is notified once all team CAB approvals are obtained.

   4. Once all team CAB approvals are obtained, the change will be moved to a status of ‘approved;’ then changes in the test environment can officially occur.

   5. Once testing is complete, the creator or requestor will create a release request for that specific change.

      1. If a customer is involved, customer sign-off must be attached to the release request.

      2. Multiple release requests may be created under one change request.

   6. Submitting the release request automatically triggers the release to the status of ‘review’ where voting will take place by IT CAB.

   7. Once all IT CAB approvals are obtained, the creator or requestor is notified, and the change can be migrated to the PROD.

   8. Once the work has been migrated to the PROD, the release report will be completed.

   9. When the release is closed, the creator or requestor will have the option to close the change request or leave open for additional releases.

4. PROCEDURES FOR STANDARD CHANGES

   1. Standard changes are created by selecting a pre-approved master standard.

   2. Submitting a standard change request automatically triggers the change to the status of ‘approved.’

   3. Once testing is complete, the creator or requestor will create a release request for that specific change.

   4. Submitting the release request will automatically trigger the release to the status of ‘approved.’

   5. Once the work has been migrated to PROD, the release report will be completed.

5. PROCEDURES FOR EXPEDITED CHANGE

   In the event a required automatic control fails, and a temporary mitigating control must be put in place, the Mitigating Control Procedure Checklist must be completed prior to expediting the change.

   1. The creator or requestor submits an expedited request via the CM.

      1. Expedited changes may be implemented in PROD prior to submitting a change request.

      2. Customer requests and signoffs are still required for an expedited change request if a customer is involved.

   2. Submitting an expedited change request automatically triggers the change to the status of ‘approved.’

   3. Once testing is complete, the creator or requestor will submit a release request for that specific change.

   4. Submitting the release request automatically triggers the release to the status of ‘approved.’

   5. Once the work has been migrated to PROD, the release report will be completed.

6. PROCEDURES FOR PRODUCTION-ONLY CHANGE

   It is possible to have a production-only change for all change types (normal, standard, and expedited). If a normal change can only be made in a PROD, this will be notated on the change request, and the request will skip team CAB approvals and go straight to IT CAB approvals for PROD.

   1. The creator or requestor submits a change request via the CM System and designates the change as PROD-only.

   2. Submitting a change request that is designated as PROD-only will automatically trigger the creator or requestor to create a release request for that specific change.

   3. Submitting the normal release request automatically triggers the release to the status of ‘review,’ where voting will take place by the IT CAB.

   4. The creator or requestor is notified once all IT CAB approvals are obtained.

   5. Once all IT CAB approvals are obtained, the release will automatically go to a status of ‘approved’ and can be migrated to PROD.

   6. Once the work has been migrated to PROD, the release report will be completed.

7. CHANGE MANAGEMENT SYSTEM DATA LIFE CYCLE

   1. Data related to completed change requests, and their associated releases, will be retained for one year from the closure date of the change.

8. REVIEWERS OF THIS PPS

   1. Reviewers of this PPS include the following:

      Position	Date
      Associate Vice President for Technology Resources	March 1 E5Y
      Chief Information Security Officer	March 1 E5Y
      Vice President for Information Technology	March 1 E5Y

9. CERTIFICATION STATEMENT

   This PPS has been reviewed by the following individuals in their official capacities and represents Texas State Information Technology policy and procedure from the date of this document until superseded.

   Associate Vice President for Technology Resources; senior reviewer of this PPS

   Vice President for Information Technology