Skip to main content
Back To Top Top Back To Top
This website publishes administrative rules on their effective dates, as designated by the adopting state agencies, colleges, and universities.

Rule 3341-6-61 | Change management for IT systems.

 

(A) Policy statement and purpose

This policy articulates how change management of BGSU information technology systems will be accomplished.

Change management refers to a formal process for making changes to IT production architectures, tools, and systems. The goal of change management is to increase awareness and understanding of proposed changes across an organization and ensure that all changes are made in a thoughtful way that minimize negative impact to services and customers.

(B) Policy scope

This policy applies to all BGSU information technology systems.

(C) Definitions

(1) Change - the addition, modification, or removal of approved, supported, or baselined hardware, network, software, application, environment, system, or associated documentation.

(2) Change advisory board (CAB) - a group of people that support the assessment, prioritization, authorization, and scheduling of changes. The composition and role of the CAB are described in paragraph (D)(4) of this policy.

(3) Change authority - the person actually making the requested change to an IT production architecture, tool, or system. This role is designated for a non-classified position.

(4) Change control - the procedure to ensure that all changes are controlled, including the submission, analysis, decision making, approval, implementation, and post implementation of the change.

(5) Change history - auditable information that records, for example, what was done, when it was done, by whom and why.

(6) Change log - auditable log of who, what, why, and when for all changes. This may be system specific as certain systems can automatically log changes in this manner.

(7) Change management - process of controlling changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved changes with minimum disruption.

(8) Core service - a service that users directly consume, and the organization receives value from.

(9) Critical operations windows finals week starting on the Monday of that week for each quarter, first two days of classes for each quarter, graduation weekend starting on the Friday of that weekend, and fiscal year end close.

(10) Enabling service a service that must be in place for a core service to be delivered.

(11) Enhancing service a service that adds extra value to a service but is not absolutely required.

(12) Impact - determined by potential disruption to users, departments, colleges, and the organization. User means approximately ten or less individuals.

(13) Peer - another IT professional that can review a change and understand the technical elements involved.

(14) Priority - how quickly a change must be implemented to maintain stated service level agreement (SLA). How to determine the priority of a change is described in paragraph (D)(3) of this policy.

(15) Process log - a central repository of changes that documents the process followed for a particular change. The purpose of the process log is to ensure that high impact changes have been carefully considered and to serve as a basis for process improvement when changes do not go as planned.

(16) Request for change (RFC) a formal proposal for a change to be made. It includes details for the proposed change.

(17) Service a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. Do we add value or assume risk? Then it is a service we provide.

(D) Policy

(1) Steps of change management

Change management includes the following steps:

(a) Planning: Plan the change, including the implementation design, schedule, communication plan, test plan, and roll back plan.

(b) Evaluation: Evaluate the change, including determining the risk based in priority level of service and the nature of the proposed change, determining the change type and the change process to use.

(c) Review: Review change plan with peers and/or change advisory board as appropriate to the change type.

(d) Approval: Obtain approval of change by management or other appropriate change authority as determined by change type.

(e) Communication: Communicate about changes with the appropriate parties (targeted or campus-wide).

(f) Implementation: Implement the change.

(g) Documentation: Document the change and any review and approval information.

(h) Post-change review: Review the change with an eye to future improvements.

(2) Types of changes

There are three types of changes:

(a) Standard change a repeatable change that has been pre-authorized by the change authority by means of a documented procedure that controls risk and has predictable outcomes.

(b) Normal change Normal changes follow the defined steps of the change management process. Routine, elevated, or critical priority is determined by unit directors or delegates according to the risk assessment matrix in paragraph (D)(3) of this policy.

(i) Normal low changes must be reviewed and approved by the unit supervisor (director, manager, or other appropriate supervisor) as change authority.

(ii) Normal medium changes must be reviewed and approved by the change advisory board as change authority.

(iii) Normal high changes must be approved by the CIO, DCIO, or their delegates as change authority.

(c) Emergency change A change that must be introduced as soon as possible due to negative service impacts. There may be fewer people involved in the change management process review, and the change assessment may involve fewer steps due to the urgent nature of the issue; however, any Emergency change must still be authorized by a manager and either the CIO or the DCIO, and reviewed by the change advisory board retroactively.

(3) Determining the applicable change management process

A standard change is controlled by a pre-approved standardized process. For all other changes, the following matrix is used to determine the change management process that will apply.

First, determine the impact of the change to the service: organization level, college level, department level, or user level.

Next, assess the priority of the proposed change. A routine priority change is one that can wait until the next scheduled meeting of the change advisory board. An elevated priority change cannot wait until the next meeting. A critical priority change needs to be done as soon as possible.

For example: a critical priority change to a service that impacts the organization would be considered an emergency change and use the change management process applicable to that type of change.

Priority -RoutinePriority -ElevatedPriority -Critical
Impact -Organization change affects more than 1,000 individualsNormal mediumNormal highEmergency
Impact - College change affects approximately 1,000 or fewerindividualsNormalmediumNormal highNormal High
Impact - Department change affects approximately100 or fewer individualsNormalmediumNormal mediumNormal High
Impact - User change affects approximately ten orfewer individualsNormallowNormal lowNormalMedium

(4) The role of the change advisory board

The members of the change advisory board provide a due diligence readiness assessment and advice about timing for any request for change (RFC) that is referred to it for review. This assessment should ensure that all changes to the IT environment are carefully considered to minimize the impact on campus users and existing services.

Any decision to move forward with an RFC should include an advisory review by the CAB before a medium priority change and after an emergency change.

The change advisory board shall consist of the IT directors, the deputy CIO, the CIO, the chair of the faculty senate's information technology committee, and their designated alternates who will attend in their absence.

CAB members are responsible for:

(a) Thoroughly reviewing all change requests;

(b) Raising any potential concerns about the impact or timing of those requests;

(c) Ensuring the changes requested:

(i) Have undergone proper planning and testing;

(ii) Are planned to ensure the lowest possible risk;

(iii) Are coordinated so changes do not impact each other;

(iv) Are coordinated with the campus calendar to avoid times of high impact for affected services; and

(d) Providing advice regarding any additional measures that should be considered prior to the change.

(5) The role of the first level manager

Change management responsibilities for first level managers include the following tasks:

(a) Review and approve timing and feasibility of RFCs;

(b) Review and approve RFCs when authorized by CA;

(c) Engage IT communications manager to initiate communication with users;

(d) Ensure that requestor fills out the RFC accurately and completely; and

(e) Ensure staff availability to successfully complete the RFC.

(6) The role of the change authority

Change management responsibilities for the change authority include the following tasks:

(a) Provide advisory input to the requestor on any needed changes to the RFC prior to approval, including any follow up communication necessary for clarification during the change process;

(b) Review and approve RFCs when needed; and

(c) Review change outcomes and make process changes appropriate to increase service availability and service quality.

(7) The role of the requestor

Change management responsibilities for the requestor include the following tasks:

(a) Ensure that additional resources are available in case of problems;

(b) Prepare the request for change (RFC) and submit to the appropriate change authority;

(c) Incorporate feedback from the change authority into the RFC; and

(d) Document the outcome of the change.

(8) Examples of the process

StandardChangeNoramlChange
Plan: Collectinformation to make the change; follow documented procedurePlan: Collect information to make the change;perform testing; review documentation
Evaluate: Access documented procedure to ensure compatibilitywith the changeEvaluate: Determinethe risk, priority, and Normal change type
Peer review: Conduct internal review as needed indocumented procedurePeer review:Conduct internal or external review depending on servicepriority
CAB review: NotrequiredCAB review: Submit to theCAB for assessment and advice
Approval: Pre-approved by Change AuthorityApproval: Obtain authorization from the ChangeAuthority
Communicate:Send targeted e-mail to affected customers only as needed in documentedprocedureCommunicate:Priority 1: Send notification to Outages and other venues as needed (e.g.,Inform lists) Priority 2: Send targeted e-mail to affected customersonly as needed
Implement: Make the changeImplement: Make the change
Document: Change LogDocument: Change Log and Process Log (except forLow)

(9) Change plan documentation

All normal and emergency changes, evaluations and approvals will be documented to allow customers to understand what was changed, the reason it was done and the process that was used to make a change. The following sections detail the kind of information that will be logged for each change and where it will be logged.

(a) The change log

All standard, normal, and emergency changes are logged in the change log. The change log identifies:

(i) Who made the change;

(ii) What was changed;

(iii) Why the change was made; and

(iv) When the change was made.

(b) The process log

All medium, high, and emergency priority changes are logged in the process log. Low priority changes are not. The process log contains:

(i) Testing plan and testing results;

(ii) Risk assessment documentation;

(iii) Communication plan; and

(iv) Deployment plan, including back-out contingencies.

Last updated March 13, 2025 at 7:41 AM

Supplemental Information

Authorized By: 3341
Amplifies: 3341