Definition: The phrase “Change Management” incorporates any addition, modification, or removal of systems, software, or hardware that may have an impact on institutional operations. In our highly interconnected environment, the impact of a change may have unintended or unanticipated consequences, and must be carefully planned and communicated in advance to avoid disrupting normal operations. 

Scope:

This policy addresses how change management is handled for systems, applications and devices in the Purchase College Domain. 

The change management process involves:

• Logging change requests.
• Assessing the impact, cost, benefits, and risk of requested changes.
• Providing approval or rejection.
• Overseeing the change implementation.
• Monitoring and reporting the status of changes.
• Closing change requests and conducting post-implementation reviews.

Tools:

Purchase College uses NNT Change Tracker to apply and archive changes as they are applied to servers and network devices. For text-based configuration changes, NNT tracks which lines of configuration were impacted by a given patch or update.  For computer workstations, CTS makes use of SCCM, Munki, and group policy to deploy software, updates, and patches. 

Classification and Categorization of Changes

There are three different categories of changes:

1. Normal Change – Any service change that is not a standard change or an emergency change.
2. Emergency Change – A change that must be implemented as soon as possible; for example, to resolve a major incident or implement a security patch.
3. Standard Change – A preauthorized change that is low risk, relatively common, and follows a procedure or work instruction.

In addition to the change categories, changes can be classified as major, significant, or minor, depending on the level of cost and risk involved, and on the scope and relationship to other changes. The detail procedures for each group should address this classification. 

Emergency Changes

A change that must be made before a Change Advisory Board (CAB) can be convened to review and approve it due to a repair or error in an IT service that is causing a negative impact. Incident resolution may sometimes require emergency changes. Examples include a critical service-down that requires a quick hardware swap-out, or a late-night system emergency when the change manager or others may not be available.

An emergency change must follow these steps:

• If time allows, the change initiator must make a good-faith effort to contact their manager or the appropriate change manager to give them the opportunity to approve the change prior to making it.

• Once the change is deployed and the incident is resolved, the change initiator must document the change in Help.HSC as an emergency change.

• The change manager and the CAB will review all emergency changes at their next scheduled meeting. 

Change Planning:

When any change is being considered—a new device, new system, OS upgrade, software version upgrade, security patch—or the elimination of a resource or service is being considered, it is critical that careful consideration be given to the potential impact of the change, and to the process for implementing the change. It is also critical that the implications be carefully communicated to any stakeholders that may be affected by the change.

The change initiator is responsible for the ensuring that the analysis and communication are conducted during the planning phase. The change initiator is often a business unit (e.g., Office of Admissions) without IT expertise, and they may have to rely on technical staff—or on other staff from other units—to determine the full impact and implications of the change they wish to initiate. Since a change may affect more than one area—or even the entire institution—a Change Advisory Board (CAB) will also be used to ensure the implications are widely understood. The composition of the CAB may vary depending on the change being proposed.

The composition of the CAB will be determined by the change initiator and the director of CTS. The change initiator is responsible for convening the CAB in a timely fashion and obtaining their approval for the change.

Change Request:

The change initiator must complete a Change Request Form providing information on the change they are proposing. The Change Request Form will be reviewed by the director of CTS and the Change Advisory Board. The Change Advisory Board may add additional information before approving or rejecting the change request.

• Business reason for change (process improvement, regulatory requirement, etc.)
• All costs associated with making this change (new version of software cost, re-training, etc.)
• Other units that may be affected by the change 

Risk and Impact Analysis

The change initiator must complete a risk and impact analysis form for the change they are proposing. See the Appendix for the Risk and Impact Analysis template.

Change Communication

The change initiator is responsible for communicating the change to the proper audiences. Once the initiator is notified of the change approval, they should initiate necessary communications about the change prior to the change being made. See guidelines for when change notifications should be sent and to whom they should be sent.

Approved changes that have a broad impact, such as the entire college community, may require additional communications, such as notification by broadcast email, signage, or other methods. For changes with broad impact, the change initiator should work with his or her management to ensure the necessary notifications are being completed.

Standard and Routine IT Maintenance Changes, IT Roles

Servers

All college servers are assigned a primary system administrator. A secondary (and tertiary) system administrator is also assigned for each server in the event the primary system administrator is not available for any reason. Collectively, these individuals are referred to as the system administrator (SA).

The SA is responsible for reviewing and applying operating system (OS) patches and updates as soon as is practical, and for maintaining their systems at the most current state possible. The SA is responsible for advising management when a server cannot be updated due to hardware or software incompatibility. Patches and point releases are considered normal and routine changes—and do not require CAB approval. Operating system upgrades do require CAB approval.

 Documentation for all patches and upgrades should be carefully reviewed before applying any change to any system. For patches, no approval beyond the SA is required. For OS upgrades, written approval should be obtained in advance from the assistant director for networks and systems – as well as from any application administrator (see below) responsible for applications on the server.

 For servers where a TEST environment is available (i.e. Banner, SQL-Server, Web Server), the patches and upgrades will be applied to the TEST instance of the server first to help determine any undocumented adverse impact of the change. 

Applications

For many applications residing on college servers, an application administrator (AA) is assigned to configure and manage the operation of a specific application (i.e. Moodle, Genetec.) The application administrator is often an individual with functional expertise for that application. The application administrator may also be the same person as the system administrator (SA). The application administrator has elevated privileges allowing them to change configuration settings and to manage the application through whatever back-end console the application may provide. The AA is expected to work closely with the SA for the server where his or her application is hosted. 

The AA is responsible for reviewing and applying application patches and updates as soon as is practical, and for maintaining the application at the most current state possible. The AA is responsible for advising his or her system administrator (and management) when an application cannot be updated due to hardware or operating system incompatibility.

Devices

All college network devices (firewalls, routers, switches, load balancers, storage arrays and sub-systems, appliances, etc.) are assigned a primary system administrator. A secondary (and tertiary) system administrator is also assigned for each device in the event the primary system administrator is not available for any reason. Collectively, these individuals are referred to as the system administrator (SA).

The SA is responsible for reviewing and applying vendor patches and updates as soon as practical, and for maintaining his or her devices at the most current state possible. The SA is responsible for advising management when a server cannot be updated due to hardware, software, or firmware incompatibility.

For instances where devices are deployed in a resilient fashion, patches and upgrades will be applied to one of the devices first—and then evaluated to determine whether there is any undocumented adverse impact of the change before it is applied to the other device.

Workstations

All college workstations (desktop computers, laptops) place CTS in the desktop system administrator (DSA) role. All college workstations must be joined to the domain and must be accessible for application of software patches and system updates. The CTS DSAs use SCCM, Munkee, and group policy to distribute patches and updates to Apple and Windows workstations. 

Patches and point releases of common software are considered normal and routine changes—and do not require CAB approval. Operating system upgrades do require CAB approval. 

Change Management Roles and Responsibilities

Roles associated with the change management process are defined in the context of the management function and are not intended to correspond with organizational job titles.

Role  and Responsibilities

Change Initiator
Business or IT representative who initiates a request for change. This person is responsible for filling out the Request for Change (RFC) form ensuring that all required information is included, submitting it according to this procedure, and notifying change manager.

Change Process Owner
Senior manager who provides management control and guidance for the process in the IT department. Accountable for process design, operation, and improvement. Approves process rollout and changes to the process. Coordinates with change process owners in other departments to ensure common practices where appropriate.

Change Manager
This person has overall operational responsibility for the change management process in the IT department. Accountable for vetting the change request to ensure accuracy and completeness and sufficient information for the CAB to approve or reject the proposal. May make the determination regarding categorization and classification of the request.

Change Advisory Board
The CAB is a cross-functional team responsible for assessing change requests in terms of business need, cost/benefit, viability, and potential impacts to existing systems or processes. The CAB instructs the change manager to approve, defer, return, reject, or cancel changes. Also, the CAB makes recommendations related to change implementation. After changes are complete, the CAB reviews them for success/failure and lessons learned.

Emergency CAB (ECAB)
This team (or individual) is a subset of the CAB that is responsible for dealing with Emergency changes. The ECAB must be able to respond on very short notice and authorize or reject Emergency changes.

Technical Review Board
An ad-hoc group of subject manner experts and technical experts who are convened by a CAB to do an in-depth review of a change.

Service Owner
Represents one or more services in IT leadership and CAB meetings. Understand customer service requirements. Authorizes changes to the service.

Component Manager
Represents one or more service components in the CAB. Understands the technical structure of the component and subcomponents, and how they support the service.

Stakeholder
Any individual with an interest in types of changes or in a particular change. 

Appendix – Risk and Impact and Analysis Template

 

Risk Assessment                                                                                              Risk Score: Low/Medium/High

 

1. How often has this change been successfully made?

 

1 Routinely        2 Occasionally   3 Never

 

2. What is the degree of difficulty to implement this change? (Consider the complexity of the change, number of devices involved, number of steps in the process, time pressure and number of people involved to accomplish it.)

 

1 Low                 2 Medium          3 High

 

3. Has this change been successfully tested, or will it be, prior to implementation?

 

1 Yes                  2 No

 

4. Which test environment have you, or will you, use for this change?

 

1 Separate/duplicate     2 Shared            3 Partial             4 Production/none

 

5. Have the recovery procedures ever been successfully tested?

 

1 Yes/NA                         2 No

 

6. What type of support is available if external technical assistance is needed?

 

1 On site            2 Remote           3 On call            4 Not available

 

7. What is the degree of difficulty and effort for the Vendor/Partner, if needed, to return the system/component to an operational state?

 

1 NA                   2 Low                 3 Medium          4 High

 

8. What is the probability of this system/component failing?

 

1 Never/low      2 Medium          3 High

 

9. What is the probability of this change negatively affecting any of the applications, databases, servers or infrastructure components supporting a the application?

 

1 Low/NA          2 Medium          3 High

 

Appendix – Risk and Impact and Analysis Template

 

Impact Assessment                                                                           Impact Score: Low/Medium/High

 

1. What amount of downtime will the user experience, outside of the regularly scheduled maintenance window?

 

1 None               2 Less than an hour       3 Greater than 1 hour               4 Greater than 4 hours

 

2. What is your recovery capability if this change fails?

 

1 Easy backout or alternate/fail-over is available and will provide almost immediate service

2 An alternate is available, but needs to be brought online

3 No alternate system/component or spare is available

 

3. Could Patient Safety/Care potentially experience a negative impact due to this change?

 

1 Yes                  2 No

 

4. Could providers or mission-critical programs (e.g., academic classes, offices) potentially experience a negative impact due to this change?

 

1 Yes                  2 No

5. Is end user training required, prior to implementation?

 

1 Yes                  2 No

 

6. If the change were to fail, what is the worst case scenario? (In or outside of the regularly scheduled maintenance window)

 

1 None               2 Slowdown      3 Partial or full outage

 

7. If a partial or full outage is possible, has the business successfully tested their manual/contingency procedures, should the change fail?

 

1 NA/Yes           2 I don’t know                3 No

8. How many IT services/business applications are impacted by this change?

 

1 None               2 One or two                  3 Three or more               4 All

 

9. Approximately how many users/workstations will be negatively impacted during the change implementation?

 

Number of users/workstations