Procedures & Guidelines
The Change Management team will meet weekly to review change requests and to ensure that change reviews and communications are being satisfactorily performed.
A Change Request Form (CRF), which may be found on the Change Management home page, must be filled out and submitted by 12:00 Noon Monday. This cut off date is to allow sufficient time for the Change Manager to review change submission prior to next (upcoming. delete) meeting. The Change Request Form (CRF) must include change schedules, the development process and solution implementation process.
If the change requires escalated approval from other committees or groups, the CIO will be responsible for forwarding the change request to an appropriate group for approval.
The Change Manager will ensure that the Change Request Form is complete, assess the change to make sure it is feasible within our current technical resources and also will appraise and prioritize the proposed change. The Change Manager will also work with the CIO on preauthorization and forward the change request to the key members of the working group or key stake holders if the Change Manager believed that additional review will be required.
IT Client Services division will be responsible for apprising end-users of change especially if the change impacts a large group of users, including ACCD students, faculty and staff. Changes requiring assistance of Client Services need to be communicated well in advance of the change. Client Services staff will use electronic delivery systems, such as, PALS, Listserv, IT Links Newsletter, IT website, and electronic system alert facilities.
Information Change updates and emergency change should be documented immediately after the change has been completed. A Change Request Form (CRF) is essential to provide notification and maintain documentation audit trail.
Team members involved in the change must agree to the readiness and timing of the change. If the IT Managers disagree, then change needs to be postponed or renegotiated. Discrepancies will be forwarded to the CIO for clarification.
The scheduled change implementation date and time should be such as to minimize downtime and impact for users. The date and time should not be for the convenience of the change implementation team and should use published change windows where available.
Before any changes are implemented, fallback procedures must be developed and in place to be executed if needed. All problems resulting from the change should be reported immediately and documented. Scheduled implementation dates and time should recognize other schedule activities and known events for that same time period.
Once the change is implemented, the implementers should access the Change Request form and log the change request as closed. Email notifications will be sent to the change stake (space) holders and team members of the closed change request.
