Resubmit of failed changes

[rebeat0914]

This question has sparked heated debate in our office. A change requester submits an RFC, let's call it Change A. Change A requires that several other changes have already been completed successfully, lets say Change B, Change C and Change D. Say Change A fails and is backed out and investigation finds the failure cause to be that Change D actually was not completed correctly. The person responsible for Change D makes the corrections and Change A can be attempted again. The question is: who is responsible for submitting a new RFC for Change A. The team making the original RFC says the person (or group) that was responsible for the failure should submit a new RFC for Change A, in my example that would be the Change D person. Others believe the original submitter should submit the new RFC for Change A regardless of what the reason for failure of earlier attempts is.

[dsemeniuk]

I believe Owner of Change A and Owner of Change D both need to resubmit their RFCs for implementation as they both were failed changes.

The PIR on Change D would state the failure and why. So a new RFC will have to resubmitted (linked to original RFC) stating the new "plan" and why to do Change D again.

Change A will be marked as failure, documenting dependancy on Change D, and resubmitted even though it could be the same implementation plan, its just noted that Change D needs to be in place.

The Person who submitted Change A is the original requestor wanting this change, why would Change D requestor request Change A if they never wanted it in the first place?

My 2 cents.

[Guerino1]

Hello Rebeat0914,

Why would you "close" the failed changes? Another option is to simple reject them, until corrective action is taken, and then promote them forward again, using the same RFCs. Doing it this way ensure that you have a complete audit trail of the work associated with a specific failed Change. If you create a new RFC, then you have the same related work thread spread over multiple RFCs. Many enterprises we deal with won't close failed Changes. They'll simply reject them backwards, until work is done to correct the issues, the re-promote them forward.

I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL