OIT Change Management Policy
This document describes the process by which changes are requested, reviewed, approved, communicated, tested, logged, and implemented.
For purposes of this policy, a change is defined as anything that transforms, alters, or modifies the operating environment or standard operating procedures. This policy establishes the process for managing these changes to hardware, software and firmware. The purpose of this policy is to ensure information resources are protected against undocumented changes as well as ensure coordination with other activities in the university. The overriding goal is to provide a high level of availability and service to our customers.
This policy applies to Office of Information Technology (OIT) personnel who install, operate, or maintain information technology upon which any unit of The University of Alabama in Huntsville (UAH) relies on to conduct business and/or achieve the mission of the university, and the community as it needs to be informed and aware of the policy since it may have occasion to request a change, approve, test, and thus are thereby subject to following the prescribed process.
This policy covers changes to OIT-supported systems (hardware, software, applications, and network environment) upon which any functional unit of the university relies in order to perform its normal business activities. Examples of these systems include, but are not limited to: Banner, Oracle, LDAP, Servers, the Network, Learning Management Systems and others. Changes not covered by this policy are changes that affect only an individual. Examples of changes not covered under the scope of this policy include, but are not limited to, changes to an employee’s desktop or laptop computer, allocation of IP addresses, etc.
Changes may be required for many reasons, including:
• User requests
• Vendor recommended/required changes
• Changes in regulations
• Hardware and/or software upgrades
• Acquisition/implementation of new hardware or software
• Hardware or software failures
• Changes or modifications to the infrastructure
• Environmental changes (electrical, air conditioning, data center remodels, etc.)
• Unforeseen events
• Periodic Maintenance
FORMALLY REQUEST A CHANGE
All requests for planned change will be documented by creating a new change request. The change request will be completed by the change requestor (OIT staff).
ANALYZE AND JUSTIFY CHANGE
The change requestor will work to develop a specific justification for the change and identify the impact on infrastructure, business operations and budget, identify business as well as technical risks, develop technical requirements, and review specific implementation steps.
APPROVE AND SCHEDULE THE CHANGE
The Change Management Committee consisting of – at minimum - representative OIT members from Network Services, Systems, Operations, Applications, Academic Technologies, and Customer Service will assess the urgency and impact of the change on the infrastructure, end user productivity and budget.
PLAN AND COMPLETE THE CHANGE
The Change Management Committee will assign specific OIT members and identify appropriate end-user members to complete the change in a manner that will minimize impact on the infrastructure and end users. In the event that the change does not perform as expected or causes issues to one or more areas of the production environment, the committee will determine if the change should be removed and the production environment returned to its prior stable state.
POST IMPLEMENTATION REVIEW
The Change Management Committee to formally ensure the change has achieved the desired goals will conduct a review. Post implementation actions may include acceptance, modification, or backing-out of the change. The committee formally documents the final disposition of the change as part of the Change Request.
DOCUMENTATION (REVISION HISTORY)
This policy categorizes change as: Planned Major; Maintenance and Minor; and Emergency and Unplanned Outage. Of the three change categories, Planned Major Change requires the most rigorous and extensive change process and subsequent procedures.
PLANNED MAJOR CHANGE
Examples of planned major change are:
• Change that results in business interruption during regular business hours
• Change that results in academic interruption within a term
• Change that results in business or operational practice change
• Changes in any system that affect disaster recovery or business continuity
• Introduction or discontinuance of a new information technology service
MAINTENANCE AND MINOR CHANGES
Examples of this type of change are:
• Application-based security or business needs patches
• Operating system patches (critical, hotfixes, and service packs)
• Regularly scheduled maintenance
• Changes that are not likely to cause a service outage
EMERGENCY AND UNPLANNED OUTAGE CHANGES
Examples of this type of change are:
• Building is without service
• A severe degradation of service needing immediate action
• A system/application/component failure causing a negative impact on business operations
• A response to a natural disaster
• A response to an emergency business need
• A change requested by emergency responder personnel
Emergency Change Process
The manager/director will make decisions about high impact emergency changes. These types of emergency changes are authorized only to repair IT service errors that are severely impacting the business, when a situation has occurred that requires an immediate action that cannot wait until the normal advertised window to either restore service or prevent a significant outage.
The emergency change process differs from the normal change process in that:
Approval is granted, and documented via e-mail in advance of the change by authorized manager/directors. If the appropriate manager/director is unavailable, then the CIO should be contacted for approval in advance of the change. If the CIO is unavailable, the change should still be documented via e-mail. In the rare event that e-mail service is down/unavailable, the change should be documented in writing, and signed by the authorized manager/director.
Testing may be reduced or even eliminated in extreme situations.
Updating of the necessary change request may be deferred until normal business hours.
Emergency changes require:
Technical change review and approval in writing, usually by the manager or director of the department making the change.
If it is not possible to notify the Director of Customer Relations and Manager of the Help Desk of the emergency change in advance of the change, they should be notified as soon as possible after the change.
Submission of a Change Request within one business day after the issue has been resolved.
Change Management committee review of the emergency change at the next Change Management meeting.
Emergency change procedures should be considered the exception rather than the norm. Failure to comply with emergency change procedures is considered a serious breach of risk management practices and may result in disciplinary action including dismissal.
The OIT Change Management Policy is posted on the OIT website: http://www.uah.edu/oit/.
Policy Number IT0913-01
- Hits: 1178