This document outlines the change management policy expected to be adhered to by all employees of Hamurlabs.
The primary objective of Change Management (CM) is to enable changes to be made, with minimal or no disruption to the services we provide to our customers. Change Management will work in conjunction with other Hamurlabs policies related to ITIL and IT Service Management (ITSM). The goals of the Hamurlabs Change Management Policy include establishing a standard process for requesting, planning, communicating, approving, implementing and reporting changes to our Services. The owner of this policy is the Hamurlabs Chief Operating Officer.
| Roles | Description |
|---|---|
| Change Requestor | Anyone who wants to raise a request for change (RFC) |
| Change Owner | Person who ensures the assessment, prioritization, scheduling, communication, and delivery of the change |
| Change Implementer | Person who creates, builds, tests, and deploys the change |
| Change Management Process Manager | Person who administers the change process, ensuring all necessary process steps are completed and improvements are raised, when necessary |
| Change Approver | The person/group who approves the change(s) |
| CAB (Change Advisory Board) / ECAB (Emergency Change Advisory Board) | The group/body who exists to support the authorization of change and to assist Change Management in the assessment, prioritization, and scheduling of change, resolving priority conflicts. |
| Change Type | Definition | Technical Approval prior to CAB | CAB Submission Deadline |
|---|---|---|---|
| Standard |
A routine change that is low risk, relatively common, and follows a pre-defined procedure. Customer approval is still required. For a Normal change to be upgraded to a standard change, it must have been completed successfully three times as a normal change and the procedure documented. The creation of the standard template requires approval by the change manager. |
No | No |
| Normal | A change to an existing service, system, application, or infrastructure component with potential impact which may require CAB approval before being implemented. | Yes | 3 hours before CAB for high risk changes only |
| Emergency | A change that must be implemented as soon as possible, for example, to resolve a major Incident, implement a security patch or to prevent an imminent failure. | Yes | Emergency CAB required |
When assessing a change, a risk assessment is undertaken using the following criteria:
When assessing a change, an impact assessment is undertaken using the following criteria:
For each change type, the following approval matrix needs to be adhered to:
| Change Type | Technical Approval | Customer | CAB / ECAB |
|---|---|---|---|
| Standard | No | Yes | No |
| Normal | Yes | Yes | Risk related |
| Emergency | Yes | Yes | Yes |
Technical approval must be given by a higher skilled engineer or peer (of the technology/technologies related to the change) of the engineer implementing the change. If the engineer planning and implementing the change has no reviewer of an equivalent or higher skillset, then the change must be set as a high risk and assessed by the CAB / ECAB.
Individual customer approval (for changes related to one customer only) must only be accepted from an authorized customer representative.
All Emergency changes are to be reviewed by the CAB / ECAB, where they will be approved or rejected. This is in addition to technical and customer approval.
A change in response to a major incident where the remedy requires immediate action and will be approved by the Major Incident Manager with evidence of retrospective approval from the customer being requested as soon as reasonably practicable.
All changes should be carried out as described in the RFC and within the designated planned times. If a variation is identified during the change, then this must be presented to either a member of the Change Management team or the Duty Manager to approve the variation. This variation must then be documented in the change notes. If the variation is not approved, this will result in the change being backed out. This change will then need to be re-planned and re-raised.
Following the implementation of the change, tests in line with the testing plan set out in the change must be carried out to ensure that the desired result has been verified. If a change has not met the acceptance criteria, then the back-out plan must be invoked, as detailed in the RFC.
Once the change has been tested and validated, the change status is changed to completed.
A change review should be carried out to confirm that the change has met its objectives, that the change initiator and stakeholders are happy with the objectives, and that there have been no unexpected side effects (e.g., no P1 incidents after implementation). Spot checking of changes rather than large scale PIRs is acceptable for successful changes, however, a PIR is mandated for changes that have been rolled back, led to unexpected service impact, or changes where there was a variation during implementation.
Once the change owner has satisfied themselves that all stages of the change life cycle have been completed, the change can be closed.
For planned changes which may cause outage or serious performance degradation for multiple customers, notifications must be issued at least 14 days in advance. In emergency situations, the 14-day notice period may be waived.
