Change management refers to a formal process for making changes to IS (Information Services) services or 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 minimizes disruption to services and customers. Change management includes the following steps:<\/p>\n\n\n\n
This policy applies to all changes to IS services and systems provided by St Mary\u2019s University Information Services. The primary functional components covered in the Change Management process include:<\/p>\n\n\n
Hardware<\/strong> \u2013 Installation, modification, removal, or relocation of servers or network-related equipment.<\/p>\n Software<\/strong> \u2013 Installation, patching, upgrade, or removal of software products, including operating systems, integrations between systems, third-party applications, authentication to AD (Active Directory), and internally developed packages and utilities.<\/p>\n Database<\/strong> \u2013 Changes to databases or files such as major upgrades, additions, reorganization, and major maintenance.<\/p>\n Application<\/strong> \u2013 Application changes being promoted to production, as well as the integration of new application systems and the removal of obsolete elements.<\/p>\n\n\n Changes to major systems configuration for conflict between integrations.<\/p>\n\n\n Scheduled Changes<\/strong> \u2013 Requests for creation, deletion, or revision to job schedules, backup schedules, or other regularly scheduled jobs managed by the IS Units.<\/p>\n Telephony<\/strong> \u2013 Installation, modification, de-installation, or relocation of PBX\/VOIP equipment and services.<\/p>\n Classroom Technology<\/strong> \u2013 Any modification or relocation of desktop equipment and services for users or classroom labs.<\/p>\n Changes made to non-priority IS components<\/strong> \u2013 such as systems that are not yet in production, development environments or testing environments – are outside the scope of this policy.<\/p>\n\n\n All changes to IS services and systems must follow a standard process to ensure appropriate planning and execution.<\/p>\n\n\n\n Changes will be categorized as Standard change<\/em><\/strong>, Significant change<\/strong><\/em>, or Emergency change<\/strong><\/em>.<\/p>\n\n\n\n Appropriate processes and levels of review shall be applied to each type of change commensurate with the potential of the change to disrupt university operations.<\/p>\n\n\n\n It is the responsibility of the IS unit Director to ensure that all areas under their direction have followed the documented process.<\/p>\n\n\n\n There are three types of changes based on approvals needed through the change management process.<\/p>\n\n\n\n How to use this matrix:<\/p>\n\n\n\n First, determine the priority level of the component or service<\/strong>. Then assess the risk of the proposed change \u2013 low, medium, or high. The matrix shows whether the type of change is then Standard or Significant. (Note: an emergency change is the same as a significant change, but with an expedited timeline.)<\/p>\n\n\n\n For example:<\/em> A high risk<\/strong> change to a priority 1<\/strong> IS service (or IS component) is a significant change. A low-risk<\/strong> change to a priority 3<\/strong> service is a standard change. A medium risk<\/strong> change to a priority 2<\/strong> service may be standard or significant.<\/p>\n\n\n\n What is the Priority Level of the service?<\/strong> <\/p>\n\n\n\n See the list of IS Components, or the \u201cRisk and Change Type Matrix,\u201d to determine priority of the service. <\/p>\n\n\n\n What is the risk associated with the change?<\/strong> <\/p>\n\n\n\n To calculate risk, consider assurance (our confidence that the change will go as planned) and potential negative impact on services from a customer perspective. Then take the combined score to assign a risk score. <\/p>\n\n\n\n <\/p>\n\n\n\n Assurance Calculation:<\/strong> <\/p>\n\n\n\n Impact Calculation:<\/strong> <\/p>\n\n\n\n Change Type:<\/strong> <\/p>\n\n\n\n This is a combination of priority and the overall risk score. <\/p>\n\n\n\n The members of the Change Advisory Board (Please refer to RFC \u2013 Change Advisory Board Membership)<\/em> provide a due diligence readiness assessment and advice about the timing for any change requests (CR) that are referred to it for review. This assessment should ensure that all changes to the IS environment are carefully considered to minimize the impact on campus users and existing services or systems. <\/p>\n\n\n\n CAB members are responsible for: <\/p>\n\n\n\n Any decision to move forward with a CR should include an advisory review by the CAB in advance for Significant changes and after the fact for Emergency changes. <\/p>\n\n\n\n All changes, evaluations and approvals will be documented to allow customers to understand what has changed, the reason the change was implemented and the process that was used to make a change. The following details will be logged for each change and are found in the Request for Change (RFC). <\/p>\n\n\n\n RFC must be submitted for review two weeks prior to the monthly maintenance window.<\/p>\n\n\n\n Emergency RFC\u2019s will be submitted in a timely manner and may occur post change, an e-mail notification is required from the ECAB membership to identify the change.<\/p>\n\n\n\n Request for Change (RFC)<\/strong><\/p>\n\n\n\n Definitions adapted from Information Technology Infrastructure Library (ITIL). <\/p>\n\n\n\n Assurance<\/strong> – The level of confidence that the change will go as planned and is determined by experience and complexity.<\/p>\n\n\n\n Change<\/strong> – The addition, modification, or removal of approved, supported, or baselined hardware, network, software, application, environment, system, or associated documentation.<\/p>\n\n\n\n Change Advisory Board<\/strong> – A group of people who can advise on change management and the implementation of these changes.<\/p>\n\n\n\n Change Control<\/strong> – The procedure to ensure that all changes are controlled, including the submission, analysis, decision making, approval, implementation, and post-implementation of the change.<\/p>\n\n\n\n Change History<\/strong> – Auditable information that records, for example, what was done, when it was done, by whom and why.<\/p>\n\n\n\n Change Management<\/strong> – Process of controlling changes to the infrastructure or any aspect of services in a controlled manner, enabling approved changes with minimum disruption.<\/p>\n\n\n\n Request for Change (RFC)<\/strong> – The compilation of changes described by the service owner that will affect existing services. Submitted for each change.<\/p>\n\n\n\n Emergency Change<\/strong> – This is a significant change but must be executed with utmost urgency. (See \u201cSection A – Types of Changes\u201d for more information.<\/em>)<\/p>\n\n\n\n Impact<\/strong> – Determined by potential disruption to customers and dependent systems.<\/p>\n\n\n\n IT Component<\/strong> – A system, device, application, or document that is part of an IS service or system.<\/p>\n\n\n\n IT Service<\/strong> – An IS service or system is a customer-oriented offering and\/or consumption of a technology-based transaction. <\/p>\n\n\n\n Significant Change<\/strong> – A change with fewer well-known risks or less predictable outcomes, and\/or a change that is not regularly made during business. (See \u201cSection A – Types of Changes\u201d for more information.<\/em>)<\/p>\n\n\n\n Peer<\/strong> – Another IS professional that can review a change and understand the technical elements involved. <\/p>\n\n\n\n Process Log<\/strong> – A central repository of all Significant and Emergency 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.<\/p>\n\n\n\n Risk <\/strong>– Is determined by a combination of the relative assurance that a change will happen as expected and the potential impact of a change should it not go as expected.<\/p>\n\n\n\n Standard Change<\/strong> – A change with readily known risks that is regularly made during business and whose outcomes are predictable. (See \u201cSection A – Types of Changes\u201d for more information.<\/em>)<\/p>\n\n\n\n <\/p>\n","protected":false},"featured_media":0,"parent":0,"menu_order":0,"template":"","class_list":["post-3489","it-services","type-it-services","status-publish","hentry"],"acf":[],"yoast_head":"\nPolicy<\/h2>\n\n\n\n
Minimum Standards<\/h3>\n\n\n\n
\n
Section A \u2013 Types of Changes<\/h3>\n\n\n\n
Types of Changes<\/h4>\n\n\n\n
\n
Section B \u2013 Risk Assessment<\/h3>\n\n\n\n
Risk and Change Type Matrix<\/h4>\n\n\n\n
RISK<\/th> Low<\/th> Med<\/th> High\/Guaranteed<\/th><\/tr><\/thead> Priority 1 Service\/System <\/strong>
Crosses functional boundaries, serving the business functionality of many units. It is critical to the ability of the University to meet its business and regulatory obligations, support the delivery of education, or administer research. It has strategic value to the campus such that encouragement of widespread use is desirable. <\/td>Standard<\/td> Significant or Emergency<\/td> Significant or Emergency<\/td><\/tr> Priority 2 Service\/System <\/strong>
The system is a feeder to Priority 1 systems; or is a system that does not cross functional boundaries but is still critical to the ability of the University to meet its business and regulatory obligation. <\/td>Standard<\/td> Standard
or
Significant
or
Emergency<\/td>Standard
or
Significant
or
Emergency<\/td><\/tr>Priority 3 Service\/System <\/strong>
Any departmental system that supports the internal operations of any department or departmental function and does not cross functional boundaries. <\/td>Standard<\/td> Standard<\/td> Standard<\/td><\/tr><\/tbody><\/table> Sample Priority, Risk and Change Type Assessment<\/h4>\n\n\n\n
<\/th> Yes<\/th> No<\/th><\/tr><\/thead> Have we made this change before? <\/td> Risk +0<\/td> Risk +1<\/td><\/tr> Is the change simple to make? <\/td> Risk +0<\/td> Risk +1<\/td><\/tr> Do we have a clear understanding of everything the change will do? <\/td> Risk +0<\/td> Risk +1<\/td><\/tr><\/tbody><\/table> <\/th> No<\/th> Yes<\/th><\/tr><\/thead> Will this change be noticeable to customers? <\/td> Risk +0<\/td> Risk +1<\/td><\/tr> Could this change impact on other services or systems? <\/td> Risk +0<\/td> Risk +1<\/td><\/tr> Could this change result in an extended service interruption if it goes badly? <\/td> Risk +0<\/td> Risk +1<\/td><\/tr><\/tbody><\/table> <\/th> Risk Score 1-2 Low<\/th> Risk Score 3-4 Medium<\/th> Risk Score 5-6 High<\/th><\/tr><\/thead> Priority 1<\/strong><\/td> Standard<\/td> Significant<\/td> Significant<\/td><\/tr> Priority 2<\/strong><\/td> Standard<\/td> Standard or Significant<\/td> Significant<\/td><\/tr> Priority 3<\/strong><\/td> Standard<\/td> Standard<\/td> Standard<\/td><\/tr><\/tbody><\/table> Section C \u2013 Change Management Roles<\/h3>\n\n\n\n
Change Advisory Board (CAB)<\/h4>\n\n\n\n
\n
\n
Section D \u2013 Process Examples<\/h3>\n\n\n\n
Change Plan Documentation<\/strong><\/h4>\n\n\n\n
\n
\n
Definitions<\/h2>\n\n\n\n