Change Management Review (CMR) Process

Change Management Review (CMR) Process

Revised Charter v7

Updated April 10, 2019

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.

If you have other inquiries or process related question then contact CAB chair directly.

· A daily digest of all newly created change requests, along with the weekly change reports are distributed through this list.

Weekly CMR Meetings

The purpose of this meeting is to assess the risk and impact of changes collectively. If you have other inquiries or process-related questions, then contact your CAB chair directly or participate in the Next Gen meeting. This will ensure that we stay focused on the task at hand (review to assess risk and impact), mindful of everyone’s time, and your request receives proper attention.

· 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 at noon on the day 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 (including depreciation/decommissioning of a service).

· Any change that creates an outage or risks creating an outage for any campus-wide production service or application. “The Local Departments can use this process for their production systems.”

If Local Departments decide not to adopt our central change management process, then they should implement their own change management process.

· Any change that creates an outage, or has a risk of creating an outage for any campus wide production service or application. “This process can be used by the production system of Local departments or implement their own change management process” “ This process also applies to Local departments for their production system or they can implement their own change management process”

CMR Tickets

· CMR tickets are generated and stored on the Change Management module of ServiceNow.

CMR Types

· Normal - Any scheduled production change that creates an outage, or has a risk of creating an outage for an infrastructure service or application.

· Emergency – Unplanned outages or security actions that meet CMR ticket criteria.

· Standard - For your routine operational low-risk changes. Before you utilize the Standard Change type, it needs to be pre-approval by CAB. Here is the detail process on this change type.

See this link for the process of canceling your change request.

Lead Time for CMR Tickets

· Normal - changes require review in one CMR meeting prior to implementation. We recommend a two weeks lead time.

· Emergency – An emergency change does not have any required lead time, as it is intended to restore, or protect, a production service. Emergency changes must have a correlating incident number that describes the nature of the change. If the emergency transpires within the No Fly Zone, Director notification is required.

· Any change that must be completed prior to at least one weekly CMR meeting must be categorized as an emergency change.

· If you are submitting your change request during the curtailment period, and your implementation date is before the next CAB meeting, then select Emergency Change type.

· servicedeskteam@lists.berkeley.edu must be added to the “watch list” for any emergency change.

· Standard - Submit these changes one week before the implementation since we only review Standard changes during the campus No-Fly period.

Type of Outages

· Planned - Use Planned outage if your service is going to experience an outage with your change.

· None - Use None outage if your service is not going to be impacted by this change. If there is a chance of an outage, then add that to the Risk and Impact Analysis.

· Unplanned - Use Unplanned outage only when there is an unexpected incident (after the fact incidents), or unexpected outage occurred during the change.

No Fly Zone (no major infrastructure/services 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, during the activation of Emergency Operation Center (EOC), BigGive, etc.

· Changes deemed critical for the No Fly Zone will require a Director’s approval.

See this link for detail information on the No-Fly request process

General Change Management Process

· Risks and impacts for proposed changes should be identified and explored with impacted groups prior to the CMR meeting.

· In the Risk and Impacts section, provide as much information as possible. Some examples; systems it would impact, customer/group that will be impacted, or the number of users impacted. If the impacted systems and customers are more than 5, then added as an attachment.

· 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.

· If your previously approved change is now scheduled to newer dates, then update change board via email changeboard@lists.berkeley.edu.

· If your previously approved change request is now associated with a major incident, then cancel your change request, and open again once the resolution is in place. See this link for the process of canceling your change request.

· Update any documentation to reflect the change such as; KB Articles and or wiki.

· If your previously approved change now has a newer date and time, then you can send an email to changeboard@lists.berkeley.edu for the update, and see if anyone has any concern. Lookout for No-Fly period so that you are not rescheduling during those time.

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 cannot 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 possible 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.

Change Management Metrics and Reporting

Below are Key Performance Indicators (KPIs) to measure the success and efficiency of the Change Management process.

· A monthly report via email will include

· Number of Incidents caused by Change Request. To reduce in the number of failed changes/increase change success rate.

· Total Emergency Changes for the month. To reduce the number of emergency changes.

· Emergency Changes due to lack of planning. To improve the lead time.

· Annual report via email will include

· A total number of changes in a year.

· A total number of Emergency Changes in a year.

· Percentage of incidents caused by Change Request.