Information Services

Change Management Handbook

Doc. Ref. : INSRV Change Management Handbook Version : 2.4Status : DraftCreated by : Dave BallDate : 10 December 2007Approved by :

Version History

Version/Status

Release Date Comments

1.0/Draft 04 May 20072.0/Update 13 Nov 2007 Aligned to ITIL v32.3/Update 19 Nov 2007 Minor updates and formatting2.4/Update 10 Dec 2007 Draft For Wider Distribution

Contents

1 Introduction2 Process3 Roles and Responsibilities4 Reporting and Review

1. INTRODUCTION

1.1. Purpose, Goals and Objectives

The Change Management process is based on ITIL’s best practice Change Management process. It has been amended to suit the requirements of our environment and produce optimal benefit.

The target audience of this document is any person within INSRV who is likely to propose and/or make any Changes [as defined in this document], or do this on behalf of any non-INSRV member of Cardiff University.

Purpose:The purpose of this document is to define the scope, principles and process of Change Management for Information Services, Cardiff University.

To ensure that standardised methods and procedures are applied for the efficient and prompt handling of all changes to the Infrastructure within its scope.

To ensure all Changes to service assets are recorded in the Configuration Management System (CMS).

To make appropriate response to requests for change entails a considered approach to assessment of risk and business continuity, change impact, resource requirements, change authorization and especially to the realizable Business Benefit.

This assessment is essential to maintain the balance between the need for change and the impact of the change.

Goals:Respond to the customer’s changing business requirements while maximising value and reducing incidents, disruption and re-work.

Respond to the business and IT requests for change that will align the services with the business need.

Objectives:The main objective is to minimise the impact of change related incidents upon service by ensuring that changes are recorded and then evaluated, authorized, prioritised, planned, tested, implemented, documented and reviewed in a controlled manner.

This will consequently improve the day to day service levels and quality of service provided by Information Services.

1.2. Scope

The Change Management Process covers all changes on Configuration Items (CIs) included in INSRVs Configuration Management Handbook. The functional areas within the scope include, but are not necessarily limited to :

All Critical Systems Infrastructure All Computer Room facilities equipment and software running on them

including electricity, air conditioning, etc. All Network equipment and related software All Off the Shelf licensed production software - As part of the Definitive

Media Library Operational processes and documentation Decommissioning of all equipment, IT environment and services. All desktop equipment and software (Phase II of Change Management

implementation – Dependant on ITAM Project)

The CIs and their attributes covered by the Configuration Management System CMS, and therefore subject to Change Management, are defined in detail in the document “INSRV Configuration Management System Handbook”.

The programme/project management will be recommended to utilise Change Management for non-production environments.

Movement for a Projects Pre Production Environment into Service (i.e. Production) will be managed by INSRV’s Release Management process.

Summary:

All changes carried out on Production or Service CIs (as defined in the “INSRV Configuration Management Handbook”) will be subject to change management.

For CIs that were categorised as test and/or development CIs will not be subject to change management for changes carried out for test and/or development purposes, unless programme/project management require Change Management.

1.3. Definitions

1.3.1.IT Infrastructure Library (ITIL)

ITIL (IT Infrastructure Library) is the most widely accepted approach to IT Service Management. ITIL provides a cohesive set of best practice, drawn from the public and private sectors internationally. It is supported by a comprehensive qualification scheme, accredited training organisations, and implementation and assessment tools. The best-practice processes promoted in ITIL both support and are supported by the British Standards Institution’s Standard for IT Service Management (BS15000) and International Standards (ISO20000).

1.3.2.Change

Changes occur primarily for 2 reasons:

Proactively – seeking business benefit such as reducing cost or improving services or increasing the ease and effectiveness of support.

Reactively – a means of resolving errors and adapting to changing circumstances.

Changes need to be managed in order to Optimise Risk Exposure Minimise the severity of any impact and disruption Be successful at the 1st attempt

Any action that results in a new status for one or more Configuration Items (CIs) is a Change. This could be an addition, modification or removal of authorised, planned or supported service or service component and its associated documentation.

All CIs are documented in the “INSRVs Configuration Management Handbook”.

Examples of ‘CHANGE’ include -

Commissioning and Decommissioning of hardware Moving equipment from one location to another Carrying out maintenance on electrical equipment requiring outage Laying a new fibre optic cable between two locations Changing the standard PC Image to include a new version of operating

system, a significant OS patch, or added standard application(s) Change the way (procedure) incidents are handled.

1.3.3.Change Request or RFC

A formal communication seeking an alteration to one or more Configuration Items. Such as a Request for Change, Project Initiation Document, Service Desk call.

1.3.4.Change Calendar

A shared calendar showing all tentative and approved changes, and the agreed “at risk” periods. The calendar will be maintained by Service Management. This will be overlaid on the Academic calendar.

1.3.5.Configuration Item (CI)

Component of an infrastructure under the control of Configuration Management. CIs may vary widely in complexity, size and type – from an entire system (including all hardware, software and documentation) to a single module or a minor hardware component. Configuration Items are the records of CMDB. They may be hardware, software, or documentation. Examples include services, servers, environments, equipment, network components, desktops, mobile units, applications, licences, telecommunication services, and facilities.

1.3.6.Configuration Management System (CMS)

The CMS is a central data store that has all the relevant details of each Configuration Item (CI) coupled with the important relationships for that CI. The relevant details and relationships are imported from a number of relevant databases that INSRV already have in place or are due to implement, such as Socket, IDMAN and IBM Director.

1.4. Principles of Change Management

INSRV Service Management maintains a list of Technical Service Owners (TSO) and delegated representatives to enable proper approval of any RFC. It is the responsibility of the TSO and/or CSO to notify INSRV Service Management of any amendments.

The CM process assumes that all RFCs raised by entities outside Information Services for those CIs that they own, have been through their own change process and approved prior to being assigned to INSRV.

New RFCs internal to INSRV have to be approved by the Team Leader, or their delegated representative, prior to entering the Change Process

Impact Analysis & Risk Assessment are the responsibility of the requester and they need to be supplied in as much detail as possible to provide necessary information to the CAB

Information Services will decide the most appropriate way a business orchestrated IT RFC will be implemented

RFCs will be scheduled in accordance with the agreed planned downtime notice as per the Service Level Objectives (SLO).

RFCs will be grouped into ‘releases’ to minimise any downtime/change window making use of “at risk” periods identified in the Change Calendar

INSRV Change Calendar will document all approved RFCs in coordination with all agreed downtime windows.

1.5. Concepts for successful change management

Creating a culture of Change Management across the organization where there is zero tolerance for unauthorized change

Aligning service Change Management process with Business, Project, and stakeholder Change Management processes.

Prioritisation of Change

Establishing accountability and responsibility for changes through the service lifecycle.

Segregation of duty controls

Establishing a single focal point for changes in order to minimize the probability of conflicting changes and potential disruption to the production environment.

Preventing people who are not authorised to make a change from having access to the production environment.

Integration with other Service Management processes to establish traceability of change, detect unauthorized change and identify change related incidents.

Change Windows – enforcement and authorisation for exceptions

Performance and risk evaluation of all changes that impact service capability

Performance Measures for the process e.g. efficiency and effectiveness.

2. Process

Any event that alters the existing state of a Customers production IT Services (including software, hardware, networks and facilities). Service Providers seek to minimise disruption of IT Services by using standard process to communicate and implement changes.

Request Assess Authorize Implement Review

Service ProviderChange Management

Examples Business Impact

Customer Notification

Definition

PlannedChanges

Standard Change(Pre Authorised)

Security Patches Variable

Defined in the Standard Change

Variable(E.g. 2 Days)Defined in the Standard Change

A change that has previously been approved by the Change Management process and has an accepted and established procedure to provide a specific change requirement.

Normal or New Change

Installing a new piece of software or hardware

Broad or Significant Affect

At least 5 Working Days

Standard change that needs to follow the full process: RFC, technical reviews, CAB approval and implementation

Urgent Change

Service Levels risk being affected

Some Impact

ASAP Prior to Change being implemented

Implementation is pulled forward by speeding up the change process in case of a potential benefit from early implementation: RFC, accelerated review and approval, and implementation

Unplanned Changes

Emergency Change

Loss of a Service or a Server affecting a Service

Major Impact

ASAP after Changes made to restore Service

In case of an incident causing downtime, a change may be implemented without any approvals at the discretion of the technical staff to make the services available again. Change process should be followed after successful recovery of the services for reporting and review purposes.

Anyone who wants to introduce a change on IT systems is advised to consult the Standard Change Catalogue. If an entry in the task catalogue reflects the work you intend to carry out, follow the flow chart below to identify if it can be carried out as a task.

2.1.1 Determining the Impact and Risk - Change Impact/Risk Categorisation Probability MatrixMatrix model to enable requesters to determine an Impact v Risk required when raising an Request for Change(RFC).

Change Impact

Change Impact/Risk Categorisation MatrixHigh ImpactLow ProbabilityRisk Category: 2

High ImpactHigh ProbabilityRisk Category: 1

Low ImpactLow ProbabilityRisk Category: 4

Low ImpactHigh ProbabilityRisk Category: 3

Probability

2.1.2 Change PriorityMatrix outlining the priority of a change when completing an RFC.

Priority Corrective Change Enhancement ChangeImmediate Putting Service Life at risk

Causing significant loss of revenue or the ability to deliver important public services.

Immediate Action Required

N/A

High

To be given highest priority for change building, testing and implementation resources

Severely affecting some key users or impacting on a large number of users.

Meets legislative requirementsResponds to short term market opportunities or public requirementsSupports new business initiatives that will increase company market position

Medium No severe impact, but rectification cannot be deferred until the next scheduled release or upgrade.

Maintains business viability

Supports planned business initiativesLow A change is justified as necessary, but

can wait until the next scheduled release or upgrade.

Improvements in usability of a service

Adds new facilities

2.1.3 Identifying what type of Change is it - Planned Changes

2.1.4 Change Workflow and interfaces to Configuration ManagementDiagram showing the inter-relationship of the Change Management process and the maintaining of the information stored in the Configuration Management System (CMS).

2.2 Normal or New Change

The Normal/NEW Change process workflow is as follows:

Who What Actions

1

Requester

(1st/2nd Level Support

Alert from Monitoring Tool)

Raise New Change o Create an RFC in the Service Desk.

2 Team Leader Assess the Change

o Review the content and verify the RFC Call for completeness.

o Accept Change (Passes to Change

Coordinator).o Reject Change (Passes back to Requester

with feedback)

3

ChangeCo-ordinator

(Team Leader or Representative)

Arranges Technical/Customer Review

o On Accept of Change make a tentative entry of the proposed Change in the Change Calendar if there is a proposed implementation date/time

o Liaise with relevant technical areas to review the Change and state their agreement or rejection. Taking into account current Change Calendar.

o Ensure customers affected by the Change are also included in the review through insrvAssist.

o After all technical review agreements are in place; schedule the Change for discussion at the CAB with agreement from Team Leader.

4 CAB Approve Change

o Review changes submitted and assess resource requirements, risks, dependencies etc.

o Give final go-ahead for the Change to be implemented.

o Where requested, review the Change for inclusion in the Standard Change Catalogue

5

ChangeCo-ordinator

(Team Leader or Representative)

Communicate CAB decision

o Update the initially tentative entry in the Change Calendar as approved

o Communicate CAB decision to the Service Desk, Configuration Management, Requester, TSO and insrvAssist

o Develop Work Instruction utilising Standard Change Catalogue if necessary.

6 Implementer Implement Change o Implement the Change according to the Work Instruction provided (or create one)

o Initiate back-out plans where

necessaryo Update the RFC call with the result of

implementation

4.Configuration Management

Update CMDBo Ensure the status of CI’s have been

updated following this change

2.3 Standard Changes (Pre-Authorised)

A Standard Change is associated with a standard procedure which has previously been approved by the Change Board (CAB) for inclusion in the Standard Change Catalogue (SCC). It is likely that this Change will be implemented repetitively; CAB may pre-approve the Change to become a Standard Change for inclusion in the SCC. Once a Change is included in the Standard Change Catalogue, it can be requested, with reference to the SCC, raising a Request for Change (RFC) in the Service Desk.

Who What Actions

1. Requester

Raise Standard Change with Change Management

o Raise an RFC in the Service Desk with the Standard Change reference and any required information.

o The workflow associated with the Standard Change will determine whether the Standard Change requires Approval.

2.

Approver

Defined in the Standard Change

Approve Change

o Approve the Change; The workflow will pass it on to the implementer.

o Reject the Change; return it to the requester with an explanation/request for additional information.

3.Communication

(Automated)Advertise Change

o RFC is scheduled in the Change Calendar by the Change Co-ordinator.

o insrvAssist are informed of the Change and ensure customers impacted by the change are informed.

4. ImplementerImplement Change

o Implement the Change according to the Standard Work Instruction associated with the Standard Change.

o Ensure the Back-out Plan has been documented.

o Inform Change Management and Service Desk whenever the change encounters errors and/or fails during implementation.

o Confirm Successful Change Completed to Change Management.

4.

Configuration Management

(Automated)

Update CMDB

o The Standard Change Workflow should update the CMDB with the effects of the change. Configuration Manager validates the CMDB.

2.4 Urgent Change

Urgent change process is an accelerated version of the Normal Change process. There must be a financial and/or business benefit associated with the urgent implementation of a Change that was either unavailable or not known before.

A Change is not deemed to be ‘urgent’ because the request was raised too late as a result of poor planning at its source. There should always be a clear business reason for a Change to be processed as ‘urgent’.

Who What Actions

1. Requester

Raise Urgent Change with Change Management

o Create an RFC in the Service Desk. o The form must clearly indicate that the

Change is requested as ‘URGENT’ and the business reason(s) why it is requested as such.

2.Change

Co-ordinatorAccepts the Change

o Urgently review the content and verify the RFC Call for completeness.

o Urgently make a tentative entry of the proposed Change in the Change Calendar if there is a proposed implementation date/time.

3.ChangeManager

Arranges urgent approval

o Send an e-mail to all CAB members to inform and seeks immediate agreement from at least two CAB members, and

o Ensure customers affected by the Change are also included in the review through their customer representative.

o In case of rejection, inform the Requester and ensure that the issue is resolved; escalate where necessary

o Upon receiving approvals from two members of the CAB, schedule the Change

4.Change

Co-ordinatorCommunicate CAB decision

o Update the initially tentative entry in the Change Calendar as approved

o Communicate the Urgent Change to CAB members, Service Desk, insrvAssist, Requester, System Owner and Customer Representative

6. Implementer Implement Change

o Implement the Change according to the Work Instruction provided

o Initiate back-out plans where necessary

o Update the change ticket with the result of implementation

2.5 Emergency Change

In case of an incident resulting in downtime to a CI providing a Service, the priority should be given to resolving the incident. Staff dealing with the incident may decide to make changes and commit those changes at their own discretion to resolve the ongoing incident. The following process should be followed retrospectively, once the incident is resolved, with the purpose of recording the committed changes.

Who What Actions

1. Implementer Implement Change

o Implements the change with the aim of recovering the services at the discretion of the technical staff and their manager working on the incident

o Notify insrvConnect that you are dealing with the Emergency as dictated by a particular source e.g. IBM Director.

o Ensure that a note of the Changes are made for inclusion in the RFC to follow

2. Implementer

Raise Emergency Change with Change Management

o Once the incident has been resolved and services are recovered, notify Change Management by creating an RFC Call.

o Associate related incidents to the RFC.

3.ChangeManager

Inform CAB

o Report emergency Changes immediately to CAB members via e-mail and add it to next CAB meeting agenda for discussion.

o Advise insrvAssist and insrvConnect that Emergency Change took place.

4. CAB Review Change

o Review and confirm the change as a valid emergency change

o Initiate actions to avoid repetition of any similar incidents with the involvement of Problem Management

3. ROLES AND RESPONSIBILITIES

3.1. Change Manager

Change Manager has overall responsibility for managing the CM process and ensuring that there are no bottlenecks causing delays in processing Requests for Change (RFCs).

Chairs the CAB Meetings. Arranges Authorisation of Urgent Changes through CAB Communicated Emergency Changes to all CAB Members Assists in the creation of ‘Standard Changes’ to be included in the SCC

with respective Back Office teams.

Note that the budget and/or the financial approval of the Change is the responsibility of the requester. This refers to the assessment of the cost of the Change and ensuring that it is within the approved budgetary limits of the approver.

3.2. Team Leader or Designated Change Co-ordinator

The Team Leader/Change Coordinator provides the main point of contact for the person[s] raising the RFCs and is the main facilitator of the Change Management process.

It is their responsibility to ensure that two principal reviews are undertaken before a change is submitted for CAB approval:

Technical Review is the assessment that the Change is technically feasible, sensible and can be performed without inappropriate detriment to the services

Customer Review is to ensure that the business managers are content with the Change proposal and the impact on the business

Receive and validate RFCs for their Technical Area. In case of a rejection, coordinate the issue between the requester and

the technical authority; escalate when necessary Coordinate approval of RFCs with the members of the CAB Communicate the outcome to relevant parties; update the Change

Calendar

3.2. Approver(s)

The approver is the member of staff who has the authority to sanction the Change to take place. This will be dependent on what change is taking place and it may be a Team Member, Team Leader, TSO, Associate Director, Assistant Director, CSO who will approve the respective changes.

A Change may require more than one Approver to sanction the Change.

3.2. Implementer(s)

The Implementer(s) perform the change(s) on the affected CIs and report back to the Change Coordinator on the status of the Change.

3.3. Requester(s)

The Requester(s) is the person or system that has determined that the Change should take place.

3.4. Change Advisory Board (CAB)

Change Advisory Board (CAB) is the body which exists to support the authorisation of changes and to assist the Change Management in assessing and prioritising changes.

It not CAB's direct responsibility to make technical reviews. CAB should ensure that all necessary technical reviews have taken place, and they have been made properly, balancing the level of their assessment based on the overall risk of the change.

Proposed CAB Membership:

Change Manager (Chair)Production Service ManagerInfrastructure ManagerNetwork Team ManagerSecurity Team ManagerinsrvAssist &/or Customer Representative

Depending on the Changes being considered by the CAB representatives from:

System/Application Specialists/Team Leaders Facilities Contractors

The procedure should define who is required by the CAB.

The Managers of the units listed above are the natural members of the CAB. When they are not available to attend the CAB meeting, it is the responsibility of these Managers to provide a suitable replacement.

The CAB should convene on a Weekly basis (Either as a meeting or electronically). Members can send a deputy or pass feedback if they are unable to attend. CAB members should be in a position to express views and make decisions on

behalf of theirIf there are no issues to be discussed, the CAB meeting may be called off by the Change Manager.

Following are the responsibilities of the CAB members:

Ensure all submitted RFCs are reviewed within their relevant areas before attending to the CAB meeting. Determine and provide details of their likely impact, the implementation resources, and the ongoing costs of all Changes.

Attend or ensure attendance of a deputy to all CAB meetings. Provide opinion on which Changes should be authorised. Participate in the scheduling of all Changes.

Do their best to be available for consultation should an Urgent Change review be required.

Provide advice to Change Management on aspects of proposed urgent changes.

Make recommendations to resolve Emergency Changes

The CAB is an advisory body and if agreement cannot be made then the following authorisation model will be used:

3.4.1.CAB Agenda

The standard agenda for a CAB meeting is as follows ~

Review of all Changeso Failedo Backed-Outo Changes applied without reference to the CAB by IM, PM or

CM RFCs to be assessed by CAB Members (in structured and priority order). RFCs that have been assessed by CAB members. Scheduling of Changes and update the Change Schedule. Change Review Advance Warning of Future Changes.

Outstanding Changes and changes in progress. Review of Unauthorised Changes

Typical Weekly Change Calendar

Mon Tue Wed Thurs Fri Sat Sun060008000900120013001700190022002400

Legend0600-0700

Weekly Maintenance WindowFor Scheduled/Automated Tasks

0800 - 0900

Manned Weekly Maintenance Window

0800-2200

Core Service HoursAgreed Standard Changes and Emergency Changes Only

From 1730

Urgent Daily Change WindowOutside Core HoursEmergency Changes Only

0900-1000

Change ‘At Risk’ Period Weekly CAB Meeting

4. Regular Review and Reporting

All New and Standard Changes will be reviewed by Change Management after their implementation to ensure that the desired outcome has been achieved.

The Change Manager will report to the CAB about the status of the Changes in every meeting, and will also report regularly to the Senior Management about the overall status of Change Management implementation across Information Services.

Reports and KPIs to include but not limited to the following:

Number of new, urgent, emergency and pre-approved standard changes per functional area

Percentage of changes that were successful, unsuccessful, and those that failed in the first attempt of implementation

Summary of unauthorised changes identified and actions taken MTRS – Mean Time to Restore Service will be calculated and advertised

to customers

o

Changes Implemented to services that met the customers agreed requirements (Quality/Cost/Time) - % of all changes

Benefits of Change – Value of Improvements + Negative Impact Removed/Terminated compared with the cost of the change.

Reduction in the number of Disruptions to Service Reduction in the number of Unauthorised Changes Reduction in the Backlog of Change Requests Reduction in the Number and % of unplanned changes and emergency

fixes. Change Success Rate – Number of Successful at review/Number of

approved RFCs Reduction in the number of Failed Changes Average time to implement based on urgency/priority/change type. Incidents attributed to Changes % Accuracy in change estimates

The review and reporting cycle is set as follows:

Report / Review By Purpose / ActionsWeekly CAB Review CAB Ensure routine flow of the change

cycle- review failed changes during

last period- review and approve proposed

changes6-monthly CAB Review CAB + ITIL

Service Support Discipline Owners

- All changes by type and number of unauthorised changes and changes failed in their first implementation attempt by functional area- Review the change process

Annual Senior Management Review

Change Manager and

- Report overall change status to Senior Management

INSRV Board - Review the Change and Configuration Management Strategy