Collision detection overview

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. Both factors, together, 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. The collision status is indicated by one of the following link colors:
• Black—No new collisions have been detected. Either no collisions exist, or all collisions are in the Ignored or Resolved state.

For more information about collision states and the Collision Detection dialog box, see Using Collision Detection.

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