This documentation supports the 20.02 version of Remedy Change Management.

To view an earlier version, select the version from the Product version menu.

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 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. 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.

Example

Consider a server that hosts a number of virtual machines. User A submits a change request for an operating system upgrade on one of the virtual machines. The request is scheduled to be implemented between 4:00 P.M. and 5:00 P.M. on Tuesday, the following week. The next day, User B submits a change request to add another hard disk to the server. This request is also scheduled to be implemented on Tuesday of the following week, but between 3:00 P.M. and 6:00 P.M.

A collision now exists, because of the complete schedule overlap, and because the change request for the server hardware upgrade indirectly affects the virtual machines that it hosts. A change in schedule is necessary to implement both change requests efficiently.

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.

Best practice

We recommend that you run an impact simulation in Atrium Impact Simulator to detect CI dependencies before you use Collision Detection. Saving the simulation automatically relates all dependent CIs to your change request, which ensures that any collisions are detected. For more information, see Viewing the impact of CIs on change requests.

  • RedAt 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.

Important

The following differences exist in the way that Collision Detection works in release requests:

  • Collision Detection is run against the changes in the release manifest, not the changes that are related to the release on the Relationships tab. Collision Detection does not apply to release activities in the release manifest.
  • The Collision Detection link does not turn red when a collision is detected.
  • You fix collisions on the Manifest tab of the release form.

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

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

Comments