Share This:

Introduction:

This article presents one of the key concepts of Change Management – Risk Management. The process described below has been simplified to suit the reality of most IT organizations following the process. Assessing the risk of change is a key step in making the change process focused, harnessed and controlled.  If the risk is properly assessed, it can be managed, evaluated and approved, leading to more successful results.  A good rule to follow is: “Never approve a change request that does not explicitly plan for the possibility of failure.”

BMC Remedy Change Management has several features to help assess risk. This post will describe those features, how they work, and how to use them effectively.

Before we look at risk assessment features, let’s consider the case of a change management process which does not include any
risk assessment features.  A basic feature of Change Management is the ability to define categories of changes, and to designate which changes require approval. Approval may be required for different reasons – to approve budget, to notify affected groups, or to approve the change to the infrastructure. In the latter case, the manager may receive the approval request and have very little information required to make the decision whether to approve or not. The change request has two attributes – Risk Level and Impact – which indicate the risk.  How can the change process collect more granular information, and establish a consistent way of assigning the risk of a change?


This is the motivation for the Risk Assessment questions as they provide a way of collecting answers to standard questions in the change
evaluation process, and assigning a risk level and impact based on the value provided. There are no out of box or standard risk assessment questions because the answers depend on the company size and prioritization.  For example, a common risk assessment question is:
"How many users will be impacted by this change?"

For large companies, a change which impacts 25 users may be considered a medium impact.  For small organizations, it may be considered a large impact.

Below are some common risk assessment questions used by different organizations:

  1. How many users will be impacted by this change?
  2. Does this change need to be done during business hours?
  3. Can this change be rolled back easily?  

 


Next, let’s work through an example of risk assessment questions, and how they work.


Risk assessment questions can provide a lot of consistency in assigning risk to proposed changes, but there are some limitations. First, questions which may be relevant for some changes are not relevant for others. Second, the assignment of risk or impact is subjective – it is forward looking assessment with incomplete information of future events.  It is common to underestimate risk by failing to account for execution failures, conflicts or unforeseen factors.  So the next feature we want to discuss in this post is Derived Risk. 

This feature provides a feedback mechanism to track the risk of future changes, by tracking how well past changes were performed. Derived risk provides an objective, quantitative way to assign risk based on similar changes in the past. The more data history it has on similar changes, the better it will project the risk of future changes.

Here are some additional factors to consider getting the most out of derived risk:
  1. Implement risk assessment questions first. This provides a first step of assessing risk across all changes.
  2. Ensure all changes update the Performance Rating as they are closed. This is the right time to evaluate how smoothly the change was performed. It also is a good step to reinforce the process of focusing on lesson-learned.
  3. Periodically query for changes with poor performance values to understand how risk was under estimated, and how to account for it in future change requests.
  4. Add new risk assessment questions if appropriate, based on common causes of poor performance.
  5. Encourage a culture of continuous improvement, where new questions and unforeseen failures are addressed both in procedures, and in assessing risk.

The Change form includes the following fields for risk management:

  1. Risk Level: Enter the anticipated risk that this proposed change has from 5 (highest risk) to 1 (lowest risk).
  2. Impact: Determine the impact of this change based on the number of affected users.
  3. Performance Rating: When using the Classic view, in the Classification tab, rate the work done by support staff or the manager in completing the change request. Usually, the manager of the support staff assigned to the change request enters this rating after the change request is closed. This field is not displayed in the Best Practice view.

Risk assessment involves computing the total risk of making a change based on risk related questions and the derived risk.



Risk Related Questions:

As an application administrator, you can create risk factors based on weighted answers to multiple-choice questions. Each question can carry its own risk weight, and each answer can carry its own risk value. The change coordinator's answers to these questions enable you to compute a more detailed risk value based on a set of specific circumstances rather than simply choosing one of the predefined risk levels.
Change managers and virtualization administrators use the risk value to determine how much the change request impacts their company. Armed with this information, they can plan and schedule their changes and devise fall-back plans accordingly.



The change coordinator's responses are recorded and associated with the change entry in the "CHG:ChangeRiskFactors" form. This back-end form is for reference only, and it not intended to be viewed by the users or administrator.




Steps to configure Risk Questions:

  1. Go to Application Administration Console -> Change Management -> Risk Factors -> Change Risk Selection
  2. Select the Company and then go to the Questions Tab.
  3. Numeric Values for each Risk Level.




Risk.JPG.jpg

  4. A good example of risk question is, "How many people will this change affect?"

 

The answers could then be 1-25 (risk 1), 26-50 (risk 2), 51-75 (risk 3), 76-100 (risk 4), and more than 100 (risk 5).
Risk Factor Template.jpg
   5. Go to Change Management and when submitting a new CRQ, Click the Risk Level icon Risk Button.jpg
        so you can answer questions configured as per your requirement.

 

CRQ Approval.jpg
  6. The important note here is when you select the answer based on your question above the Risk Level* field will not reflect the level unless you save the Change Request. The Change Request in the above example will show the Risk Level* = 5
Risk Level.jpg
Approvals based on Risk Level:

  1. Go to Application Administration Console --> Foundation --> Advanced Option --> Approval Process Configuration
  2. If you have configured the approval process for your Company then the same needs to be verified if they are enabled, for example you have OOB default Global.
  3. Go to Application Administration Console --> Change Management --> Approval --> Approval Mappings
  4. You can configure the approvals that will be generated based on the Approve if Risk <= (Risk Level 1,2,3,4,5)
AP Mappings.jpg
   5. The Approve if Risk and Notify if Risk fields work in conjunction with each other. You can use the Notify if Risk < field to set up notification-only approvals based on risk level. These are courtesy notifications that do not require the recipien to perform any action.

Risk Level Approval.JPG.jpg
  6. Now based on the above scenario where the Risk Question being selected as (Risk Level 1,2,3,4,5), example Level 5 the approval will not be generated.

 

 

   7. Important Note here is Approval mapping records are specifically for the Change Level processes. The Change Ad Hoc
       process does not use the Approver Lookup record, nor does the Change Management Chain process.

Derived risk factors:

Performance Ratings.JPG.jpgDerived risks factors are based on the historical performance of changes. When a change is completed a performance value for the change is entered. This performance value is a combined consideration of all derived factors on a change. The person entering the performance rating needs to consider all aspects of the changes performance. This includes looking at how the change manager performed, how well things went with this operational CTI, and any other derived risk factors that are configured. The performance rating stored on the change is then used, in combination with previous historical ratings, to compute an overall performance for each of the derived risk factors. The performance history
becomes more meaningful as more changes are accomplished. The performance rating becomes an average of the performance of the assigned manager or the chosen operational categorization. This in turn helps a more accurate risk
assessment to be performed on new changes.


One of the derived risk aspects that can be configured allows for tracking of the performance of the change manager. When a change is completed a performance rating will be entered. This rating is stored on the change and when the change closes, the status becomes ‘closed’, the performance rating is then averaged into the existing performance rating for the CAB Manager. The lower the performance, the higher the risk.

  1. In the Derived Risk Factors Template for the Risk Factor Type option Derived Rating there are 5 choices available in the Field Name list (Change Coordinator, Change Implementer, Change Manager, Operational CTI, Support Group Name) and for Risk Factor Type option Derived there is 1 choice available (CI Priority).
  2. On the Infrastructure Change form, the View Risk Report navigation item will be hidden on New and Search windows
  3. Risk Level 1 is the low value and Risk Level 5 the high value, to use the computed value of risk set the Risk Level field to  
    NULL and save the change record.
  4. Risk Weight contains % values of (20/40/60/80/100).
  5. The formula for computing risk is as follows: if RF1, RF2 and RF3 are the risk levels of three risk factors associated with the change, and if w1, w2 and w3 are the respective weightings for the risk levels, total risk (Risk Level) is computed using the following formula:

          RF1*w1 + RF2*w2 + RF3*w3

           ------------------------------------------------
           w1 + w2 + w3
  6. This version of the formula is used rather than just taking the % weightings alone since the sum of the weights is not required to be 100. This formula ensures that each risk factor contributes the specified fraction (weight) to the overall Risk Level.

    Note that if only a single risk factor is associated with the change, its effective weighting is 100% regardless of its actual specified weight.
  7. High performance rating corresponds to a low risk value and vice versa. In other words, if a Change Manager had a performance rating of 5 (highest) and weighted at 100%, the Risk Level corresponding to this rating is Risk Level 1 (lowest risk).
  8. The performance rating given to a change request is used for computations starting only when the next change request is submitted. The performance rating given to a change request does not affect its own Risk Level.
  9. Certain updates to child records will be rolled back if closing without saving. In Risk Determine, if child template entries are created (via Add) or deleted (via Delete), closing the Risk Determine entry without saving will restore the entry to its prior state. Any modifications made to child entries opened via the View button will not be rolled back. This includes setting the status of a child entry to "Delete", which will cause it to be immediately deleted.
  10. A similar mechanism has been implemented for Risk Factors Template and Answer Choices (risk menu items). Additions and Deletions can be rolled back.

Approval Risk based on the CI:

  1. Create a CI, example: Impact: 1-Extensive/Widespread, Priority: 5, Service Type: Business Service

CI.jpg
  2. Create a Review Individual approval mappings having Advanced Criteria tab with “Notify if Risk < (Risk Level 4)” and “Approve if Risk <= (Risk Level 3)”
   3. Go to the from Risk Factor Configuration à Derived Factors tab à Derived Risk Factor Template
   4. Select Risk Factor Type = Risk Object, Risk Weight = 100%, Field Name = CI Impact

 

Derived Risk.jpg
  5. When you create a new CRQ with the CI created above the Risk Level* = 5 once you save the CRQ. 
  6. Move the CRQ to next stage the approval gets generated for the Review phase as per the approval mappings mentioned
       above.
CRQ.jpg
Risk Report:

Risk Report, which can provide a key decision making tool in change planning. The Change Risk Report dialog box displays the summary, which includes the questions and responses, and the derived factors if applicable. The derived factors section includes the change impact, change priority, CI impact, and CI priority. Each change has a risk value computed for it as the information on the change is modified. Specifically when you first save the change a risk is computed based on the derived factors. Then when you answer, or change the answer to risk questions, and then save the change, the risk is computed again.

  1. The CI as mentioned above associates with the CRQ in the Service+ field.
  2. Select a Risk Level from the questions from the Risk Level icon   Risk Button.png
  3. Submit the Change Request.
  4. So based on the Questions and Derived Factor the Risk Value gets created.

Risk Assessment.jpg
   5 . Additionally, you can find a derived factor example on below link from BMC Support website

 

    6. When using the Best Practice view: Choose Links a View Risk Report in the left frameof the Change form.
         When using the Classic view: Choose Advanced a View Risk Report in the left frame of the Change form.

 

     7. As per the current design model this is not Mandatory, to have the Risk Assessment in Change Management.

 

I hope that you find this useful as an example on how to use features of BMC Remedy Change Management for assessing risk of changes. I welcome your comments, feedback, and suggestions that you may have regarding this blog post.

 

Recent Ideas:

Add a 'Risk Factor Test Tool' to Application Administration for Change

 

https://communities.bmc.com/ideas/3548

You can find more content like this about BMC Remedy products on the BMC Remedy Pulse Blogs page.