Change Management

PURPOSE

The objective of this Standard Operating Procedure (SOP) is to establish a systematic approach to managing changes within HIC. 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

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.

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

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

     1. Identifying the priority and category of change.

     2. Identifying the stakeholders and related communication plan. 

     3. Identifying the urgency and impact of the change. 

     4. Identifying the assets affected by the change. 

     5. Identifying the potential risks following the change. 

     6. Creating an Implementation Plan 

     7. Creating a Test Plan. 

     8. Creating a Roll-back plan.

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

3. Change Approval 

   • Standard Changes are not required to be approved by CAG.

   • Non-standard changes are reviewed and approved if applicable by the CAG.

4. Change Implementation

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

   • Change Building - When a change is approved, it will be built as documented. 

   • 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 outcome reported back to the CAG. 

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

   • During all above stages of the Change Workflow, the stakeholders will be kept informed of the process. 

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 Process

• Jira Change Management CAG Process

• For Definitions see ISMS Glossary

DOCUMENT CONTROLS