Incidents caused by Change

[HasarinFareeth]

Hi - I wanted to report incident caused by a change against the number of changes implemented in the reporting period. I have a scenario where a change can be closed at the end of a current month but an incident caused by that change can be reported next month, so ideally this change causing the incident might come as successful if a report is extracted for the incident caused by changes with current month. How can I overcome this?

Thanks

Fareeth

[palanikumar]

Hi @HasarinFareeth ,

This can be handled only by process. In general, calculation of successful change will always have this conflict.

You can try this:

1) Once Change is implemented, keep the Change in review state for Post Implementation Support Period (2 weeks or more based on your environment)

2) Allow incident to be created only if it is in Review state

3) You can write a Scheduled Job to change the status automatically during this period.

The above process will ensure you are not reporting wrong status

[Dr Atul G- LNG]

Hi @HasarinFareeth 

I have a scenario where a change can be closed at the end of a current month but an incident caused by that change can be reported next month, so ideally this change causing the incident might come as successful if a report is extracted for the incident caused by changes with current month. How can I overcome this?

Atul:

Technically, there isn't a direct way to build this report. The reason is that an incident might be created as soon as a change is deployed, but the Service Desk agent might not link it immediately. In such cases, even if the incident is linked to the change later, it would still be logged in the current month only.

This is more of a process decision. You could keep the 'review window' of a change open for a longer duration — say, 2 to 3 weeks — depending on the type and nature of the change. If any incidents are logged after that window, they wouldn't be allowed to link back to the change. But again, this approach isn't always practical in the real world.

In one of my previous projects, we kept the review field open for up to 6 months. That way, if any incident was logged within that timeframe and investigation revealed it was caused by a change, it could still be linked.

In summary, this is more of a process-driven decision, my friend