Change Closure Codes Definitions

[Nickels]

The change manager at my company is looking for definitions that we can document for our change management process for the change closure codes. We've been looking and haven't found anything yet. Does anyone have a good resource of where I may be able to find some definitions that we can review? 

Appreciate the help!

-Chris

[Nitinsh_2411]

Hi Allen,

Thank you for the definitions and if possible, Please share for "Successful with Additional Time" also.

[merrymee]

Change Closure Codes

Change Closure Codes denote or indicate the outcome of a change workflow, providing us with the reason for closing a change request, whether the Change was completed successfully or not. This field is manually updated when updating status activity on a change workflow.

These 3 OOB closure codes provided by ServiceNow for Changes can be modified and enhanced according to company needs.

1. Successful

2. Successful with Issues

3. Unsuccessful

Change Closure Codes Definitions:

• Successful

Indicates that the Change was installed or implemented successfully, accomplishing its intended objectives, and did not cause any incidents or issues at any tier level.

• Successful with Issues

Indicates the Change was installed or implemented successfully; largely accomplished its intended objectives but went off-plan, which directly or indirectly caused one or more issues. For Example, this Change went past the Planned End Date in some way due to an error encountered during implementation, causing additional troubleshooting or a fix forward applied to resolve the issue. Furthermore, this Change may also require additional CTasks with team engagement to allow for more testing or request for more additional documentation needed in the implementation plan, or Additional Manager's Approval was requested, etc.

• Unsuccessful

Indicates the Change was unsuccessful and did not meet its intended objectives due to one of the following reasons:

Backed Out: The Change was unsuccessful and did not accomplish its intended objectives, causing significant issues and causing the implementation team to back out the Change. When a Change is back out, a new Change Request must be created if the backed-out Change needs to be rescheduled. 

Incomplete.

Caused Impact/Incident: The Change was deployed but resulted in an incident that significantly impacted the business, usually following P1/P2 incidents.

Incomplete: Change closed without confirmed solution. Nothing was remediated with this Change. The Change was marked as incomplete due to one or multiple factors (E.g., some of the Change codes were implemented but missing some dependencies).

Some companies add the close code: Canceled to their Change close code. But this is also usually part of the change workflow. So it will be duplicative to add this to the closure code.

Mercy Ikhuoria Nwankwo

ITSM Process Management

[Katie Fent]

This is how we have defined the OOTB close codes - 

Successful - Change was fully implemented with no incidents or issues resulted

Successful with Issues - Change was implemented but incidents or issues occurred and was not backed out 

Unsuccessful - Change was implemented but incidents or issues occurred and was backed out 

[EricJ3841883040]

I find that exact codes vary by organization, however they all should follow ITIL principles.  I find the default ones can be a bit ambiguous and can be confusing "Successful with Issues".  Is it a success or did it create issues?

For our organization we use:

Successful - Implies the change was implemented and followed the documented plan with no deviation

Implemented with Comments - The change was implemented but did not follow the plan.  NO Incidents were created.  This closure code will force closure comments to indicate what deviated from plan.

Implemented with Incidents - If the change caused an incident, then we were unsuccessful.  In essence this is the Unsuccessful (failed) change.  It will be followed up with a After Action Report (AAR) or Post Implementation Review (PIR).

Backed Out - There was a plan that was tested but when deployed it did not meet the expected results.  It was backed out with NO Incidents.  Production environment is fully intact as it was before the implementation attempt.   This to me shows maturity as your team realizes it didn't get the results desired and rolls back the change.