Skip to content

Change Completion

Once a change is completed the change ticket should be tagged with Change Successful, Change Successful with Issues or Change Unsuccessful and the ticket closed in Zammad. The processes which need to be followed for each is described below.

If you are unsure of what state your change completed in contact the chair and/or deputy of the Change Management Board for advice.

Change Successful

A change is successful when the objectives of the change are achieved in the scheduled time and in full with only minor deviations from the original implementation and test plan.

To close a change as successful update the change request with details of the successful implementation. Include any deviations from the original implementation plan, lessons learned, and final results of testing. This documentation is valuable for future reference.

Once everything is confirmed to be functioning properly and the change has been monitored for a suitable period you can close the change request in Zammad. This signifies the completion of the change process and prevents further modifications under the same request.

If it later turns out the change was unsuccessful the change ticket must be updated to reflect the correct state and the process for an unsuccessful change must be followed.

Change Successful with Issues

A change is successful with issues if a change achieves the intended objective, but there is a significant deviation from the original schedule, implementation or test plan. There are many other reasons a change can be successful with issues. Here are some examples:

  • Significant deviation from the implementation or test plan.
  • The implementation overran the time scheduled by an small amount because it was best to continue to completion.
    • It is not acceptable for changes to regularly overrun. Changes should be scheduled with the expected time needed with the information available at the time of the change request creation with an acceptable margin for contingency.
  • Parts of the change could not be completed in the time scheduled and was stopped as a result. "Nice-to-have" or stretch objectives identified in the change request were not achieved as a result. All objectives of the work undertaken during the change were otherwise completed and successful.
  • Minor performance degradation is detected after the change, but not enough to trigger a rollback.
  • Suboptimal configurations needed to be applied in a minor deviation from the implementation plan.
  • Dependent systems are impacted in a way that was not anticipated, but the issues are not significant enough to trigger a rollback.
  • The objective of the change was achieved, but follow-up actions are needed due to issues discovered during the change that could not have been foreseen.
  • Any unexpected impacts or issues occur which are not sufficient to trigger a rollback.

If the change was successful with issues the change ticket must be updated with an explanation of why and what, if any, the next steps are.

If a follow up is needed (for example, a new change, a post implementation review, etc) the process for an unsuccessful change should be followed. If no follow up is needed the successful change process should be followed. If you are unsure contact chair and/or deputy of the Change Management Board for help.

Changes which do or could fall in to this category after implementation must be flagged to the chair and/or deputy of the Change Management Board.

Change Unsuccessful

A change is unsuccessful when the objectives of the change are not achieved or significant issues or impacts occur as a result of the change being conducted which was not expected or documented by the change request.

If the change was unsuccessful the change ticket must be updated with an explanation of why the change was not successful and what the next steps are.

In the change ticket document the reasons for the failure, including any errors encountered, unforeseen dependencies, or other factors that led to the unsuccessful change. This will help with troubleshooting and planning future changes.

Before attempting the change again investigate the underlying cause of the failure. The goal is to identify the exact reason for the failure so that it can be addressed before another attempt. Document the findings in the change request ticket and close it the ticket in Zammad.

If there is to be another attempt to make the change a new ticket must be created and the change management process followed again. Based on the findings of the root cause analysis, revise the implementation plan, test plan, and any other relevant sections of the change request. Also supply a link from this new change request to the previous one. This will help with evaluation of the change.

Changes which do or could fall in to this category after implementation must be flagged to the chair and/or deputy of the Change Management Board.