Enterprise Application Services (EAS) Change Management Policy

Change Management Concept

Change Management is an IT Service Management discipline whose goal is to reduce the risk of incidents when changes are made to the IT infrastructure. Change Management reduces risk through the use of standardized procedures to document and implement change.

Policy Purpose and Benefit

The EAS Change Management Policy defines the standardized procedures to be used when changes are made to the University’s administrative software. When this Policy is followed, the risk of incidents is reduced and the integrity of the University’s business operations and reporting is preserved. Without Policy formality, the risk of incidents would be higher and accountability for software changes would be insufficiently documented.

Role of Policy Participants

  1. Successful change requires the engagement and participation of all the people involved. This Policy assigns responsibilities to Departments and EAS according to the principle role each serves.
  2. Departments act as owners of the University’s business data that is entrusted to their individual missions. Departments are responsible for their data’s content and usage; therefore, Departments initiate software proposals and decide whether the software should be installed.
  3. EAS is an IT service bureau that provides support to Departments in the form of software development, software installation, and consultation.

Software Governed by this Policy

  1. The word “change” applies to new software and modified software.
  2. This Policy is applied to all administrative software that is maintained by EAS; this includes vendor-supplied software as well as EAS-developed software.
  3. This Policy is applied to all types of software: reports, processes, forms, and Oracle scripts.

Project Tracking System

  1. The EAS Project Tracking System is a tool used by Departments and EAS to manage software changes. It defines the procedures for enforcing this Policy: project creation, software development, testing, project approval, and installation.
  2. The Project Tracking system automatically notifies the person responsible for an action required to move the project to its next stage.
  3. The Project Tracking System may be queried to view current project status.
  4. EAS uses the Project Tracking System internally to manage vendor upgrades; see the section below, “Vendor Software Upgrades”.

Project Creation

  1. The Department identifies a need to improve the processing for a particular business function.
  2. The Department Requestor shall prepare a software request for EAS that adequately and clearly states the specifications for the change. The request should explain the business purpose to be supported by the software.
  3. The EAS Software Developer shall create a project for the request in the Project Tracking System.
  4. The project’s tracking entry includes the names of the Department Requestor and Approver and the EAS Software Developer, and a description of the specifications.
  5. Other policies, such as “DU Data Standards” and the Banner Data Acceptable Use Policy may apply to the project’s specifications.
  6. When a software proposal conceived by a Department requires data that is maintained by another Department, then that Department shall be contacted by EAS to verify approval of the proposed usage of its data.
  7. The Assistant Vice Chancellor of EAS shall resolve issues concerning the validity, usage, and scope of the request.

Software Development and Testing

  1. Before beginning work, the Software Developer may ask the Department Approver to approve the Software Developer’s interpretation of the specifications, as stated in the project’s description or, for lengthy specifications, in other documentation.
  2. The Software Developer shall prepare the software in a test environment. and perform preliminary testing to verify that the technical behavior of the software is acceptable.
  3. Department staff shall test the software in a more thorough manner to judge the fulfillment of its business purpose.
  4. The Department Requestor and Software Developer shall work together to fine tune the specifications and software to achieve the desired results.

Project Approval and Installation

  1. The Department Approver shall approve the project for installation; this action signifies that the software is acceptable for production.
  2. Approved software is assumed to be tested software; only approved software shall be installed.
  3. The Department Approver process automatically creates a Request in the University's IT Service Management Software (ITSM).
  4. Prior to installation, the Software Developer shall place the software into the EAS source code versioning library.
  5. The Software Developer shall add a Change Plan and Backout Plan to the Request.
  6. The Software Developer shall approve the Request which automatically creates a Change Request in the ITSM software.
  7. To attain tighter data security and a more easily accessed audit trail, only the EAS Database Administrator (DBA) shall install software for production.
  8. The DBA shall install software that has been retrieved from the source code versioning library; this action completes the project.

Vendor Software Upgrades

  1. The EAS DBA shall create the software upgrade project in the Project Tracking System.
  2. The DBA shall install the upgrade software in a test environment.
  3. EAS Software Developers shall perform preliminary testing to verify that the technical behavior of the upgrade is acceptable.
  4. Department staff shall test the upgrade software to judge the vendor’s defect resolutions and enhancements.
  5. Department staff shall carefully test mission-critical software.
  6. The Department must alert EAS of concerns and problems that are discovered during testing.
  7. Before installation, the Director of EAS shall approve the project; this action signifies that the upgrade software poses no known risk to the University’s critical business processing.
  8. The DBA shall install the upgrade software in the production environment; this action completes the upgrade project.