Body
Objective
Creighton University Information Technology has decided to implement a change management process that will allow its users to request, manage, approve, and control changes that modify services as defined in the IT Service Catalog.
This document is intended to provide a high-level overview of the change management process, and is to be used as reference for all IT staff to clearly understand the procedures put in place to manage qualified changes through the University’s centralized information technology environment.
Definitions
Change - For the purposes of this document, a Change is defined as the addition, modification, or removal of a configuration item (CI), service, or service component, and/or its associated elements.
Back Out Plan - A contingency plan of step-by-step instructions with defined success criteria (with sufficient detail to allow an individual with similar skills to execute the plan and is understood by all approvers) to minimize any disruption of service if a change implementation does not go as planned.
Change Advisory Board (CAB) - A dynamic group of people that is convened weekly and whose specific membership depends upon the change. The CAB approves Changes to the IT infrastructure.
Configuration Item - Configuration Item or CI refers to the fundamental structural unit of a configuration management system. Examples of CIs include documents, hardware, software, models, plans, and people.
Requests for Change (RFC) - Tickets submitted to request a change to systems, infrastructure, hardware, software, or services defined in the IT service catalog. Also known as a Change Request.
Change Manager (CM) - Responsible for the Change Management process and authorizes all changes.
Forward Schedule of Changes (FSC) - Contains details of all RFCs and their proposed implementation date.
Minor Change – A change that has low impact on business and does not consume lots of resources. The departmental Change Manager approves the Minor Changes.
Standard Change – Pre-authorized changes that are considered to have little to no risk associated with them. They are common occurrences that have specific guidelines and procedures which they follow. Standard Changes MUST be submitted through Change Management, but do not require CAB approval.
Normal Change – A change that is characterized as having substantial impact, and requires approval from the CAB.
Urgent Change – A request for a change that will impact service levels or increase risk if it is not implemented before the CAB convenes to approve it. An Urgent Change must be approved by the CAB prior to execution of the change.
Emergency Change - A change required to immediately restore service or to avoid an outage where no other workaround is available. Authorization for Emergency changes is not needed by the Change Management Procedure. A Change Request must be entered after change implementation for tracking and documentation purposes. Also known as break/fix.
Requester - The person responsible for documenting, planning, coordinating, implementing (or assigning an implementer) and closing a Request for Change. This person inputs the Change Request into EasyVista.
Implementer - The person/assignee or group of individuals who perform implementation of a change activity. If the Implementer does not have Change Management system access, it is the responsibility of change manager to close the Change Request with success/failure detail.
Post Implementation Review (PIR) - Review of changes from the prior change period. Should include noting any problems/resolutions with changes performed during that period.
CAB Structure and Types
The Change Advisory Board (CAB) consist of groups of associates and a designated change manager who have decision authority on the implementation of changes. CAB members should have a clear understanding of the customer and business needs and the user community, as well as the technical development, support functions, and environments.
There are two types of CABs at Creighton University.
· Local/Departmental CABs – Minor changes are reviewed and approved by local management. Not a significant enough change to go to the full CAB.
· CAB – Standard weekly CAB where normal and standard changes are reviewed and approved. CAB may also include PIRs on changes that did not go as planned or PIRs on emergency changes.
Change Types
Normal Changes
Normal changes must be submitted to CAB through the RFC process. Normal changes require CAB approval before the change is implemented. A normal change with a complexity and/or risk rating of high must be submitted with a fully documented test plan, communication plan, back out plan, and post implementation testing plan. Failure to sufficiently document these plans in the RFC will lead to delays. RFCs for changes with medium or low complexity and/or risk may be submitted with less formal test plan, communication plan, back out plan and post implementation testing plans documented in the ticket. All of the above-mentioned plans are required fields in the RFC form and some information is expected to be submitted with each RFC, only the robustness and thoroughness of the details are affected by the complexity and risk ranking.
Standard Changes
Standard changes are only classified as such by the CAB. Any change that appears to be a standard change must be classified as such by the CAB following the submission of an RFC and the petitioning of the change requestor to reclassify future changes, matching the characteristics of the submitted change, as a standard change.
Standard changes require the submission of an RFC, the biggest difference between a standard change and a normal change is the standard change, by definition, does not require CAB approval. However, documentation of the change is still required by submitting an RFC for the standard change. By definition a standard change will not have a high complexity or risk ranking and therefore only requires brief test, communication, back out and post implementation test plans/explanations.
Standard changes will not be approved by CAB but implementers and/or requesters should still ensure all affected parties are aware of the standard change. Communicating upcoming standard changes in CAB is one preferred method of communication. The submission of a standard change RFC ensures that all changes to CIs are tracked and documented.
Urgent Changes
Urgent changes are those changes that cannot wait for the next CAB meeting for approval. Urgent changes are NOT intended to be used to compensate for poor planning. Poorly planned changes should be rescheduled and submitted as normal changes at a later time. Manager approval is required for all urgent changes, manager approval is intended to enforce the CAB process by not allowing poorly planned changes to be submitted as urgent. Once a manager approves an urgent change, the change is submitted to the eight CAB groups for approval. Each CAB group has a primary and secondary member. The CAB groups are as follows:
- Application Administrators
- Customer Support
- DBA / Warehouse
- Desktop Engineering
- Information Security
- Network and Infrastructure
- Data Team
- System Administration
Urgent changes require one voting member in 5 of the 8 CAB groups to approve for the change request to be moved to the implementation phase. Voting members of each group will receive an email with pertinent information regarding the urgent change and voting buttons. Approve and reject buttons will be available in the email. Approve button is self-explanatory, however the reject button comes with some severe consequences. If a CAB approver does not understand the change, requires additional information, or does not agree with the change, that approver should reach out to the requester or implementer for further clarification. The use of the reject button by any approver will immediately close the ticket without approval and require that the submitter start over with a new RFC. The Reject button should be used sparingly and only if the intent is to close the ticket. In the same vein, if an approver reaches out to a requestor or implementer of an urgent RFC with questions, comments, concerns; those questions and concerns should be addressed regardless of the approval process. Even if five approvals are received but one approver has asked questions or has objections, the requester or implementer must address the questions or concerns before moving to implementation. Failure of a requester or implementer to resolve issues or concerns raise during the approval process could lead to the revocation of CAB privileges.
Emergency Changes
Emergency changes are also known as Break/fix. A CI requires immediate action to restore service or prevent further degradation of service and there is no time for CAB or e-CAB approval. In cases of break/fix an emergency RFC should be submitted after the fact, after the change has been made to restore service. The intent of the RFC after the fact is to track all changes made to Cis, regardless of the timing or planning. Emergency RFCs do not require CAB approval because the change has already been made. All emergency changes will be reviewed in the PIR process during the CAB meeting following the change. The implementer or person/persons with the best knowledge of the situation requiring the emergency change should be at the CAB meeting to discuss the emergency change. The emergency change process is NOT intended to be used for a change other than emergency break/fix changes. If CAB determines that an emergency change was improperly used with the intent to circumvent the CAB process, disciplinary action may be sought, including revocation of CAB privileges.
CAB Process Overview and Agenda
Overview:
All normal Changes are passed to the Change Advisory Board (CAB). The CAB consists of a group who has the authority to assess and advise the Change Manager of the RFCs that are presented to them. The CAB consists of both permanent and ad-hoc members. The individual CAB members represent a variety of technical, business, and customer perspectives. This varied viewpoint is an integral part of the Change Management Process to balance the need for change with the need to minimize inherent risks.
Only the permanent members of the CAB have voting rights, however, input from ad-hoc members carries a lot of weight in the approval process.
A request for change must be submitted prior to the weekly CAB meeting in order to be reviewed and approved in CAB.
It is conceivable that an RFC could be submitted before CAB, reviewed at CAB, approved by CAB and implemented immediately following CAB. Although this scenario is possible there would have to be significant work performed before hand by the requestor, implementer or both. In order for a normal change to be approved, sufficient planning must have occurred before RFC submission. The implementer and all affected groups and users must be notified and ‘communicated’ with and fully understand the change and impact of the change. The service desk must understand the change and impacts of the change. A fully documented and executed test plan should have been executed involving all affected parties. A communication plan regarding the change should have been developed, documented and executed prior to implementation. A fully documented back out plan should be developed prior to the change and all affected parties are in agreement with the back out plan. In short, any change that is rushed through CAB must be well thought out and communicated with all affected parties or the change will be denied or rescheduled. CAB is not the place to present surprises or quickly conceived change requests. They will be denied or rescheduled. It is acceptable, however, to submit an RFC weeks or months in advance to gauge the attitude and opinions of those in CAB.
Finally, the most important activity the CAB performs is the evaluation of the Change Management Process itself. This group helps monitor the Change Management Process, identifies any deficiencies, and recommends improvements.
Agenda:
Changes from the last meeting reviewed and agreed to
- Reviews of decisions made last CAB meeting
- Reviews status of any open actions from last CAB meeting
- Review and possibly approve new change RFCs
- CAB will enforce a first in prioritization. RFC submitted first will be given priority on change time slots.
Discussion of newly submitted Requests for Changes and decision to request more information
- Assess the prioritization and type for the change
- Assess the impact of not doing the change
- Assess the impact to the live environment
- Decide the status of approved changes in regard to schedule, implementation phase, implementation resources, priorities, regulatory requirements and costs
- Forward Schedule of Changes review and agreement including new RFC’s approved
- Assess applications for Standard Pre-Approved Changes
- Review of Post Implementation Reviews
- Review the Change Management Process
CAB Approval Process
Before an RFC is approved, the change requestor must be able to answer “Yes” or “N/A” to the following requirements:
- Disaster Recovery
- Backup
- Testing Completed
- myIT Alert sent
- Checked for Vulnerability
Disaster Recovery:
For a technology add, replace, change, move, or retirement, the change requestor must ensure the following requirements have been completed well in advance of the effective date of the change:
- BCDR Plan – Updates depend on the changes affecting ownership and organization.
- DR Technology Master (16 data groups) – Updates depend on what is affected.
- Recovery Layers – Updates depend on information from #2 above
You will need to work with the BCDRP Coordinator. It is helpful to have a System or Architecture Diagram (affected interface technologies and/or areas) and an estimated go-live or effective date.
Backup
Does this technology need to be added to, or removed from, the regular nightly backup schedule? A ticket is required to be submitted to the System Administrators in advance of the effective date of the change.
Testing Completed
Has this change been validated in a test environment? Testing must be completed prior to change approval.
IT Alert sent
Has this change been communicated to campus via the IT mailing list? Alerts should be sent 7 days prior to the effective date of the change.
Checked for Vulnerability
A vulnerability assessment must be completed and any issues identified resolved or accepted in writing prior to this change going live. Ideally this process occurs during the development process, where the test/dev system is scanned for vulnerabilities and remediated and production is built based on the clean environment.
CAB Responsibilities and Frequency
Responsibilities:
- Assessment of RFCs – considering impact, availability of resources, priorities, authorization and coordination of changes
- Provide advice to the DoIT Change Manager on whether to approve changes
- Confirm, review and agree to the FSC
- Review Change Management metrics
- Discussion of topics affecting the Change Management Process
- Discussion (from a change management perspective), of topics affecting the business
- Review of Post Implementation Reviews
- Review backed out and failed Changes
- Assess and advise the IT Change Manager to approve a Standard Pre-Approved Change application
Frequency:
CAB meets regularly on Thursdays at 1:00 pm Central time. The meeting may occasionally be moved to a different day to accommodate University holidays or closures.
Roles and Responsibilities
Creighton IT CAB Chairperson
- Pre-CAB meeting preparation:
- List of changes to be presented
- Update existing Forward Schedule of Change
- Determine non-permanent attendees
- Schedule room etc.
- Documents any updates on old business
- Distribute Change Management Reports
- Review of changes
Post CAB meeting activities:
- Update the schedule
- Communication of approve / rejected changes
- Actions items / who assigned to
CAB Membership Composition
The Change Advisory Board (CAB) needs to have representation from the entire organization. This is impractical due to the number of individuals that would be required. To streamline this requirement, membership is defined as including permanent members who attend all meetings and ad hoc members who attend the meeting based on the agenda. Each permanent member of the CAB has a named designated backup. In the event that a member (or the designate) does not attend the CAB meeting, they implicitly approve all CAB decisions.
CAB Permanent Members:
- IT Change Manager (Chair)
- Manager of the Central Action Center
- Member of the DBA / Warehouse Team
- Member of the Application Administrators Team
- Member of the Desktop Engineering Team
- Director of Enterprise Applications
- Director of Enterprise Applications
- Director of Enterprise Applications
- Director of Enterprise Applications
Ad hoc membership can include:
- Members of the campus community who submitted a RFC.
- Members of the campus community who may be impacted by a change to be discussed
- Members of the campus community who have an interest to learn more about upcoming changes.
Maintenance Window
The University has established and communicated a standard maintenance window where changes can take place. During this maintenance window, there is no expectation of system functionality. Creighton IT has communicated that during Friday evenings from 10pm – 2am maintenance on systems may occur, we will communicate these changes as best as possible but there should be an expectation of system inability during this time.
There will be times when changes are requested to be made outside the maintenance window. These changes should have little to no noticeable impact on our user groups, or the non-standard time is agreed by the impacted user group, or Creighton IT requires the change be made during a time when support is available and full testing of the change can be accomplished after the change. It is at the discretion of the RFC requester or implementer to request a non-standard (outside the maintenance window) change, however, all non-standard changes must be approved by the CAB.
Contact Information
|
Name:
|
Bryan McLaughlin
|
|
Role:
|
CAB Chairperson
|
|
Department:
|
Information Technology
|
|
Phone:
|
402-280-2386
|
|
Email:
|
bmclaughlin@creighton.edu
|
If this article did not help, please review the Related Articles.