Change Management Review (CMR) Charter

Change Management Review (CMR) Process

Revised Charter v6

Updated November 19, 2013

Charter Committee: Steve Aguirre, Caprice Elias, Josie Galvin, Karen Kato, Isaac Orr, David Rieger

CMR Representatives

• Any group that supports an IT service, or system, that has the potential to affect people or services outside of their own area of responsibility, must be represented on the campus Change Board.

• Any service that is supported by an outside entity (i.e. third party Software as a Service) must have a campus sponsor, which can speak on behalf of that group, assigned to the campus Change Board.

• The following is a sample of teams that are represented at each CMR meeting:

• All membership related requests for the campus Change Board should be sent to the Change Board Mailing List.

Change Management Mailing List

• The Change Management Mailing List (changeboard@lists.berkeley.edu) is used to communicate all things change management to each represented group.
• All newly created change requests, along with the weekly change reports are distributed through this list.

Weekly CMR Meetings

• A report of the previous week’s changes (both unplanned and scheduled) and all known upcoming changes (requested or approved) will be generated and distributed to the Change Board on the morning of the weekly CMR meeting.       All members are expected to review the report prior to the afternoon meeting so that each group’s representative is prepared to discuss their relevant items during the call.
• Absence of questions or comments from any group regarding any discussed change will be considered as approval for the change to proceed as requested.
• Participation in the weekly change meeting is mandatory for any group that is responsible for enterprise level applications, or systems.
• Attendance of the weekly change meeting is open to any campus member that has an interest in planned changes within the IT sector.

Criteria for Changes that Require Review

• Any production change that creates an outage, or has risk of creating an outage for an infrastructure service or application.
• Any production change that impacts other infrastructure services or applications.

CMR Tickets

• CMR tickets are generated and stored on the IST Change Management project in the Footprints ticketing system.

CMR Categories

• Standard changes that occur on a regular basis and have a clear back-out strategy require review.
• Non-Standard changes that are considered high impact (effect 5,000+ users) or are otherwise complex.
• Emergency – Unplanned outages or security actions that meet CMR ticket criteria.

Lead Time for CMR Tickets

• Standard changes require review in one CMR meeting prior to implementation.
• Non-Standard require a minimum 2 week lead time. This will provide those impacted services and applications adequate time to coordinate and fully assess the dependencies.       Communication on the change should not be published to campus users until after the first CMR.
• Emergency – The primary focus of the service provider is to fix the production issue as quickly as possible. A CMR ticket should be entered by the service provider or service desk team so that the system status can be updated. A full review of root cause and future mitigation steps should be reviewed in the next CMR meeting after research is completed.       If the Emergency transpires within the No Fly Zone, Director notification is required.

No Fly Zone (no major infrastructure work to be scheduled)

• Teams should target no scheduled changes during the week before, and the week of, the first day of instruction of the Fall and Spring semesters.
• Changes deemed critical for the No Fly Zone will require a Director’s approval.

General Change Management Process

• Risks and impacts for proposed changes should be identified and explored with impacted groups prior to the CMR meeting.
• The CMR representative should ensure the CMR ticket addresses:       The change, date, start and stop times, impact, and potential risk. Additionally, for non-standard changes, the background of the change as well as proposed back-out strategy must be included.
• CMR representatives have authority to 1) Accept the change as presented for their services, 2) Request further review or 3) Suggest a different date/time for the change based on risk and/or other technical/business schedules.
• Review of root cause and future mitigation steps for emergency/break-fix changes.

Process to Request Further Review

• Any member of the CMR group has the authority to delay a proposed change for further discussion outside of the CMR meeting.
• If a change request requires further review, the impacted parties should be identified in the CMR meeting and the team requesting the change should schedule a timely discussion on the topic.
• The requested change can not be implemented until the further review discussion is concluded.
• If the CMR discussion group reaches agreement on the approach, risks and mitigations, the change requestor should email the CMR list with the update (unless there is time and it can wait until the next CMR meeting).
• If the CMR discussion group does not reach agreement on the approach, risks and mitigations, it should be escalated to the impacted Directors for a decision.

Change Implementation Timing Guidelines

• All infrastructure services or applications have impact to the campus, therefore; the date/time of the change should be scheduled to impact as few users and systems as feasible.
• Peak periods and usage patterns vary by system and coordinating changes with hundreds of applications is difficult. We ask for as much notice as feasible to collaborate with all impacted parties. In addition, given that there are no good times for an outage, we ask impacted applications for some flexibility to make necessary adjustments to support a needed change for the campus.