Change Management

PURPOSE

The objective of this Standard Operating Procedure (SOP) is to establish a systematic approach to managing changes within HIC (Health Informatics Centre). This SOP outlines the processes and responsibilities for identifying, assessing, approving, implementing, and reviewing changes to ensure they are effectively managed while minimising risks and disruptions to operations.

SCOPE

This SOP applies to all departments and personnel involved in initiating, evaluating, and implementing changes within HIC. This document provides a summary of each of the main sections of the change management process as is implemented by HIC. This document does not cover test or development work unless there is an impact on production or pre-production areas.

RESPONSIBILITIES

DEFINITIONS

• Asset: Anything that has a value to HIC services.

• Change Category: Defines a common scale against which to judge the magnitude of the change in terms of effort and risks.

• Change Description: Description of the change – what is being changed and how. 

• Change Impact Category: Defines a common scale against which to judge the magnitude of the change in terms of effort and risks: 

  • Extensive - There is a significant business service impact because multiple customers are affected by the change. Considerable human and technical resources are needed. Management is involved in the decision process. The RFC must be discussed in the CAG meeting and approved by the change manager. The change manager seeks advice on change authorization and planning. 

  • Significant - There is a clear service impact because at least one customer is affected by the change. The RFC must be discussed in the CAG meeting and approved by the change manager. The change manager seeks advice on authorization and planning. 

  • Moderate - There is little impact on current services because no customers are affected because of the change. The change manager can authorize this RFC. 

  • Minor - The change can be executed without prior approval from the change manager because no customers are affected by the change.

• Change Type: Defines the type of change being submitted for review: 

  • Standard Change – a low risk change that’s preapproved and follows documented, repeatable tasks. 

  • Non-Standard Change – a thorough review process is conducted before approving this change. 

• Change Urgency: Provides a comparator scale to measure how urgent the change is: 

  • Critical - The change is immediately necessary to prevent severe business impact. Change approval is needed by the CAG or Emergency Committee. 

  • High - The change is needed as soon as possible because of potentially damaging service impact. 

  • Medium - The change will solve irritating problems or repair missing functionality. This change can be scheduled. 

  • Low - The change will lead to improvements, changes in workflow, or configuration. This change can be scheduled. 

• Communication Plan: Detailed description of the communications to be provided during the change.

• Information: Any communication or representation of knowledge such as facts, data, or opinions in any medium or form including textual, numerical, graphic, cartographic, narrative, and audio-visual. 

• Project Management System: The database and software system used by HIC to store project details and documents relating to, in particular, approvals and data releases.

• RFC: Request for change. The RFC is the main reference for all documentation related to a change and supports the approval decision process. It should highlight the following: 

• Risk Assessment: Overall process of identifying and evaluating risk.

PRINCIPLES

1. Every change identified, either from external input or from an internal party, will go through a documented process. 

PROCEDURE

1. Request for Change (RFC) Initiation

• The Change Reporter completes a Standard or Non-Standard Change Management Ticket providing details such as the nature of the change, its purpose, scope, and potential impact.

• A Standard Change is defined as a documented process for change which has been reviewed and pre-approved by the CAG.

• Supporting documentation, such as risk assessments, cost estimates, and stakeholder analyses, may be attached to the change management ticket.

2. Change Validation

• A Standard or Non-Standard Change is validated by the Change Sponsor.

• Validation is the process of ensuring that the party requesting the change is indeed authorised to request it and that the request is appropriate.

• Change Requestor and Change Sponsor ensures the following are in place;  

  • Identifying the priority and category of change.

  • Identifying the stakeholders and related communication plan. 

  • Identifying the urgency and impact of the change. 

  • Identifying the assets affected by the change. 

  • Identifying the risks of making the change. 

  • Creating an Implementation Plan 

  • Creating a Test Plan. 

  • Creating a Roll-back plan.

• If necessary, the proposed change could be prototyped to gather as much information as possible 

3. Change Approval 

• A Risk Assessment Score is automatically calculated using the Risk Assessment Consequences/Likelihood assessment.

• Based on this assessment the following paths are available:

  • Standard Change

    • 1-8 → within Risk Appetite and does not require approval by CAG

    • 9-19 → requires CAG approval

    • 20+ → change is not approved as it is outside our risk appetite

  • Non-Standard Change

    • 1-8 → requires CAG approval

    • 9-19 → requires CAG approval

    • 20+ → change is not approved as it is outside our risk appetite

4. Change Implementation

• The Change Implementer develops a detailed change implementation plan, including tasks, timelines, resource requirements, and communication strategies.

  • Change Implementation – Following the approved implementation plan, in the event of a failure, the roll-back plan will be implemented or an Incident raised.

  • Change Testing – Following the approved test plan. 

  • Post Implementation Review – The change will be verified and reviewed with any issues logged on the ticket. 

  • Standard Change Creation – If applicable a standard change will be created to streamline future change requests. This will be reviewed by the CAG prior to availability for use. 

5. Change Communication

• Change Implementer follows communication plan and stakeholders are kept aware of change status.

6. Documentation and Record Keeping

• The process will be documented and stored within the Project Management system.  

  • If applicable, relevant documentation will be created or updated by the staff responsible. 

  • This process is parallel to the Change Workflow and does not necessarily finish when the Change Workflow ends.  

  • This may involve, but is not limited to, training for staff and instructions/guidelines to users. 

APPLICABLE REFERENCES

• Standard Change Processes

• How to Co-ordinate Change Management CAG Process

• How To Create a New Standard Change

DOCUMENT CONTROLS