This documentation supports the 18.08 version of Change Management.

To view the latest version, select the version from the Product version menu.

Configuring risk assessment

Risk assessment involves computing the total risk of making a change based on risk-related questions and the derived risk. The derived risk can be based on historical performance and the impact or priority of a change or CI. The higher the risk on a change request, the more time you should take to consider the impact of the purposed change and whether to proceed.

The following table displays the numeric values for each risk level:

Risk assessment

Aggregate risk value

Risk level

1

Minimal (lowest risk)

2

Low

3

Medium

4

High

5

Extreme (highest risk)

Risk factor 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 accordingly.

You can create different sets of questions for different companies. With the Remedy IT Service Management Virtualization Lifecycle Management extension, you can now also create different sets of questions for different operational categorizations. When the change coordinator or virtualization administrator creates a change request, the questions for the applicable company and operational categorization are displayed. If no questions are defined for the company and operational categorization of the change request, the global questions are displayed.

Example

You might create one set of risk factor questions for provisioning a virtual machine (VM) and another set of risk factor questions for removing a VM. The following table illustrates the two operational categorizations for which you might create the two sets of risk factor questions:

Tier

Operational categorization 1

Operational categorization 2

1

Request

Request

2

Virtual Machine

Virtual Machine

3

Provision

Remove

If you select all three levels of categorization, you can create different questions for provisioning and removing a VM. If you select the first two levels of categorization, you can create a set of risk factor questions for all VM requests, regardless of whether they are for provisioning, removing, or changing a VM.

You can choose how to word your questions and responses. A good example of a risk question is, "Will this change impact more than 100 people?" The answer can be Yes or No. You might specify Yes as a risk value of 5, and then specify No as a risk value or 1. You could specify Yes and No to have other risk values, such as 4 and 2.

You could ask this same question in another way: "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).

Both of these questions provide similar information. It is up to the application administrator to understand how important the specific details are. Yes or No questions are quicker to answer, but they limit the choices.

These questions then appear in the Risk Assessment Questions dialog box that the change coordinator accesses by clicking the Risk Info button (beside the Risk Level field) on the Infrastructure Change form.

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

Derived risk factors

Derived risks factors are based on historical performance data, the impact or priority of the change request, and the impact or priority of the attached CI. When a change is completed, the change manager or coordinator must enter a performance rating, as listed in the following table. This performance rating is a combined consideration of all derived factors on a change.

Important

When working in Best Practice View, the change coordinator or change manager does not enter the performance rating. There is a predefined configured default value that is automatically applied.

Performance ratings

Performance rating

Performance rating level

1

Lowest (worst rating)

2

Low

3

Medium

4

High

5

Highest (best rating)

Performance ratings are recorded for each change request. The historical ratings are used 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.

Important

Performance ratings for changes are not rolled into the average performance until the change is closed. A completed change does not yet have the performance rating averaged into the overall rating.

When a change is completed, the change manager or change coordinator must enter a performance rating to close the request. This performance rating is used for computational purposes, based on all derived factors related to the change. Derived risk factors are based on the historical performance of different aspects of a change. For all configured derived risks, a cumulative performance rating is stored for that aspect of the change.

For example, one derived risk aspect that can be configured allows for tracking of the performance of the change manager. When a change is completed, a performance rating is recorded. 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 change manager.

Example

Mary Mann, a change manager, has been involved in only one change as the change manager, so the number of ratings is set to 1. She had a low performance rating on the change in which she was involved, and the performance rating is set to 1. This means that Mary is considered a high risk on the next change where she is the change manager. For the next change in which Mary is involved, she performed better and received a medium rating (3). The average rating for Mary is now 2 (total performance ratings / number of ratings). The more changes that she manages, the better overall performance the system will have when calculating risk.

You can create a collection of risk factors that are derived from pre-existing data in the Change Management application, such as the priority of related configuration items (CIs), the performance rating of a manager or support group, the CI priority and impact, or the change priority and impact. The risk values for the derived factors are recorded and associated with the change request.

This derived factor is calculated in the Performance Rating field on the Classification tab that rates the work done when the change request is completed.

Important

Risk and Performance have an inverse relationship. A high performance rating leads to a lower risk, and a low performance rating means a higher risk, as shown in the following table.

Performance ratings and aggregate risk values

Performance rating

Aggregate risk value

1 (Low)

5

2

4

3

3

4

2

5 (High)

1

For additional information, you can view the BMC Communities blog post on Risk assessment in BMC Change Management.

Was this page helpful? Yes No Submitting... Thank you

Comments