• Emergency: Reserved only for highly critical changes that must be introduced

as soon as possible (e.g. changes needed to restore failed high-availability ser- vices or widespread service failure, or changes that will prevent such a failure from imminently occurring). The change management process normally has a specific procedure for handling emergency changes.

The change authority is the person or persons who will authorise specific changes to take place. Organisations can decide who will be responsible for authorising different types of change and, in the interests of operational efficiency, will often devolve this authority to the change management team or operational staff. It is vital that the designated change authority has the appropriate knowledge and skills to be able to make such decisions. Modern tools will allow electronic approv- als, with definable defaults that ensure changes are progressed in a timely manner.

The change advisory board (CAB) is a group of people that advises the change manager in the assessment, prioritisation and scheduling of changes. The CAB is made up of representatives from all relevant areas within the IT service pro- vider, the business and third parties. The key factor is that all parties who have

a view on a particular change should be represented. Membership of the CAB is therefore likely to be dynamic, even within a single meeting.

Meetings may involve face-to-face contact or be conducted by telephone or online. Depending on choices made within the organisation, meetings may be held at different times and intervals as demand dictates. CAB members assess both business and technical perspectives of proposed changes.

For emergency changes there may not be time to convene the full CAB, so it is necessary to identify a smaller group with authority to make emergency decisions (i.e. an emergency change advisory board (ECAB)).

Change procedures should specify how the composition of the CAB and ECAB will

be determined in each instance. No change should be approved without there being a remediation plan (i.e. what

to do if the change is unsuccessful). Where possible, a back-out plan should be provided to recover the organisation to its original, or another, known state should the change fail. This might involve reloading a baselined set of configuration items, revisiting the change itself or, if the failure is severe, invoking the organisation’s business continuity plan. It should be recognised that not all changes can be backed out, so the remediation plan must cover what to do in such situations. Only by considering the remediation options available prior to instigating a change and establishing that the remediation is viable, can the risk of the proposed change be determined and the appropriate decisions taken.

The change schedule lists all approved changes and planned implementation dates. It becomes an important audit trail to support incident/problem management among other processes.

A change model is a repeatable way of dealing with a particular type of change. It sets out specific defined steps that are followed for a specific type of change. Standard and emergency changes are typical examples that might be handled

CHANGE MANAGEMENT

this way. Support tools can be used to automate the handling, management, reporting and escalation of the process. The change model includes:

• steps to handle the change including handling issues and unexpected events; • the chronological order to take the steps, with any dependences or co-processing

defined; • responsibilities (who should do what);

• timescales and thresholds for completion of the actions; • escalation procedures (who should be contacted and when).

• Emergency: Reserved only for highly critical changes that must be introduced