Emergency changes are sometimes required and should be designed carefully and tested as much as possible before use, or the impact of the emergency change may be greater than the original incident. Details of emergency changes may be documented retrospectively.
The number of emergency changes proposed should be kept to an absolute minimum, because they are generally more disruptive and prone to failure. All changes likely to be required should, in general, be foreseen and planned, bearing in mind the availability of resources to build and test the changes. Nevertheless, occasions will occur when emergency changes are essential and so procedures should be devised to deal with them quickly, without sacrificing normal management controls.
The emergency change procedure is reserved for changes intended to repair an error in an IT service that is negatively impacting the business to a high degree. Changes intended to introduce immediately required business improvements are handled as normal changes, assessed as having the highest urgency. If a change is needed urgently (because of poor planning or sudden changes in business requirements) this should be treated as a normal change but given the highest priority.
Service transition processes |
83
Emergency change authorization
Defined authorization levels will exist for an emergency change, and the levels of delegated authority must be clearly documented and understood. In an emergency situation it may not be possible to convene a full CAB meeting. Where CAB authorization is required, this will be provided by the emergency CAB (ECAB).
Not all emergency changes will require the ECAB involvement; many may be predictable both in occurrence and resolution and well-understood changes available with authority delegated, e.g.
to service operation functions who will action, document and report on the emergency change.
For example, repair or replacement of server hardware may require a small change in the server revision or configuration that can be authorized by operational staff.
It is important that any decision to authorize an emergency change is documented to ensure that formal agreement from appropriate management has been received, and to provide proper records for audits of the process.
Emergency change building, testing and implementation
Authorized changes are allocated to the relevant technical group for building. Where timescales demand it, change management, in collaboration with the appropriate technical manager, ensures that sufficient staff and resources (e.g. machine time) are available to do this work. Procedures and agreements – approved and supported by management – must be in place to allow for this.
Remediation must also be addressed.
The emergency change should be tested as fully as possible. Completely untested changes should not be implemented if this is at all avoidable. If a change goes wrong, the cost is usually greater than that of adequate testing. Consideration should be given to how much it would cost to test all changes fully against the cost of the change failing, factored by the anticipated likelihood of its failure.
This means that the less a change is considered likely to fail, the more reasonable it may be to reduce the degree of testing in an emergency.
(Remember that there is still merit in testing even after a change has gone live.) When only limited testing is possible – and presuming that parallel
development of more robust versions continues alongside the emergency change – then testing should be targeted towards:
■ Aspects of the service that will be used
immediately (e.g. daily entry features, not end-of-month routines)
■ Elements that would cause most short-term inconvenience.
The business should be made aware of associated risks and be responsible for ultimately accepting or rejecting the change based on the information presented.
Change management will give as much advance warning as possible to the service desk and other stakeholders, and arrange for adequate technical presence to be available, to support service operation.
If a change, once implemented, fails to rectify the urgent outstanding error, there may need to be iterative attempts at fixes. Change management should take responsibility at this point to ensure that business needs remain the primary concern and that each iteration is controlled in the manner described in this section. Change management should ensure that ineffective changes are swiftly backed out.
If too many attempts at an emergency change are ineffective, the following questions should be asked:
■ Has the error been correctly identified, analysed and diagnosed?
■ Has the proposed resolution been adequately tested?
■ Has the solution been correctly implemented?
In such circumstances, it may be better to provide a partial service – with some user facilities withdrawn – in order to allow the change to be thoroughly tested, or perhaps to suspend the service temporarily and then implement the change.
Emergency change documentation
It may not be possible to update all change records at the time that urgent actions are being completed (e.g. during overnight or weekend working). It is, however, essential that temporary records are made during such periods, and that all records are completed retrospectively, at
84
| Service transition processesthe earliest possible opportunity. An agreed time for completion of these updates should be documented when the change is authorized.
IT operations management, technical management and application management staff may have delegated authority to circumvent certain types of incident (e.g. hardware failure) without prior authorization by change management. Such circumventions should be limited to actions that do not change the specification of service assets and that do not attempt to correct software errors. The preferred methods for circumventing incidents caused by software errors should be to revert to the previous trusted state or version, as relevant, rather than attempting an unplanned and potentially dangerous change. Change authorization is still a prerequisite.
Effectively, the emergency change procedure will follow the normal change procedure except that:
■ Authorization will be given by the ECAB rather than waiting for a CAB meeting
■ Testing may be reduced, or in extreme cases forgone completely, if this is considered a necessary risk to deliver the change immediately
■ Documentation, e.g. updating the change record and configuration data, may be deferred, typically until normal working hours.
4.2.6 Triggers, inputs, outputs and interfaces
4.2.6.1 Triggers
Requests for change can be triggered throughout the service lifecycle and at the interfaces with other organizations, e.g. customers and suppliers.
There will also be other stakeholders such as partners who may be involved with the change management processes.
Typical examples of types of change that trigger the change management process are described below.
Strategic changes
Service strategies require changes to be
implemented to achieve specific objectives while minimizing costs and risks. There are no cost-free and risk-cost-free strategic plans or initiatives.
There are always costs and risks associated with decisions such as introducing new services, entering
new market spaces and serving new customers.
The following are examples of programmes and initiatives that implement strategic changes:
■ Legal/regulatory change
■ Organizational change
■ Policy and standards change
■ Change after analysing business, customer and user activity patterns
■ Addition of new service to the market space
■ Updates to the service portfolio, customer portfolio or customer agreement portfolio
■ Change of sourcing model
■ Technology innovation.
Change to one or more services
Changes to the planned services (in the service portfolio) and changes to the services in the service catalogue will trigger the change management process. These include changes to:
■ Service catalogue
■ Service package
■ Service definition and characteristics
■ Release package
■ Capacity and resource requirements
■ Service level requirements
■ Warranties
■ Utilities
■ Cost of utilization
■ Service assets
■ Acceptance criteria
■ Predicted quality of service
■ Predicted performance
■ Predicted value
■ Organizational design
■ Stakeholder and communications plans
■ Physical change in the environment, e.g.
building
■ Measurement system
■ Plans, e.g. capacity, ITSCM, change, transition, test, and release and deployment plans
■ Decommission/retire services
■ Procedures, manuals, service desk scripts.
Operational change
It is important to know the distinction between different types of requests that will be initiated by users. These types of request will depend on the nature of the organization and services and may include requests such as password reset, access
Service transition processes |
85
request or request to move an IT asset. These types of change will often be managed as standard changes by the request fulfilment process.
Service operation functions will also implement corrective and preventative changes via the normal change procedure and the standard change
procedure. These should be managed through change management, for example restarting an application, which may impact a shared service.
Changes to deliver continual improvement When CSI determines that an improvement to a service is warranted, an RFC should be submitted to change management. Changes such as changes to processes can have an effect on service provision and may also affect other CSI initiatives.
Some strategy and service changes will be initiated by CSI.
4.2.6.2 Inputs
Changes may be submitted as an RFC, often with an associated change proposal that provides inputs from the service strategy stage of the service lifecycle. The inputs include:
■ Policy and strategy for change and release
■ Request for change
■ Change proposal
■ Plans – change, transition, release, test, evaluation and remediation
■ Current change schedule and PSO
■ Evaluation reports and interim evaluation reports
■ Current assets or configuration items, e.g.
baseline, service package, release package
■ As-planned configuration baseline
■ Test results, test report and evaluation report.
4.2.6.3 Outputs
Outputs from the process will be:
■ Rejected and cancelled RFCs
■ Authorized changes
■ Authorized change proposals
■ Change to the services, service or infrastructure resulting from authorized changes
■ New, changed or disposed configuration items, e.g. baseline, service package, release package
■ Revised change schedule
■ Revised PSO
■ Authorized change plans
■ Change decisions and actions
■ Change documents and records
■ Change management reports.
4.2.6.4 Interfaces
Change management must work with transition planning and support to ensure that there is a coordinated overall approach to managing service transitions.
In order to be able to define clear boundaries, dependencies and rules, change management and release and deployment management should be integrated with processes used for organizational programmes or projects, with supplier
management and also with suppliers’ processes and procedures. There will be occasions when a proposed change will potentially have a wider impact on other parts of the organization (e.g.
facilities or business operations), or vice versa, and the change management process must interface appropriately with other processes involved.
The change management process must be tightly integrated with change evaluation. There should be clear agreement on which types of change will be subject to formal change evaluation, and the time required for this evaluation must be included in the overall planning for the change. Change management provides the trigger for change evaluation, and the evaluation report must be delivered to change management in time for the CAB (or other change authority) to use it to assist in their decision-making.
Integration with business change processes Where appropriate, change management should be involved with business programme and business project management teams to ensure that
change issues, aims, impacts and developments are exchanged and cascaded throughout the organization where applicable. This means that changes to any business or project deliverables that do not impact services or service components may be subject to business or project change management procedures rather than the IT change management procedures. However, care must be taken to ensure that changes to service configuration baselines and releases do follow the change management process. The change management team will, however, be expected
86
| Service transition processesto liaise closely with projects to ensure smooth implementation and consistency within the changing management environments.
The service portfolio management process will submit change proposals to change management before chartering new or changed services, in order to ensure that potential conflicts for resources or other issues are identified.
Programme and project management
Programme and project management (usually based on PRINCE2 or PMBOK) must work in partnership to align all the processes and people involved in service change initiatives. Close alignment between change management and programme and project management is essential to ensure that the change schedule is effective and that all changes are well managed. Change