EMERGENCY Change:

The main elements of a standard change are that:

• Authority is effectively given in advance

• The tasks are well known, documented and proven

• There is a defined trigger to initiate the Request For Change (RFC)

• Budgetary approval is typically defined or controlled by the requester

• The risk is usually low and always well understood

Over time and as the IT organization matures the list of standard changes should increase in order to maintain optimum levels of efficiency and effectiveness.

EMERGENCY Change:

A change that must be introduced as soon as possible.

E.g. to resolve a major incident or implement a security patch.

The change management process will normally have a specific procedure for handling Emergency Changes quickly, without sacrificing normal management controls. Organizations should be careful to ensure that the number of emergency changes be kept to a minimum, because they are typically more disruptive and prone to failure.

To enable this to occur, methods of assessment and documentation are typically modified, with some documentation occurring after the change has occurred.

6.1.6 Triggers and Interfaces

Requests for Change can come from anywhere within service lifecycle or from interfaces with the business, suppliers or other stakeholders. The inputs required for the change and outputs produced will vary depending on the type defined and whether it is strategic, tactical or operational in nature.

Normal inputs include:

• Request for Changes (RFC)

• Policy and strategies for change and release

• Plans (change, transition, release, deployment, test, evaluation and remediation)

• Current change schedule and projected service outage (PSO)

• Current or affected assets and configuration items

• Test results, test report and evaluation reports.

Normal outputs from the process will be:

• Rejected RFCs

• Approved RFCs

• Changes to services, infrastructure components resulting from approved RFCs

• Updated change schedule

• Revised PSO

• Authorized change plans

• Change decisions, documents, records and reports

Interfaces with other service lifecycle processes should also be considered for a coordinated approach to quality service management. Additionally the integration of

Change Management with Business Change processes, project management and supplier management is recommended to enable seamless level of IT quality to be delivered.

Figure 6.2: Change Management workflow and key interfaces with Configuration Management

© Crown Copyright 2007 Reproduced under license from OGC

There can be various types of Change Requests to initiate the execution of Change Management processes, including:

• RFCs

• Service Desk calls

• Project Initiation Documents

Different types of change require different types of change request. An organization needs to ensure that appropriate procedures and forms are available to cover the anticipated requests from the different parties and stakeholders involved. Avoiding a bureaucratic approach to documenting a minor change alleviates some of the cultural barriers and resistance that may exist when adopting the Change Management process.

6.1.7 Change Management Activities

The following diagram represents the typical activities involved for Normal Changes that have been identified. The actual steps and procedures need to be further refined

depending on any specific Change models that have been created.

Figure 6.3: The Activities of Change Management

Overview of Important Steps:

1. The RFC is recorded.

2. Review the RFC for classification and prioritization

3. Assess and evaluate the Change – may require involvement of CAB or ECAB.

4. Authorization or rejection of the Change 5. The Change is scheduled.

6. Work orders are issued for the build of the Change (but carried out by other groups) 7. Change Management coordinates the work performed.

8. The Change is reviewed.

Management Ready for evaluation

1. The RFC is recorded.

The change is raised by a request from the initiator. The level of information recorded for a change depends largely on the size and impact of the change. Some information is recorded initially and some information updated as the change document progresses through its lifecycle. This may be recorded directly on the RFC form and details of the change and actions may be recorded in other documents and referenced from the RFC such as business cases.

For a major change with significant organizational and/or financial applications, a change proposal may be required, which will contain a full description of the change together with a business and financial justification for the proposed change. The change proposal will include sign off by appropriate levels of business management.

2. Review the RFC for classification and prioritization.

To ensure Change Management is using an appropriate level of control based on factors of risk, cost and complexity, an initial review should act as a filtering mechanism to apply the correct Change model to be used (classification), identify the relative priority of the Change, and to ensure that the required details are supplied. Procedures should stipulate that, as changes are logged, Change Management reviews each Change request and return any that are:

• Totally impractical

• Repeats of earlier RFC’s

• Incomplete submissions

These requests will be returned to the initiator, together with brief details of the reason for the rejection, and the log should record this fact. There should be an opportunity to appeal, via normal management channels, and should be incorporated within the procedures.

3. Assess and evaluate the Change.

All changes will be assessed for their relative potential impact, risk and resource

requirements. Depending on the Change model that has been applied, this assessment may require involvement from:

• Only the Change Manager and Change Owner for local authorization

• The Change Advisory Board (representing all key stakeholders)

• The IT Management (Steering) Board

• Business Executive Board.

The scope of potential impacts on services for failed changes is wide, so the assessment needs to identify potential for:

• Impact on customer’s business operation

• Effect on SLA’s, baselines, service models, security etc

• Impact on other services

• Impact on non-IT infrastructures

• Effect of not implementing

• Cost and staffing implications

• Current Change Schedule

• Ongoing resources required after implementation

• Impact on continuity plan, capacity plan, security plan, test environments, and any Service Operation practices.

The following table describes the type of hierarchical structures that may be used for different levels of change authorization. A degree of delegated authority may also exist within an authorization level. Formal authorization is obtained for each change from a change authority that may be a role, person or a group of people. The levels of authorization for a change should be judged by:

• Type

• Size

• Risk

• Financial implications

• Scope.