Change Management Guidelines
This article covers how to raise a change request and includes documented steps, a video and some helpful hints and tips. Note the documented steps can be found at the bottom of this article.
Goal of Change Management
The goal of Change Management is to ensure that standard methods and procedures are used for efficient and prompt handling of all changes to minimise the impact of any changes upon Accelerant services/systems and achieve zero unauthorised change.
The goal of Change Management is to ensure that standard methods and procedures are used for efficient and prompt handling of all changes to minimise the impact of any changes upon Accelerant services and systems and achieve zero unauthorised changes.
Video: How to raise a Change Request
How to raise a Change Request
Hints and Tips
- Please ensure a change request is raised as early as possible to ensure enough time for the CR to be reviewed and approved.
- Please ensure all resources are aware and are listed in the change request.
- Adding links to User Stories can be a good way to provide evidence of testing results, sign-off etc.
- When a CR is raised it's status is "Open" by default". Please change the status to "Planning" in order to submit the CR to Change Management.
- If you're unsure of the status of the CR please contact a Change Manager (Chris Mitchell, Nilesh Chandode).
- Once a CR is implemented please chnage the status from "Pending Release" to "Pending Review". This will automatically assign the CR to Change Management for closure.
Change Process Stages
Change Request assigned to Change Manager
Change Manager reviews and resolves any discrepancies with Change Requester
Change Manager moves change to approval phase
Change Request assigned to appropriate approvers
Change Request reviewed by approvers and either approved or rejected
Once approved Change Requester notified
If rejected Change Request is closed
Change Requester to co-ordinate implementation of change with implementer(s) in accordance with the implementation plan
Implement Change Request
Close all implementation tasks
Add note to Change Request confirming success/failure
Change Manager to determine if Post Change Review (PCR) is required
If No, move change to closure phase
If Yes, hold PCR and update Change Request accordingly
Ensure follow up actions are resolved prior to moving change request to closure
Change Request assigned to Change Manager
Change Manager reviews and resolves any discrepancies with Change Requester
Change Manager moves change to approval phase
Change Request assigned to appropriate approvers
Change Request reviewed by approvers and either approved or rejected
Once approved Change Requester notified
If rejected Change Request is closed
Change Requester to co-ordinate implementation of change with implementer(s) in accordance with the implementation plan
Implement Change Request
Close all implementation tasks
Add note to Change Request confirming success/failure
Change Manager to determine if Post Change Review (PCR) is required
If No, move change to closure phase
If Yes, hold PCR and update Change Request accordingly
Ensure follow up actions are resolved prior to moving change request to closure
Change Request assigned to appropriate approvers
Change Manager convenes Emergency CAB
Change Request reviewed by approvers ay Emergency CAB and either approved or rejected
Once approved Change Requester notified
If rejected Change Request is closed
Change Requester to co-ordinate implementation of change with implementer(s) in accordance with the implementation planImplement Change Request
Close all implementation tasks
Add note to Change Request confirming success/failure
Change Manager to determine if Post Change Review (PCR) is required
If No, move change to closure phase
If Yes, hold PCR and update Change Request accordingly
Ensure follow up actions are resolved prior to moving change request to closure
Change Manager to determine if Post Change Review (PCR) is required
If No, move change to closure phase
If Yes, hold PCR and update Change Request accordingly
Ensure follow up actions are resolved prior to moving change request to closure
Change Types
A minor change is one that is not a standard change, major or emergency.
Minor change requests follow a prescriptive process which requires two levels of approval before being implemented, reviewed, and closed. These changes require a full range of assessments and authorizations such as peer or technical approval and change management, to ensure completeness, accuracy, and the least possible disruption to service. These changes are most often scheduled outside of defined change blackout windows or during defined maintenance windows but can be scheduled during operational hours when the risk and impact is low.
A major change is one that is medium to high risk and not an emergency.
Major change requests follow a prescriptive process which requires two levels of approval before being implemented, reviewed, and closed. These changes require a full range of assessments and authorizations such as peer or technical approval, business approval, change manager approval, and CAB authorization, to ensure completeness, accuracy, and the least possible disruption to service. These changes are most often scheduled outside of defined change blackout windows or during defined maintenance windows.
A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch. This change is of such a high priority that it bypasses group and peer review and approval and goes straight to the Authorization state for approval by the CAB approval group.
Emergency changes cover the following types of emergencies:
These changes do not follow the complete life cycle of a normal change due to the speed with which they must be authorized. Therefore, they progress directly for approval from the IT CAB members.
Note: Standard Change will not be used until the change process is implemented in Freshservice and has been running for a period of at least 6 months.
A standard change is a pre-authorized change that is low risk, relatively common and follows a specified procedure or work instruction.
Before a change can become ‘standard’ it must have been implemented at least once through the minor change process as a proof of concept.
All standard changes must have a fully documented approved standard change model.
Change Risk
Typically applies to Non-Critical Systems or Mission Critical systems if the risk and impact are negligible
Has been implemented multiple times without issue
Potential impact is limited to a few users or a single department
Cannot impact external customers
Backout plan is proven
No outage is planned
Typically applies to Mission Critical systems
Has been implemented previously without issue or issues resolved
Multiple departments or more than 10 users could be impacted
Could impact external customers but likelihood is low
Backout plan is proven
Outage is planned and communicated
Typically applies to Mission Critical systems
First time change has been performed or similar changes have previously resulted in issues
Entire organisation could be impacted
External customers could be adversely impacted
Backout plan is not proven
Outage is planned