become-itil-foundation-certified-abhinav-kaiser(www.ebook-dl.com)
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chapter 6 ■ Service Transition<br />
6.4.1.5 Change Remediation<br />
There is no assurance that all changes that go in will <strong>com</strong>e out undaunted and successful<br />
as planned. You need an alternate plan if the change were to fail. The actions taken to<br />
nullify the change (back out or rollback) or to invoke service continuity plans are called<br />
change remediation. It is an important part of the change plan to ensure that the IT<br />
services do not affect the customer.<br />
When any change proposal <strong>com</strong>es in, it is imperative that the change plan consist<br />
of a section to detail the back-out procedures. Not all changes can be backed out. For<br />
example, reloading of an operating system after disk format is not reversible. In such<br />
cases, an alternate plan must be in place to ensure that the IT service that is being<br />
changed does not affect the business services it supports. In extreme cases, when changes<br />
fail, IT service continuity plans are invoked. Say, for example, a live database is being<br />
altered and the change breaks down, taking down the entire customer’s business. In such<br />
cases, IT service continuity plans will power the business continuity plans to ensure that<br />
businesses <strong>com</strong>e back to life at the earliest possible time.<br />
All changes are inherently risky. The spectrum of risk depends on the particular<br />
change. Risks can be identified accurately when change remediation plans are spelled<br />
out. Say, for a particular change, change remediation is to invoke service continuity plans.<br />
This is a high-risk change and needs to be han<strong>dl</strong>ed with the utmost care. In effect, all<br />
changes must include change remediation plans to ensure that risks are identified fully<br />
and <strong>com</strong>pletely. Only when the risks are identified can appropriate decisions and actions<br />
be taken to mitigate the risks.<br />
A change window is the timeframe between the start of the change and when the<br />
change is to be <strong>com</strong>plete—implemented and verified. The back-out plans must be in<br />
line with the change window and ensure that the plan to back out a change is during the<br />
change window and not outside it.<br />
A typical change plan consists of an implementation plan with various phases,<br />
triggers, and milestones. At every milestone, the plan spells out what is expected. If the<br />
expected output is not as per the plan, then a remediation plan is also drafted in line with<br />
it. So it <strong>be<strong>com</strong>e</strong>s transparent for change implementers and change managers to expect<br />
as planned or to rollback if things don’t go as intended. This way, there is no space for<br />
ambiguity or speculation.<br />
6.4.1.6 Change Advisory Board<br />
The change advisory board (CAB) exists to support the change management team and to<br />
make decisions on approving or rejecting changes. To state it simply, it can be described<br />
as an extension of the change management role, and it exists to ensure that the proposed<br />
changes are nondisruptive, scheduled to minimize conflicts, prioritized based on risk and<br />
impact, and analyzed for every possible out<strong>com</strong>e to the hilt.<br />
In an organization, you can have multiple CABs to support change management. A<br />
typical example would be a change being represented in an infrastructure CAB before<br />
it goes into the enterprise CAB, and perhaps followed by a global CAB. The essence of<br />
having a CAB is important, not the way it gets implemented.<br />
124
Change language