Change Management

Last Revised: January 10, 2019

Refer Questions to: Executive Director, Gallaudet Technology Services

Purpose

Technology infrastructure goes through rapid changes to keep up with the fast paced world. To eliminate or minimize the negative impact to users, community, or the technology resources as a result of changes, change management procedures need to be followed to ensure that the appropriate stakeholders are aware of the change before any action is taken.

Policy

GTS staff members use the following procedures to document and communicate about planned changes for all technology system or resources.

1. Determine the scope and impact of a proposed change. Discuss the proposed change with the appropriate GTS manager, director, and/or executive director, as well as data stewards and other offices that are involved with the system that is to be changed.
2. Develop a change management procedure including development/configuration, internal testing, client testing (if applicable), and review prior to implementation in a production environment. Where feasible, beta test the change with GTS staff and selected non-GTS staff as appropriate.
3. Obtain approval for the proposed change from the appropriate GTS manager, director, and/or executive director. Document the change and the procedure in: the IT Service Desk, GTS shared drives, or appropriate GTS Change Log (GoogleDoc).
   Include in the documentation of the change:
   • Brief description of the change (Limited to 1-2 sentences)
   • Task description (e.g., location of change, which equipment or software are being accessed, testing methodology (QA), installation/verification instructions)
   • Points of contact/responsible parties
   • If this is a new software, who is responsible for maintenance and support?
   • If this involves a change with a custom development or software, verify that the software utilizes a source code control system.
   • Schedule and time estimates (date/time when change will be performed, how long (duration) the process should take)
   • Are changes required to other services (network, firewall, databases, Active Directory, etc)? If so, describe.
   • Back out or rollback procedures in case of a failure
   • Potential risks (disruption to existing services during the change, security issues, etc) and impact for users
   • Communication plans with the community (e.g., Daily Digest, relevant committees and departments)
   • Analysis after the change has taken place. Determine and document lessons learned, corrective/preventive actions, and follow up plans for changes that deviated unexpectedly from the plan.
4. Change requests should be listed as far in advance as possible. For scheduled tasks in the distant future, an approximate date is acceptable. Any disruptive changes should be scheduled during the GTS maintenance schedules.
5. Following established procedures for who is authorized to announce changes, announce the change to the GTS and embedded tech stakeholders via email and the GTS Change Calendar. Where appropriate, ask the IT Service Desk supervisor to submit information about the change to the Daily Digest.
6. In case of emergency when a change must occur immediately, submit the change management form after the fact. If possible, obtain approval from GTS executive director, GTS director, or GTS manager before you apply the change.

Last Reviewed: 11/04/2019