Change Management Policy

Download the Change Management policy or review the policy below.
 

Change Management (CM) is the process of communicating, coordinating, scheduling, monitoring, and documenting changes to IT resources in a standardized manner. This policy ensures that all changes are communicated across divisions for discussion and approval prior to implementation to avoid changes that are potentially disruptive, in conflict, or of unacceptable risk. Only formally requested and approved changes will be implemented.

ROLES AND RESPONSIBILITIes

Meeting Facilitator: The Systems Services Technical Liaison is responsible for overseeing and facilitating weekly meetings with the IT staff. The conference is scheduled for one hour to discuss new changes and status updates.

Change Owner: The change owner proposes normal and non-standard changes and any modifications affecting production by submitting a Request for Change (RFC). The change owner is required to receive approval from stakeholders and interested parties before the CM meeting.

Stakeholders/Interested Parties : These are individuals or their representatives who may be affected by approved changes, e.g., manager, senior technician, anyone directly involved in the change request, or anyone representing the GC Community.

Approvers: A minimum of two approvers is required for each change: the IT Services Operations Manager or representative and a stakeholder.

Managers: These are members of ITMT+ who have supervisory responsibilities and are empowered to make decisions directly affecting their respective areas and on behalf of their Directors. Managers are encouraged to inquire about specific change requests during the CM meetings, as the changes 2 pertain to their separate areas. Additionally, all managers are required to name designees, familiar with new RFCs, to represent them if they cannot attend the CM meetings. All appropriate representatives should be present at each meeting.

IT Staff: Every member of the IT Department can attend the CM meetings. Everyone is encouraged to ask questions about the changes discussed at the meeting. Any staff member may introduce a change by completing and submitting an RFC located at https://cm.gc.cuny.edu.

Meetings: All managers from each IT division should attend each meeting.

OBJECTIVES OF CHANGE MANAGEMENT

1. To set standards for the efficient handling of all IT changes
2. To permit changes that will maintain or improve service stability and availability and ensure the timeliness of the expansion and elimination of services
3. Before executing a request for change, the Change Management team should be aware of all the technical and management accountability
4. Ensure that all affected parties are informed, and that necessary documentation and training are in place before the implementation

TYPE OF CHANGES

The Change Management Process applies to normal, standard, non-standard, and emergency changes and anything affecting production, such as the following:

Standard Changes (Pre-authorized): A standard change is a change to a service or infrastructure for which the approach is pre-authorized by change management with an accepted and established procedure to provide a specific change requirement.

The elements of a standard change:

1. There is a defined trigger to initiate the request for change
2. The activities/tasks are well known, documented, and proven
3. Pre-authorization
4. The risk is usually low

Normal Changes (Pre-approved): A normal change refers to a change that must follow the complete change management process. Most often, normal changes fall under the following categories: minor change – (low risk and impact), significant change – (medium risk and impact), and major change – (high risk and impact).

The activities of the normal change process:

1. Record requests for change
2. Log change
3. Review the request for change
4. Assess and evaluate change
5. Allocate priorities
6. Change planning and scheduling
7. Authorize change
8. Review and close change record

Emergency Changes: Emergency change requires immediate action to ensure stability and avoid interruption in service to IT resources. Emergency changes only occur if the change cannot wait until the next Change Management meeting.

This policy does not apply to Test environments:

• The change owner must have an agreement from the owner of the server to make changes.
• The owner of the server and change owner must work out who will notify users.

CHANGE RISK

All Changes should have an assigned “Risk.”

• Low Risk: The risk that falls in the green cell marked with ‘L’ does not usually pose any significant problem.
• Medium Risk: This risk level falls at the bottom left corner and may require risk management strategies to limit any possible damage.
• High Risk: Calls for immediate action or risk management strategies to avoid possible disruptions.
• Extreme Risk: The risks that fall in the cells marked with ‘E’ (red color) are the most critical and high priority risks. Any change that has extreme risk has to go through the extra step of being approved by the Directors and the Assistant Vice President/CIO.

CHANGE MANAGEMENT PROCEDURES

• The change owner must complete an RFC located at https://cm.gc.cuny.edu/ to initiate a change. The change owner must submit an RFC for each component of an individual project as opposed to the entire project. A copy of the RFC will be sent to every Director and Manager upon submission to ensure management’s knowledge of the requested change.
• The change owner is responsible for getting approvals in advance of the CM meeting from stakeholders or interested parties and scheduling any discussions ahead of time.
• Approvers of changes will receive the RFC via email and must approve changes by checking the box next to their names.
• The change owner or designee will present the change at the CM meeting, and all IT staff present will be able to ask questions and reject pre-approved changes if necessary. If everyone agrees, the meeting facilitator will change the status of the “Pre-Approved” change to “Approved.”
• If a modification to a pre-approved request occurs after it is approved, the change owner has to get the pre-approvers to agree to the amendments.
• Discussions that explain the significance of specific changes and the necessity of critical changes are encouraged. Lengthy conversations should occur after the meeting with the core group involved and affected by such changes.
• If a change affects a small community of users, the change owner will notify the group via email before implementation when the change is approved.
• If a change requires a community notice or service alert, please follow the internal outage procedure.
• The meeting facilitator will record status changes.
• Emergency changes should have an identification of “Emergency” in the subject line. Change owners are required to send status reports after the resolution of emergency changes.
• Any project assigned to a project manager with a task requiring change management must include the project name and number in the description field.
• The facilitator will change the approved date if needed during the CM meeting.

ESCALATION OF CHANGES

Changes requiring input and assistance from the Directors must be communicated well in advance of the change request – they will decide when to escalate the change to the Assistant Vice President/CIO.

When to contact Directors:

• When the change involves a mission-critical system;
• When the implications of the change on end-users are unclear, the Directors will determine the extent and nature of the communications and actions needed.

Change Management Updates

The Director of Systems Services will make modifications to this document as the change management process is amended according to IT management/staff.

All new RFC should be submitted no later than Tuesday at 11:00 a.m. to enable people to read the request before the meeting.