What's the best practice/process for incidents caused by change

[bill_dev]

We have an incident raised because of a change that we did (upgrade to patch 14) where sla timer was not functioning correctly because the latest wf_activity_definition for SLA Timer was skipped.

We now know the solution and I'm trying to figure out the best way process wise to apply the fix(the fix is to import the latest SLA timer definition xml).

Of course I will use the "Caused by change" field.

Do I submit a new CR for the fix? Should I add a CTASK to the change that caused the incident and track the fix there? how about INCTASK?

[Brian Lancaster · Accepted solution]

My thought would be to create a new CR which a reference to the incident and the original CR (even if it is just in the notes).  However this sound like a question for your change manager in relation to how you have your change process setup.

[Uncle Rob]

New change.  
The action of change isn't dependent on the success or failure of previous changes. 
Almost all change in an organization is due to "something not meeting my expectation" which (should) always have been introduced by change anyway.

[jonathanyates]

Agreed with Rob, any change request is for a specific change. 

If I open a change to deploy new software, SNv2, and the deployment was successful, but then started to error for the user base I would still need a new change to rollback to a previous version as my change was to deploy SNv2 only.