Detecting collisions between change requests

A collision occurs when a CI is related to two or more change requests whose implementation schedules overlap. Change Management detects collisions between change requests automatically, and helps you to make decisions to manage and resolve the potentially harmful conflicts between these change requests. 

How collisions occur

Understanding how collisions occur helps you to avoid spending resources inefficiently, and to avoid creating instability in your IT infrastructure. Collisions are dependent upon a time (scheduling) factor and a CI factor and not on the status of the change request. Together, both factors play a role in determining whether a collision exists.

Time factor

The time factor of collisions is dependent upon the Scheduled Start Date and Scheduled End Date values in the Date/System tab of change requests. Collisions occur when there is a complete or a partial overlap of implementation schedules. If you consider two change requests, A and B, the following schedule-based collision scenarios are possible:

• Identical dates—Both change requests have the same scheduled start and end date values. It is unlikely that the CI will be available for two IT personnel to work on at the same time.
• Complete schedule overlap—Work on change request B is scheduled to begin after work on change request A, but will be completed before the work on change request A is completed. In this scenario, even though change request B requires a shorter implementation period, the CI will be unavailable to the assigned IT personnel because of the work being done for change request A.
• Start date and end date overlap—Work on change request B is scheduled to begin before work on change request A is completed. In this scenario, the IT personnel assigned to work on change request B will not be able to access the CI because work on change request A is still in progress.

CI factor

The CI factor determines the risk that the implementation of a change request might impede or undo the implementation of another change request. Depending on the type of effect that a change request has on a CI, the following CI relationship-based collision scenarios are possible:

• Direct effect—A CI is related to two or more change requests. All of the change requests affect the CI directly, and have overlapping schedules.
• Indirect effect—A CI that has dependencies is related to a single change request. This change request is likely to affect the dependent CIs indirectly. If one of the dependent CIs is related to a different change request with a conflicting schedule, a collision occurs between the two change requests.

How collision detection works

Collision detection works by automatically comparing CIs that are listed on the Relationships tab of change requests. CIs that are related to change requests from the Service field are also displayed on the Relationships tab, and are included in the comparison. Additionally, the Scheduled Start Date and Scheduled End Date values of change requests are compared to determine whether their implementation periods overlap.

• Red—At least one collision is in the Detected or Investigating state. Clicking this link opens the Collision Detection dialog box, where you can view the collisions that affect a particular change request. The Collision Detection link in the Functions menu of the Change form indicates the collision status of CIs related to the change request.
• Black—No new collisions have been detected. Either no collisions exist, or all collisions are in the Ignored or Resolved state.

You can also view a related video on BMC Communities at The Pulse - Collision Detection in Change and Release Management.

Collision status

The following statuses apply to collisions in the Collision Detection dialog box:

Understanding the Collision Detection dialog box

The following image shows the Collision Detection dialog box when accessed from a change request.

The Collision Detection dialog box is composed of the following sections:

1. The dialog box displays basic details about the current change request, such as the request ID, Scheduled Start Date, and Scheduled End Date. If you access the Collision Detection dialog box from a release request, only the change request ID or release request ID is displayed, depending upon which console you access the dialog box from. 
   Additionally, when you access the dialog box from a change request, you can perform a mouseover on the change request ID to view a a tooltip that displays the summary, location, customer information, and change coordinator information for that change request.

2. This area is followed by a table that lists all of the collisions that exist between the current change request and other change requests. If you access the dialog box from a release request, the table displays a list of collisions for all of the change requests that are included in the release manifest. The Filter By menu enables you to filter the collisions that are displayed in the table by their collision statuses. For more information, see Collision status.
   A tooltip is available in this section as well, which is displayed when you access the Collision Detection dialog box from either change requests or release requests. This tooltip is described in the table that follows.

3. The Refresh button updates the list of collisions. 
   The Preferences button enables you to add or remove columns displayed in the table. You use the check boxes to select multiple collision records simultaneously. The table also displays collisions that are caused by CIs that are owned by a different company than the one that you belong to.

   The following table provides the following details about the collisions in the current change request:

   Detail	Description
   Collision Status	The status of the collision between the current change and the colliding change. Important: Changing the status of a collision to Resolved does not actually resolve the collision. You must manually modify the scheduled start and end dates for one of the colliding changes to resolve the collision.
   Configuration Item	The name of the CI that is causing the collision.
   Change ID	The request ID of the change request in the release manifest that has a conflict. This column appears only when you access the Collision Detection dialog box from a release request. When you access the dialog box from a change request, the change request ID is displayed at the top of the dialog box.
   Scheduled Start and End Dates	The scheduled start and end dates of the current change. These columns appear only when you access the Collision Detection dialog box from a release request. When you access the dialog box from a change request, these details are displayed at the top of the dialog box.
   Conflicting Change ID	The request ID of the conflicting change request.
   Conflicting Scheduled Start and End Dates	The scheduled start and end dates of the conflicting change request.
   Check boxes	The relevant collisions that are selected. You can select multiple check boxes at the same time. Any actions that you perform in the Collision Detection dialog box will affect all of the selected collisions.
   Tooltip	If you access the Collision Detection dialog box from a change request, a tooltip appears when you perform a mouseover on the conflicting change request ID column of the table. However, if you access the dialog box from a release request, the tooltip appears when you perform a mouseover either on the request ID of a change request, or on the request ID of the conflicting change request. The tooltip displays the summary, location, customer information, and the change coordinator information for the change request that the cursor points to. Important: You must select the collision in the table before performing a mouseover.

   Best practice

   BMC recommends that you run an impact simulation in BMC Atrium Impact Simulator to detect CI dependencies before you use the Collision Detection feature in BMC Helix ITSM: Change Management. Saving the simulation automatically relates all dependent CIs to your change request, which ensures that any collisions are detected. For more information, see Relating and managing configuration items and impacted services for a change request.

4. The Update Collision Status and Business Justification that follows the table of collisions enable you to change the status of the selected collision. You can also enter a business justification for the status change.

5. The collapsible Collision Status Audit Trail panel at the bottom of the dialog box enables you to view the history of status changes for the selected collision. It provides the following information:

   • Date and time of the status change
   • ID of the user who updated the status
   • New status of the collision
   • Reason for the status change

To change the status of a collision

1. Open the change request by starting from a release request record, clicking the Manifest tab, and opening the related change request that you are working on.
2. Select Functions > Collision Detection.
3. In the Collision Detection dialog box, select one or more collisions that you want to update.
4. In the Update Collision Status and Business Justification panel, select the new status in the Collision Status field.

5. Type the reason for the status change in the Business Justification field.

   Important

   A Business Justification value is mandatory whenever you update the status of a collision to either Ignored, or Resolved.

6. Click Update to apply the new status to the selected collisions and save the business justification that you entered.

To view the audit trail of collision status changes

You can use the Collisions Status Audit Trail panel of the Collision Detection dialog box to view the history of status changes for a collision with a particular change request. It provides the date and time of the status change, the ID of the user who updated the status, and the new status of the collision.

To use the chat feature with collision detection

When a collision is detected, you might need to consult the change coordinator and change manager of the colliding change request through chat before taking any action.

1. Open the change request by starting from a release request record, clicking the Manifest tab, and opening the related change request that you are working on.
2. Select Functions > Collision Detection.
3. In the Collision Detection dialog box, select the collision that you want to discuss. 
4. Click the Chat icon at the top right corner of the Collision Detection dialog box to open the Start Conversation dialog box.
   The change coordinator and change manager of the the colliding change request are visible in the Context Users list in the dialog box.
5. To start the chat conversation, double-click the user with whom you want to discuss the collision.
   You can invite more users to the conversation later.

When you end a chat conversation, the conversation is log is saved on the Work Details tab of the current change request of the colliding change request.