How to assess the inherent risk in each change request, and necessary checks required to make sure that the risk is documented, prevented and/or mitigated?
One of the key factors is how many teams are involved in the change? As the number of teams increases, tasks assignment, collaboration, and communication becomes difficult.
Is there a service outage associated with the change and how long the services would be impacted or interrupted?
Longer the outage or disruption, more the risk.
To assess the risk associated with any/all the change requests, you can set some rules/guidelines for example:
Does this change need to be done during business hours?
Can this change be rolled back easily?
How many times have you performed this specific type of change in the last 6 months or 1 year?
Has all testing been completed successfully for this change on production?
Any resource availability delays / resource back up considered?
accordingly risk level can be documented within each change requests either as an attached document or as risk level flag (level 1, level 2 etc.)
How much effort & time it would take to reverse the change, how much outage we need and rarely change may be irreversible due to nature of it(Maximum risk)?
Learning from past changes and lessons learned, adjust the risk factor, based on the time taken and downtime.
There are various types of risk assessments, including program risk assessments, risk assessments to support analysis of alternatives, & assessments of operational uncertainty. In terms of Change, risk identification needs to match the type of assessment required to support risk-informed decision making. Initially identify the program goals and objectives, so fostering a common understanding across the team for better change management.
Example_Change Risk Questions and scoring:
Risk Yes No Yes value
Could violate an SLA agreement or cause a degradation of service X 2
Requires a client facing outage to implement X 5
Could trigger a security risk. X 7
Impacts a component other systems and services are dependent on X 5
Cannot be backed out X 7
Requires coordination across multiple teams to implement X 5
First time a change of this kind has been implemented X 3
Has been implemented in the past but with failures X 5
Impacts a key customer or multiple customers X 5
Cannot be implemented within maintenance window X 7
Cannot be tested prior to implementation X 10
Requires customer validation to complete X 5
Change Category Identification based on the risk rating:
Score Range Risk category Approvals Required
0 to 5 Minor change and requestor can submit as a candidate for standard change for future use Change Manager
CAB approval(done outside the approval workflow for this change) if the requestor wants to make this a standard change.
6 to 10 Minor Change Change Manager
11 to 20 Normal Change Change manager
Change advisory Board
21 or Higher Major change Change manager
Change advisory Board
One Of The Outcome, If risks materialize;)