91¿´Æ¬Íø

This website uses cookies so that we can provide you with the best user experience. By using this website, you consent to the use of cookies. Learn more about our use of your data by reading our Privacy Policy.

Accept Privacy Policy
Apply Visit Campus Request Info Give
Students, Faculty, and Staff Search Menu

ITS Policies & Procedures

ITS / Policies / Change Management Policy

Change Management Policy

Policy #: LFC.ITS.6
Date: 10/25/2023
Author: LFC ITS
Version: 2.0
Status: Approved

OVERVIEW

This policy outlines the change management procedures for making modifications to 91¿´Æ¬Íø's IT infrastructure and other critical e-resources, such as enterprise applications, servers, network infrastructure, and related systems. By adhering to this policy, we reduce the risk of disruptions and maintain the consistency of operations and reporting. Without such a structured approach, the likelihood of potential incidents increases, and a lack of proper documentation for IT changes follows. Change Management is key to minimizing potential risks when introducing updates to the IT system. The objective is achieved through consistent methods to accurately document, communicate, and implement changes.

1. PURPOSE

The objective of this policy is to ensure that changes to critical 91¿´Æ¬Íø IT Systems are tracked in order to support continuity of IT services, and to reduce the number of negative incidents which may impact College services and users. IT Systems include computing devices, networking, communications, applications, and telecommunications systems, infrastructure, hardware, software, data, databases, physical facilities, on-premises servers and cloud-hosted “X as a Service” platforms, and other related systems and services.

2. SCOPE

While all users of College e-resources should be aware of the policy, this policy only applies directly to College Information Technology Services staff, student workers or interns, and contractors who perform development or system administration work on College IT Systems. Systems not managed by 91¿´Æ¬Íø ITS – such as Software as a Service (SaaS) platforms – are outside of the scope of this policy. In these instances, ITS will coordinate with the relevant teams or vendors.

3. ENTERPRISE APPLICATIONS CHANGE MANAGEMENT TERMS

3.1 Change Management is a structured approach for introducing alterations within the IT infrastructure, most notably within enterprise applications. This process involves initiating a Change Request and culminates in the successful deployment of the proposed change.
3.2 A Change Request is a request for a modification, such as the addition of a new feature or capability.

4. ENTERPRISE APPLICATIONS CHANGE MANAGEMENT PROCESS

4.1 Requesting a Change: All changes to enterprise applications must be initiated through a formal change request. This request should be made by the entity desiring the change and should be aided by a member of the ITS Enterprise Applications team.
4.2 Analyzing and Justifying Change: Once initiated, both the requester and the ITS team will:
  • Ascertain the need and justification for the change.
  • Determine the feasibility of the change, especially concerning proprietary code or system access.
  • Identify both technical and business risks.
  • Evaluate the potential impact on the infrastructure, business operations, budget, and cybersecurity posture.
  • Establish technical prerequisites.
  • Develop and review the implementation methodology.
  • Formulate a functional test plan to ensure the change meets its intended outcome.
4.3 Change Approval and Scheduling: The oversight of this phase will be managed by the Director of Enterprise Applications, who will direct a change management team comprised of ITS staff with expertise in various areas such as network management, server administration, security, database management, and desktop support. Additionally, relevant stakeholders from the user community will be incorporated when appropriate. The magnitude and implications of the change will determine the level of authorization needed, including up to authorization and approval by the Chief Information Officer (CIO.)
4.4 Change Execution and Review: Upon approval, the Director of Enterprise Applications will delegate specific tasks to ITS members and identify relevant stakeholders to ensure a seamless transition. If any issues arise post-change, the Director of Enterprise Applications will assess whether to revert to the previous stable state.

5. INFRASTRUCTURE CHANGE CLASSIFICATION

5.1 Standard Changes are pre-approved and low-impact, well-known, and documented. Standard changes require a risk assessment and authorization when implemented for the first time, but subsequent implementations can be done without these precautions as long as the change has not been modified. Examples include swapping failed equipment in a like-for-like exchange, changing the tagging of a port on a network switch, replacing failed components in a server, or other normal day-to-day maintenance and administrative tasks.
5.2 Significant Changes need to follow the change control procedure; they should be scheduled, have their risk assessed, and be authorized in advance. Significant changes have an impact and urgency of medium or higher. All changes that are not standard or emergency should be treated as normal changes and adhere to the change control procedure. The following activities should be considered significant at a minimum:
  • Hardware: activities such as installations, alterations of solution design, or equipment relocations
  • Database: updates, modifications, or significant maintenance tasks which will result in brief interruptions to service or measurably degrade performance for a period of time exceeding 15 minutes.
  • Schedule Alterations: Changes related to job schedules, backup schedules, or other routine tasks overseen by ITS staff.
  • Outages: Any application or network downtime event expected to exceed 30 minutes will necessitate a thorough review.
5.3 Emergency Changes are typically unplanned, high impact, and require expedited assessment, approval, and implementation to restore normal functionality as quickly as possible. Modifications to components that affect business operations, and therefore cause downtime, are treated as emergency changes. Emergency changes often occur as a result of equipment or service failures.

6. INFRASTRUCTURE CHANGE MANAGEMENT POLICY

6.1 Standard changes to College IT systems need only be tracked by ITS staff as necessary to restore previous service states or equipment programming as needed.
6.2 Significant changes to College IT systems must follow the Change Control Procedure identified by the CIO to ensure appropriate approval, planning and execution.
6.3 Change requests are not required for non-production environments unless there is a significant upgrade or impact.
6.4 Production change requests must note that the change has been successfully applied, tested, and verified in a non-production environment when a suitable environment exists.
6.5 Changes to production environments undergo impact examination before submitting the change request per the change control procedure. This information will be used to determine the impact of the change by considering:
  • The impact the proposed change will have on business operations, if it is expected to cause a widespread outage, a loss of connectivity or functionality to a specific group or groups;
  • The risk involved in not making the change;
  • The risk if the change does not go as planned; and
  • Predictability of the success of the change.
6.6 Any significant changes to IT systems – especially Internet-facing systems or services – must be reviewed for security implications by the Information Security Manager.
6.7 Significant user experience changes must be conveyed to ITS leadership and communicated to the affected audience and ITS User Services.
6.8 An after-action review will occur in the event of an incident during a change request, or whenever an undocumented change leads to an incident. Notes of the session will be documented and shared with ITS leadership.
6.9 In emergency cases, actions may be taken outside of change control procedure if approved by the CIO or their designee(s). All changes should be documented and reviewed upon the conclusion of emergency.

7. INTERNAL SYSTEM MAINTENANCE

ITS staff must apply security patches and software and/or firmware updates to IT systems regularly to protect 91¿´Æ¬Íø's IT environment. Although every effort is made to minimize the impact of such maintenance on users, ITS staff may need vendor support during maintenance cycles. Not all vendors provide 24/7 support, and for those that do, 24/7 support contracts are typically prohibitively expensive.
Normal weekly software updates shall be applied to all shared College Windows and Linux computing systems (including servers and shared lab computers) between 12:00AM and 6:00AM on Wednesdays. Expected downtime for any single system applying such an update is generally less than 30 minutes. Software updates for macOS systems will be similarly scheduled if/when technically feasible.

8. EXTERNALLY HOSTED SYSTEMS

Applications, systems, and services hosted externally by third-party vendors are typically not under the direct control of ITS staff for maintenance windows or upgrades. Staff should look for emailed notices regarding third-party maintenance windows and adapt their work as necessary.

RELATED POLICIES:

Document Control:

Entry#: Date Version Notes
1 2014 1.0 Original policy, approved by LITS Advisory Committee
2 10/25/2023 2.0 Revised, submitted for review
3 12/07/2023 2.0 Revised policy, reviewed by LITS Advisory Committee
4 01/18/2024 2.0 Reviewed and approved by the Senior Leadership Team

Information Technology Services