Change Management Procedure

Overview

The UVA Health System increasingly relies upon technology in order to perform its roles of patient care and administration. The interdependencies of the existing systems are complex, and the results of changes made to one system may have serious consequences for the others, and thus for the continued successful operations of the enterprise. Change Management is an important discipline of the ITIL (IT Infrastructure Library). All changes to information systems will be approved by a change authority (Enterprise Change Coordinator, Change Coordinator, Change Manager, or Change Advisory Board (CAB) as appropriate; each is described under Key Definitions) and through the use of a documented change management process that defines key roles and responsibilities, and outlines the process for requesting, classifying, approving, rejecting, and executing changes to technology systems. Technology systems will include applications, data repositories, and all technology infrastructure components. The change management process includes a methodology for communicating approved changes and maintaining change records for audit purposes.

Purpose

Provides a framework for achieving better performance, enhancing business continuity, optimizing business risks, increasing accountability and improving reliability of technology services. Ensures that service availability is maximized and that Medical Center business processes are not adversely disrupted by undesirable changes to technology systems and components. Grants authority to technology organizations to create processes for consistently documenting, reviewing, and testing and approving changes to technology systems and services. Ensures that changes are communicated effectively to stakeholders,

Scope

The intended scope is to cover the following: Hardware – Installation, modification, removal or relocation of computing equipment (servers, storage, routers, switches). Change Management Procedure Rev?2.0 12/05/13 cskeens Page 2 Software – Installation, patching, upgrade or removal of software products including operating system, access methods, commercial off-the-shelf packages, internally developed packages, and utilities. Database – Changes to databases or files such as record format modifications, reorganizations and major maintenance. Application – Application changes being promoted to production as well as the integration of new application systems and the removal of obsolete elements. Moves, Adds, Changes and Deletes – Changes to system configuration. Schedule Changes – Requests for creating, deleting, or revising job schedules, back-up schedules or other regularly scheduled jobs managed by the IT organizations.

Description

The primary goal of change management is to accomplish IT changes in the most efficient
manner while minimizing the business impact, costs, and risks. All IT changes will be
documented change records in BMC Software’s IT Service Management (ITSM) system
maintained by Health System Technology Services (HSTS). A change record in ITIL is
defined as a record containing the details of a single change. The process includes the
following primary steps:

  • Formally Request/Enter a Change. All requests for change will be documented in ITSM Change Management. A new request for change will be completed by the Change Coordinator with input from the system owner or change requester.
  • Categorize the Change. The Change Coordinator will determine the type of change requested. Exhibit A defines the detailed change flows. At a high level:
    • Standard – A common change that has low risk and low impact, which follows an established process.
      • There is a defined trigger to initiate the request for change.
      • The activities/tasks are well known, documented and proven.
      • Configuration item (CI) will be related to the change.
      • Scheduled start and end dates are selected.
      • Approval is delegated to the Change Coordinator and Change Manager as required.
      • Tasks are implemented and the change moves to a completed status.
    • Normal – A normal category refers to a change that must follow the complete change management process. Normal changes are categorized according to risk and impact to the business, and they will be classified as moderate, high or major risk to the organization. All normal changes will be reviewed by the CAB.
      The Change Coordinator will:
      • Record the request for change in ITSM.
      • Configuration item (CI) will be related to the change.
      • Review, assess and evaluate the change request.
      • Confirm and assign tasks and resources.
      • Ensure all necessary documentation has been completed; if not completed, the request for implementation approval will be deferred:
        • Project/Task Plan
        • Risk Assessment – Describe any potential risks or negative consequences associated with the change.
        • Testing Plan – All normal changes will undergo testing and quality assurance to ensure reliability and performance of all components of the organization’s technology infrastructure.
        • Back-out Plan – Development of the back-out plan is essential to ensuring effective recovery in the event of a failed change.
        • Downtime Plan - If applicable, describe how end users will function in the event the system is temporarily inoperable.
        • Communication Plan – Describe how the end users will receive notification of the proposed change.
      • Ensure testing has been completed.
      • Select scheduled start and end dates.
      • Provide initial approval for the change.
      • Get CAB approval for implementation. If approved, implement the remaining tasks. If not approved, the Change Coordinator will complete the necessary requested items and resubmit for approval.
      • Implement tasks.
      • Post implementation review.
      • Move change to completed status and close.
    • Emergent – A change that must be introduced as soon as possible as the result of an urgent or critical event. This event must have significant impact on service.
      A Change Coordinator will:
      • Record the change required in ITSM.
      • Configuration item (CI) will be related to the change.
      • Document applicable plans.
      • Select scheduled start and end dates.
      • Emergent changes will automatically route via e-mail to the HSTS Admin On-Call for approval.
      • HSTS Admin On-Call will determine whether the change requires additional CAB member approval or notification.
      • If approval required and the CAB approves, complete tasks for implementation. If not approved, the Change Coordinator will complete the necessary requested items and resubmit for approval.
      • Move change to completed status.
      • Post implementation review.
      • Close change.
    • Latent – Circumstances will occur and changes will need to be made for certain business reasons immediately. A change that is detected and logged after implementation, which did not follow Standard or Normal Change Management is a latent change. For example, a provider will begin seeing patients today, but the provider has not been established in the doctor master file. An urgent call will be sent to HSTS, the provider will be added immediately to the file in production and then the change will be recorded in ITSM as a latent change.
      • Change request will be recorded.
      • Appropriate ITSM fields will be completed.
      • Actual start and end dates will be record along with the status reason.
      • Change Manager will be notified.
      • Change will move to the completed status.
  • Prioritize the Change. The Change Coordinator will assess the urgency and the impact of the change on the infrastructure, end user productivity, and budget. Levels of priority:
    • Emergency – A change that, if not implemented immediately, will leave the organization open to significant risk. NOTE: These must be kept to an absolute minimum due to the increased risk involved in implementing them.
    • High – A change that is important for the organization and must be implemented soon to prevent a significant negative impact to the ability to conduct business.
    • Routine – A change that will be implemented to gain benefit from the changed service.
    • Low – A change that is not pressing but would be advantageous.
  • Analyze and Justify the Change. The Change Coordinator works with the change requester to develop specific justification for the change and to identify how the change may impact the infrastructure, business operations, and budget. The Change Coordinators use this information to further research and develop an extensive risk and impact analysis. The following should be addressed:
    • The requirements and detailed description of the change.
    • The description of the positive impact the change will have on the business unit’s operation.
    • The effect/risk the change may have upon the end user, business operation, and infrastructure if known. The levels of risk are:
      • 5 – Major risk: Impacts most customers, major disruption to critical systems or impact to mission critical services.
      • 4 – High risk – Impacts several customers, causes disruption to critical systems or mission critical services.
      • 3 – Moderate risk: Impacts customers in a business unit, disrupts a portion of a business unit or critical service.
      • 2 – Low risk: Impacts a minimal number of customers, minimal impact to a portion of a business unit or non-critical service.
      • 1 – No risk.
    • Describe the effect of not implementing the change.
    • Estimate the IT, business and other resources required to implement the change, covering the likely costs, the number and availability of people required, the elapsed time, and any new infrastructure elements required.
    • Estimate any additional ongoing resources required if the change is implemented.
  • Approve and Schedule the Change. The Change Coordinator uses ITSM Change Management to record the process for routing to the technical approvers and, in the event of a major or significant change, to the Change Advisory Board (CAB) for approval or rejection of the change.
  • Plan and Complete the Implementation of the Change. This process includes developing the technical requirements, reviewing the specific implementation steps and then completing the change in a manner that will minimize impact on the infrastructure and end users.
  • Post Implementation Review. A post-implementation review is conducted to ensure the change has achieved the desired goals. All moderate, high and major risk changes must be reviewed by the appropriate Change Coordinator and Change Manager. In addition to making a success or failure decision on the change implementation, the review should also consider how the change was deployed, and whether it was implemented by the established date and within the approved budget. Post-implementation actions include deciding to accept, modify or back-out the change; contacting the end user to validate success; and finalizing the change documentation in ITSM Change Management.

This section describes the activities necessary for the organization to review their
effectiveness of Change Management. The Change Manager will conduct an annual review
that will include an examination of the following items:

  • CAB minutes.
  • Review records for implemented changes.
  • Review and analyze change management reports based on the following criteria:
    • Changes have been correctly logged, classified, assessed and executed.
    • All items raised at CAB meetings have been followed up and resolved.
    • Change reviews have been carried out on time.
    • Documentation is accurate, up-to-date and complete.

CAB: The Change Advisory Board (CAB) is a cross-functional group set up to evaluate
change request for business need, priority, cost/benefit, and potential impacts to other
systems or processes. The CAB will make recommendations for implementation, further
analysis, deferment, or cancellation.


Change: Any new IT component deliberately introduced to the IT environment that may
affect an IT service level or otherwise affect the functioning of the environment or one of its
components.


Change Coordinator: The role that is responsible for planning and implementing a change
in the IT environment. The Change Coordinator role is assigned to an individual for a
particular change by the Change Coordinator and assumes responsibilities upon receiving an
approved change request.


Change Management: One discipline of the ITIL framework which ensures appropriate
controls are placed around changes to IT systems and services to mitigate risks, ensure
stability, provide responsiveness to changing organizational requirements and minimize
service disruption.


Change Manager: The role that has the overall management responsibility for the Change
Management process in the IT organization.


Change Record: In the ITIL description, this is a record containing the details of a change.
Each change record documents the lifecycle of a single change. A change record is created
for every request for change that is received, even those that are subsequently rejected.
Change records should reference the configuration items that are affected by the change.


Configuration Item (CI): An IT component that is under configuration management control.
Each CI can be composed of other CIs. CIs may vary widely in complexity, size, and type,
from an entire system (including all hardware, software, and documentation) to a single
software module or a minor hardware component.


Enterprise Change Coordinator: Same responsibilities as a Change Coordinator but in
addition, can modify infrastructure change requests and tasks independent of any functional
roles or support group affiliations.

ITIL: The IT Infrastructure Library is a collection of internationally recognized best-practices
for delivering IT services, covering all aspects of service provision, quality assurance, and
providing a framework which allows customization of internal processes.


ITSM: IT Service Management from BMC Solutions that connect and automate ITIL
processes, such as incident, problem, change, asset, service level, configuration, and service
request fulfillment.

CAB TIMELINE

 

 

Thursday Friday Sat Sun Monday Tuesday Wednesday
Run Change Report (am) Send Agenda / Attendee List
Prioritize Agenda
    Meeting Prep: Run Reports CAB Meeting: 8am MCOG: 9am
Process CAB Approvals: 10am ? Noon
Sample CAB Agenda (based on Reports)
8:00am ? 8:10am: CAB Business
8:10am ? 8:20am: Financial Systems
8:20am ? 8:35am: Ancillary Systems
8:35am ? 8:45am: OR Systems
8:45am ? 8:55am: Infrastructure
8:55am ? 9:00am: Approval Summary

 

Document Supporting Resources