The ITIL Service Transition stage is the third stage of the ITIL lifecycle. It is in this stage where new or upgraded services are tested before going live. This is thoroughly covered in ITIL foundation certification training. After the ITIL Service Design stage, it is assumed that the service will work flawlessly in a test environment. However, this is not always the case. If the service implementation fails, it is necessary to go back to square one. But what if there is no protocol to go back to the way that things were when they still worked? Each service needs a back-out plan in case things go horribly wrong and this is called and ITIL remediation plan. An ITIL remediation plan is put into place in the Service Transition stage to ensure that services can be restored to their previous working conditions. This is discussed in more detail in ITIL courses and also in this article.
ITIL Remediation plan as part of service initiation
Plans are done, actions are taken, and changes are initiated, but what happens if the change is not completed successfully? No change should be approved without having explicitly addressed the question of what to do if it is not successful. And this should be done using an ITIL remediation plan. Because, if the change is not successful, previous working and operational states of the services must be re-ensured for the service delivery with the help of an ITIL remediation plan. Otherwise, there will be outage or service degradation which can cause dissatisfaction of the customer. ITIL Remediation plan comes into play when service changes do not pan out as expected. An ITIL Remediation plan for a change may be as simple as “Reverse each step.” No matter how you look at it, remediation plans are necessary for the successful implementation of new or upgraded services.
ITIL Remediation plan as part of risk management
Risk management is the process where all risks that may possibly apply to the roll-out of a new or improved service are considered. Contingency plans are put into place to deal with snags that may occur. However, sometimes the problems that arise when testing the service are so severe that there are no quick fixes. In this case, an ITIL remediation plan is implemented where steps are taken to reverse the change and return to service to its original state. Working with a plan during the Service Transition stage will ensure that no serious snags will be present when the service is rolled out into a live environment. So that customers won’t have to deal with an inferior service. In this way, this plan is part of risk management.
A remediation plan is a back-out plan
Ideally, for the remediation of failed changes, there will be a back-out plan or ITIL remediation plan which will restore the initial situation. This plan will include the steps and actions that should be followed to restore the initial situation before the change started to be implemented. In this way, even if the implementation of the change does not succeed, the implementation can be reversed by following the steps in the plan.
An ITIL remediation plan for a change may be as simple as “reverse each step that was taken so far” or there may be a series of complex instructions to be followed, including restoration of baselines. In rare circumstances, a change may be authorized without considering the plan (e.g. emergency or security changes). In these situations the change is critical and the IT Service Provider has to either ensure a successful IT change management or take steps to rectify the circumstances if the change fails.
Irreversible changes
However, not all changes are reversible. A remediation plan needs to account for this scenario. In this case, an alternative approach to remediation is required. For instance, the change might be an operating system upgrade of a server. If there is a possibility to not recover the server in case of a problem during upgrade, then an alternative approach from the ITIL remediation plan must be taken. For example, this approach can include copying data from old server to a new one. If there has been a problem during the operating system upgrade of the server, you can re-start from the beginning to install the new operating system again. Or revisiting the change itself can solve the problem and this can be part of the ITIL remediation plan. In fact, all such alternative remediations must form part of the ITIL remediation plan. In several cases, the business continuity plan must be invoked. The business continuity plan aims to ensure that the business services are delivered to the customers at the required and agreed service levels. Without this plan for service changes, this can not be 100% assured.
It plan must be 100% viable
Before initiating a change, remediation options in the remediation plan must be evaluated and ensured that these are viable before any change is initiated. Otherwise, if a change cannot be implemented successfully and if the ITIL remediation plans are not present or viable, services affected from the change will not be able to come back to operation. This will affect the customer satisfaction severely. This is why ITIL remediation plans are so important in the Service Transition stage.
ITIL Remediation plan in a testing environment
ITIL Remediation plans form part of the Service Transition stage of the ITIL service lifecycle. If the change proposal is not required or has been approved, the testing continues in a laboratory replicating the production environment. The testing should include procedures to install the proposed change, and an ITIL remediation plan to back out from the change in the event it cannot be successfully implemented, and to verify the success of the change after it has been implemented.
A complete back-out or ITIL remediation plan must be documented, including procedures to back out at various stages of the change for each change deemed risky enough to require it. The need for an ITIL remediation plan, from a process standpoint, is usually tied to the level of risk calculated for a given change. The ITIL remediation plan must also include a verification procedure to check that the environment has been restored to the initial configuration that existed prior to the change attempt and that there are no negative side effects resulting from the attempted change.
Review by: Taylor Elliott