ITILST0202 Change Management Process by CertiKit Limited

Change Management Process

ITIL® 2011 Service Transition Process and Policy Pack v2 ©CertiKit ITIL is a registered trade mark of AXELOS Limited

Change Management Process

Implementation guidance The header page and this section, up to and including Disclaimer, must be removed from the final version of the document. For more details on replacing the logo, yellow highlighted text, and certain generic terms, see the Completion Instructions document.

Purpose of this document This document sets out the change management process including flowchart, activities, reporting and roles and responsibilities.

Areas of the ITIL® Framework addressed The following areas of the ITIL Framework are addressed by this document: •

Service Transition: Change Management

General guidance The introduction of more formal change management can be traumatic for an organization and is sometimes met with resistance. As with all of the ITIL processes, the key is to try to establish ownership of the process by those that are needed to make it work. Other important aspects of the approach are to ensure that there are clear roles defined and that the tools used to record and process changes are understood by those involved. There will be a need to establish a more proactive planning culture amongst those raising changes and you may need to manage down the number of emergency changes raised over time.

Review frequency We would recommend that this document is reviewed annually.

Document fields This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”. Version 1

Page 2 of 36

[Insert date]

Change Management Process

To update this field (and any others that may exist in this document): 1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name. 2. Press Ctrl A on the keyboard to select all text in the document (or use Select, Select All via the Editing header on the Home tab). 3. Press F9 on the keyboard to update all fields. 4. When prompted, choose the option to just update TOC page numbers. If you wish to permanently convert the fields in this document to text, for instance, so that they are no longer updateable, you will need to click into each occurrence of the field and press Ctrl Shift F9. If you would like to make all fields in the document visible, go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check you have updated all fields correctly. Further detail on the above procedure can be found in the toolkit Completion Instructions. This document also contains guidance on working with the toolkit documents with an Apple Mac, and in Google Docs/Sheets.

Copyright notice Except for any specifically identified third-party works included, this document has been authored by CertiKit, and is ©CertiKit except as stated below. CertiKit is a company registered in England and Wales with company number 6432088.

Licence terms This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence. If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third-party copyright included in this document.

Disclaimer Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from which you will

Version 1

Page 3 of 36

[Insert date]

Change Management Process

create your own document and to which you will apply all reasonable quality checks before use. Therefore, please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country. You should take all reasonable and proper legal and other professional advice before using this document. CertiKit makes no claims, promises, or guarantees about the accuracy, completeness or adequacy of our document templates; assumes no duty of care to any person with respect its document templates or their contents; and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.

Version 1

Page 4 of 36

[Insert date]

Change Management Process

Version 1

DOCUMENT REF

ITILST0202

VERSION

DATED

[Insert date]

DOCUMENT AUTHOR

[Insert name]

DOCUMENT OWNER

[Insert name/role]

Page 5 of 36

[Insert date]

Change Management Process

Revision history VERSION

DATE

REVISION AUTHOR

SUMMARY OF CHANGES

Distribution NAME

TITLE

Approval NAME

Version 1

POSITION

SIGNATURE

Page 6 of 36

DATE

[Insert date]

Change Management Process

Contents 1

Introduction ............................................................................................................... 9 1.1

Vision statement.......................................................................................................... 9

1.2

Purpose ....................................................................................................................... 9

1.3

Objectives.................................................................................................................. 10

1.4

Scope ........................................................................................................................ 10

Change management process ................................................................................... 11 2.1

Overview and process diagram ................................................................................... 11

2.2

Process triggers.......................................................................................................... 13

2.3

Process inputs............................................................................................................ 13

2.4

Process activities........................................................................................................ 13

2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.4.8 2.4.9

2.5

Emergency changes.................................................................................................... 17

2.6

Process outputs ......................................................................................................... 18

2.7

Change management tools ......................................................................................... 18

2.7.1 2.7.2

2.8 2.8.1 2.8.2 2.8.3 2.8.4 2.8.5 2.8.6 2.8.7

Create RFC................................................................................................................................. 13 Record RFC ................................................................................................................................ 14 Review RFC................................................................................................................................ 14 Assess and evaluate change ...................................................................................................... 14 Authorise change build and test ................................................................................................ 16 Co-ordinate change build and test ............................................................................................. 16 Authorise change deployment ................................................................................................... 16 Co-ordinate change deployment ............................................................................................... 16 Review and close change record ................................................................................................ 17

Change management system..................................................................................................... 19 Configuration management system ........................................................................................... 19

Communication and training ...................................................................................... 19 Communication with change initiators ...................................................................................... 19 Communication with change authorities ................................................................................... 20 Communication with IT teams ................................................................................................... 20 Communication with projects .................................................................................................... 20 Process performance ................................................................................................................. 20 Communication with incident and problem management ......................................................... 21 Training for change management .............................................................................................. 21

Roles and responsibilities ......................................................................................... 22 3.1

Operational roles ....................................................................................................... 22

3.2

RACI matrix................................................................................................................ 22

3.3

Change management process owner .......................................................................... 23

3.4

Change management process manager (change manager) .......................................... 23

3.5

Change initiator ......................................................................................................... 24

3.6

Change authority ....................................................................................................... 24

3.7

Change builder/implementer ..................................................................................... 25

Version 1

Page 7 of 36

[Insert date]

Change Management Process

Associated documentation ....................................................................................... 26

Interfaces and dependencies .................................................................................... 27

5.1

Other service management processes ........................................................................ 27

5.2

Business processes ..................................................................................................... 28

Process measurements and metrics ......................................................................... 29 6.1

Critical success factors................................................................................................ 29

6.2

Key performance indicators........................................................................................ 29

6.3

Process reviews and audits......................................................................................... 30

Process reporting ..................................................................................................... 31 7.1

Process reports .......................................................................................................... 32

7.2

Operational reports ................................................................................................... 33

Glossary, abbreviations and references .................................................................... 34 8.1

Glossary..................................................................................................................... 34

8.2

Abbreviations ............................................................................................................ 36

8.3

References................................................................................................................. 36

Figures Figure 1: Change Management Process ....................................................................................... 12

Tables Table 1: Levels of change review and authorisation .................................................................... 15 Table 2: RACI matrix ................................................................................................................... 22 Table 3: Associated documentation ............................................................................................ 26 Table 4: Interfaces with other service management processes .................................................... 28 Table 5: Interfaces with business processes ................................................................................ 28 Table 6: Critical success factors ................................................................................................... 29 Table 7: Key performance indicators ........................................................................................... 30 Table 8: Process reports ............................................................................................................. 33 Table 9: Operational reports ...................................................................................................... 33 Table 10: Glossary of relevant terms ........................................................................................... 35

Version 1

Page 8 of 36

[Insert date]

Change Management Process

1 Introduction 1.1 Vision statement The vision of [Service Provider] in the area of service management is as follows: [Insert the vision statement defined as part of service strategy] This process forms a key part of the realisation of that vision.

1.2 Purpose Change is an essential part of the modern business environment and it is often the ability of an effective supporting IT organization to manage the implications of that change that sets it apart from others. Whether change is proactive to move us forwards or reactive to adapt to incidents, problems, or external events such as new legislation, it will inevitably carry with it an element of risk. Part of the purpose of the change management process is to manage and contain that risk in accordance with the risk appetite of the organization itself. This document defines how the process of change management is implemented within [Organization Name]. The purpose of the change management process according to ITIL® is:

“… to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.” Source: ITIL Service Transition Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS.

A change is defined as:

“… the addition, modification or removal of anything that could have an effect on IT services.” Source: ITIL Service Transition Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS. Version 1

Page 9 of 36

[Insert date]

Change Management Process

1.3 Objectives The objectives of the change management process are to: • • • •

Manage the assessment and implementation of changes to the IT environment in accordance with the business requirements and risk appetite of the organization Ensure that the Service Knowledge Management System (SKMS), including the Configuration Management Systems (CMS), remains up to date in the face of frequent and varying changes Keep accurate records of changes made and the configuration items affected by them, for use in other processes such as incident and problem management Provide benefit to the business by delivering desirable change whilst preventing undesirable change

1.4 Scope The scope of this process is defined according to the following parameters: • • • •

Organizational o [List organizations and parts of those organizations covered] Geographical o [List locations from which requests for change will be accepted and managed] Services o [Define the services covered by the process] Technical o [If necessary, cover the technology that may give rise to changes managed via this process]

This process covers all changes processed by [Service Provider] in support of the customers and users of services defined in the service catalogue. The following areas are specifically excluded from this process: [Describe any areas that need to be clearly stated as outside the scope]

Version 1

Page 10 of 36

[Insert date]

Change Management Process

2 Change management process 2.1 Overview and process diagram The process of change management is shown in Figure 1 and summarised below. The process is initiated by the creation and submission of a Request for Change (RFC). In line with the Change Management Policy, the following types of change will be processed: • • •

Standard Normal Emergency

This document mainly relates to the last two of these types, the normal and emergency changes. Standard changes are low-risk, pre-approved changes and so do not need to follow the full review and approval process. Standard changes will generally be recorded in the service desk system as service requests and the implementation process of each standard change will be fully documented. Normal changes are “business as usual” changes which are expected to make up the majority of the RFCs that are logged and handled through the change management process as described in this document. Although not emergencies, they will be prioritised in order that resources can be allocated in as effective a manner as possible. Once an RFC has been submitted it is recorded in the change management system and reviewed for completeness and appropriateness. If acceptable it is then assessed and evaluated by the most appropriate people according to the nature and scope of the change. Major or high-risk changes may be escalated to the IT steering group or the executive board. If the conclusion from the assessment is that the change should be authorised then it moves to the build and test stage, after which it is deployed under the control of change management. The success of deployed changes is then reviewed at an appropriate time after implementation. At each point, the CMS is consulted and if necessary, updated.

Version 1

Page 11 of 36

[Insert date]

Change Management Process

Figure 1: Change Management Process

Version 1

Page 12 of 36

[Insert date]

Change Management Process

2.2 Process triggers The change management process is initiated as a result of one or more of the following triggers: • •

An RFC is submitted via one of the available channels A change proposal is raised as part of the service portfolio management process

2.3 Process inputs The process of change management requires a number of inputs in order to be able to function effectively. These may not always be available but will ideally be: • • • • • • • • •

Correctly raised RFCs Change proposals Business, service and technical knowledge relevant to the proposed change Change evaluations and assessments An indication of the prevailing risk appetite of the business and IT organization Configuration management records Build, test and implementation plans and status reports Details of incidents and problems giving rise to the RFC Details of incidents and problems resulting from the implementation of the RFC

2.4 Process activities The individual process activities at each step are detailed as follows.

2.4.1 Create RFC The RFC is created by the change initiator based on their requirements. RFCs may be submitted either using a template RFC form or directly into the change management system via the web portal or client software, depending on the access available to the initiator. The minimum information specified on the RFC should include: • • • • •

Initiator name and contact details Change title Change description Reason for the RFC Business benefit of the RFC

Version 1

Page 13 of 36

[Insert date]

Change Management Process

For RFCs raised by technical staff it may be appropriate at this stage to include additional details (if available) regarding the testing and implementation plan for the change e.g.: • • • • •

Testing carried out so far with results Back-out plan Implementation plan Post-implementation testing plan Any supporting information e.g. related incident or problem references

If this information is not available at the time of raising the RFC, it will be added further on in the process. Normal RFCs should be submitted at least two weeks before the desired implementation date but due to the diverse nature of changes the time taken to assess and authorise any particular RFC is not guaranteed.

2.4.2 Record RFC The RFC is recorded within the change management system by the change manager (or deputy) and allocated a unique reference number. If the RFC was entered directly into the system this will have been done automatically when it was created.

2.4.3 Review RFC Once created, the RFC is reviewed by the change manager to ensure that it is appropriate to progress to the next stage, including that: • • • •

The initiator has the required authority to request the change The RFC has been correctly completed i.e. all of the required information is included It is not a duplicate of an existing RFC It is a reasonable request e.g. it is not based on a misunderstanding about how the affected area works

The change manager may need to consult other people, including subject matter experts, in order to complete the review.

2.4.4 Assess and evaluate change The RFC will then be assessed by a group of people appropriate to the subject of the change (the Change Advisory Board, CAB) initially to gain an idea of the significance of it. This assessment will consider the “seven Rs” of change management, namely:

Version 1

Page 14 of 36

[Insert date]

Change Management Process

1. 2. 3. 4. 5. 6. 7.

Who raised the change? What is the reason for the change? What is the return required from the change? What are the risks involved in the change? What resources are required to deliver the change? Who is responsible for the build, test and implementation of the change? What is the relationship between this change and other changes?

(Seven Rs Source: “ITIL Service Transition Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS) Based on advice from the CAB, the change manager will determine the type of assessment that should be carried out for each RFC and the level at which it will need to be authorised. These change authority levels are summarised in the following table.

LEVEL

CHANGE AUTHORITY

LEVEL OF RISK/IMPACT

Level 1

Business Executive Board

High cost and/or risk

Level 2

IT Steering Group

Multiple services or organizational divisions

Level 3

CAB or ECAB

Local service or organization

Level 4

Change Manager

Low risk

Level 5

Local authorisation

Standard change

Table 1: Levels of change review and authorisation

For changes assessed to require authorisation at levels 1-3, the change manager may decide that it is appropriate to engage the formal change evaluation process. For those changes that may be assessed by the CAB, the members may vary according to the subject of the RFC but will typically include representatives from: • • • •

Change management (chair) The business area affected The IT service(s) affected The team(s) supporting the technology involved

CAB meetings will be held weekly but frequent communication via phone, email or the change management system may be required to ensure that business requirements can be met, and changes assessed in a reasonable timeframe.

Version 1

Page 15 of 36

[Insert date]

Change Management Process

2.4.5 Authorise change build and test If the conclusion of the change assessment is that it is acceptable in terms of risk and impact, it will be authorised by the appropriate level of change authority. For changes assessed and authorised at levels 1 and 2 it may be the case that a project is initiated to implement the change and that service design activities are required. In such cases, liaison between the project manager and the change manager will be required to ensure that the status of the change is understood at key points in the project. The RFC will also be prioritised so that guidance is given for the use of resources across multiple changes.

2.4.6 Co-ordinate change build and test Once authorised, the change will be passed to the relevant team to build and test. For programming changes this may involve the creation or amendment of code and associated system and integration testing within separate test environments. For technical configuration changes, the build and test stage may consist of making such changes within a test server or network if available. The team building and testing the change will liaise with change management and report the status of the change on a regular basis. Once ready for deployment they will inform the change manager.

2.4.7 Authorise change deployment Once completed, the test results from the previous stage will be reviewed by the relevant change authority. Peer technical reviews may be requested where appropriate. Authorisation will be given for the change to be implemented in a specific way and at a specific date and time. If these conditions cannot be met at the time of implementation, the change should be referred back to the change authority for re-authorisation for deployment.

2.4.8 Co-ordinate change deployment For releases (i.e. groups of changes implemented together), the implementation will be coordinated via the release and deployment management process. For individual changes change management will provide co-ordination. The change should be implemented at the agreed date and time and within the authorised scope. Post-implementation testing will be carried out to check that the implementation Version 1

Page 16 of 36

[Insert date]

Change Management Process

was successful. If the change is not successful, then further actions will depend upon the actual effect of the change. The default situation will be that the change is backed out according to the agreed back-out plan but in some circumstances, it may be appropriate to raise an additional RFC to correct failed aspects of the previous one. Any such RFCs raised must go through the change management process as described here.

2.4.9 Review and close change record After an appropriate period following the implementation of the change a review will be conducted to assess its success. This will typically be judged according to the following criteria: • • • • • • • • • •

Have any incidents been raised that may be attributed to the change? Has the change had the desired effect? Is the change initiator happy with the change? Are there any unexpected side-effects of the change? Have the benefits of the change been realised? Did the change implementation go to plan and if not, what lessons can be learned? Were the resources allocated appropriate? Were the costs of the change within the expected parameters? Was the degree of testing adequate? If the change was backed out, did the back-out plan work as expected?

For larger changes, the review may be carried out as part of the (more formal) change evaluation process. Once reviewed, the results of the review must be recorded and the change record closed, along with any related incident or problem records.

2.5 Emergency changes Whilst all changes likely to be required should be foreseen and planned, there will be occasions when business requirements demand that changes be made in an emergency situation. Such changes are those requests which impact on internal or external ‘live’ systems and require implementation in order to resolve (or prevent) a current high priority incident or problem. In such cases a change request must be raised immediately even if the full change details are not available and the CAB must be notified. This is to ensure that all parties are aware at the earliest opportunity. From initial logging of the change, the principles of the normal change management process should be observed as far as is realistic, however, as an emergency changes may require swift approval from the CAB an Emergency CAB (E-CAB) meeting may be held.

Version 1

Page 17 of 36

[Insert date]

Change Management Process

If an emergency change cannot be formally authorised after reasonable efforts have been made to follow the process (e.g. out of hours) a local decision may be made as to whether this change will be implemented. However, details of the change must still be recorded, and the change management process followed retrospectively to ensure that records are maintained accurately, and the success or failure of the change can be reviewed. Where timescales allow it, the Change Manager in collaboration with the relevant support groups will ensure the following: • • •

Sufficient staff and resources are available to action and support the change request Back-out plans have been documented and passed to the change Implementer As much testing as possible of the emergency change has been completed

When an emergency change request is logged the Change Manager will do the following: • •

Assess who should form the Emergency Change Advisory Board (E-CAB) Communicate with each member of the E-CAB by whatever means is appropriate (face-to-face, telephone, email) to obtain a combined impact assessment

The remainder of the process will then continue but under the auspices of the E-CAB rather than the scheduled CAB i.e. as quickly as possible whilst retaining control and managing risk Changes processed as emergencies will be reviewed by the CAB on a regular basis to ensure that they are genuine emergencies and do not arise from a lack of forward planning.

2.6 Process outputs The outputs of the change management process will be the following: • • • • • • •

Closed change records Successfully completed changes Rejected RFCs, where appropriate Failed changes, together with relevant reviews and action plans Updated configuration item records Lessons learned from change reviews Closed incidents and problems that are related to the change

2.7 Change management tools There are a number of key software tools that underpin an effective change management process. These are subject to change as requirements and technology are updated and so specific systems are not described here. However, the main types of tools that play a significant part in the process within [Organization Name] are as follows.

Version 1

Page 18 of 36

[Insert date]

Change Management Process

2.7.1 Change management system The change management system is a workflow system that allows the logging of RFCs directly into the process via a web interface and a desktop client. Changes are then managed and directed according to the defined process, under the control of the change manager. Tasks can be assigned to individual users for change assessment and authorisation and later on for change building, testing and implementation. Results of all reviews can be recorded as notes within the system, along with pre-defined information at each stage of the process. Supporting information such as test and back-out plans may be attached to change records and accessed by those involved in the process for that specific change.

2.7.2 Configuration management system The configuration management system provides the capability to link changes with the configuration items they affect, building up a change history for CIs such as servers, databases and applications. This is useful in incident management where a particular incident may be tracked back to a change made at an earlier date. The status and version of CIs may be updated as the change management process progresses so that an accurate picture of the organization’s infrastructure is maintained at all times, even in the face of frequent change.

2.8 Communication and training There are various forms of communication that must take place for the change management process to be effective. These are described below.

2.8.1 Communication with change initiators The initiator of the RFC may need to explain the rationale for the change in more detail and describe the benefits expected from it. Once the RFC is logged, the change initiator must be kept informed of its progress and ideally be given some kind of indication of its expected delivery date. After implementation, the change initiator will be a key contributor to the change review, including whether the benefits were realised.

Version 1

Page 19 of 36

[Insert date]

Change Management Process

2.8.2 Communication with change authorities As part of the assessment and authorisation of changes, the change manager must communicate effectively with the members of the relevant change authority for that change. This will be achieved mainly via the change management system and email where appropriate.

2.8.3 Communication with IT teams Often the implementers of a change will be one or more IT teams that support the specific area of technology involved. It is vital that they are accurately informed of the change requirements and expected benefits so that resources are not wasted, and the required results are achieved. It is key to the change management process that the implementer(s) of a change keep the change manager informed about its progress, particularly if the build and test stage is lengthy.

2.8.4 Communication with projects For those changes that are major in terms of their scope, risk and impact, a project will most often be used as the best method of delivery. The change manager must ensure that regular updates on progress are obtained and that all changes required as part of the project go through change management. It may be appropriate for the change manager to attend some project meetings. Similarly, it may be appropriate for the project manager to attend relevant CAB meetings.

2.8.5 Process performance It is important that the performance of the change management process is monitored and reported upon on a regular basis in order to assess whether the process is operating as expected. The content of performance reports is set out in section 6 of this document, but it is vital that the reports are not only produced but are also communicated to the appropriate audience. This will include the customers of the IT service and the management of IT concerning resource utilisation and allocation. Depending on the health of the process it may be appropriate to hold regular meetings with customers and IT management to discuss the performance and agree any actions to improve it.

Version 1

Page 20 of 36

[Insert date]

Change Management Process

2.8.6 Communication with incident and problem management Some changes will have been raised in order to resolve one or more incidents and problems. The service desk manager will benefit from frequent updates on change management activity, including the timing of key changes that might give rise to further incidents. If this is the case, the service desk manager will need to inform the change manager so that this fact may be considered as part of the change review. The change manager should inform the problem manager when changes that were raised to resolve problems have been implemented. Again, the success of the change in resolving the problem may be judged by the problem manager and input to the change review.

2.8.7 Training for change management In addition to a well-defined process and appropriate software tools it is essential that the people aspects of change management are adequately addressed. The process requires that training be provided to all participants in order that it runs as smoothly as possible. The main areas in which training will be required for change management are as follows. • • • •

The change management process itself, including the activities, roles and responsibilities involved Change management software tools such as the change management system and configuration management system The basics of the technology and how it is implemented within [Organization Name] The business, its structure, locations, priorities and people

In addition, training should be provided to the user population regarding how to identify and propose a change, including: • • •

The difference between an RFC, incident, a service request and a problem and how they are handled How to submit an RFC via the various means available What may be expected of them as part of change management

This training may be provided via short workshops and supplemented by on demand resources such as videos and user guides.

Version 1

Page 21 of 36

[Insert date]

Change Management Process

3 Roles and responsibilities This section describes the main operational roles involved in the change management process, their interaction with the process and their detailed responsibilities.

3.1 Operational roles The following main roles participate in the change management process: • • • •

Process Manager Change Initiator Change Authority Change Builder/Implementer

There will also be interaction with IT and business management at various points in the process.

3.2 RACI matrix The table below clarifies the responsibilities of these roles at each step of the change management process using the RACI system, i.e.: • •

• •

R: Responsible A: Accountable

STEP

CHANGE INITIATOR

CHANGE MANAGER

C: Consulted I: Informed

CHANGE AUTHORITY

CHANGE BUILDER/ IMPLEMENTER

Create RFC

A/R

Record RFC

A/R

Review RFC

A/R

Assess and Evaluate Change

A/R

Authorise Change Build and Test

A/R

Co-ordinate Change Build and Test Authorise Change Deployment

A/R

Co-ordinate Change Deployment

A/R

Review and Close Change Record

A/R

R R

Table 2: RACI matrix

Version 1

Page 22 of 36

[Insert date]

Change Management Process

3.3 Change management process owner The responsibilities of the change management process owner are: • • • • • • • • • • • • • • •

Sponsoring, designing and change managing the process and its metrics Defining the process strategy Assisting with process design Ensuring that appropriate process documentation is available and current Defining appropriate policies and standards to be employed throughout the process Periodically auditing the process to ensure compliance to policy and standards Periodically reviewing the process strategy to ensure that it is still appropriate and change as required Communicating process information or changes as appropriate to ensure awareness Providing process resources to support activities required throughout the service lifecycle Ensuring process technicians have the required knowledge and the required technical and business understanding to deliver the process and understand their role in the process Reviewing opportunities for process enhancements and for improving the efficiency and effectiveness of the process Addressing issues with the running of the process Identifying improvement opportunities for inclusion in the CSI register Making improvements to the process Working with other process owners to ensure there is an integrated approach to change management

3.4 Change management process manager (change manager) The responsibilities of the change management process manager are: • • • • • • • • •

Working with the process owner to plan and co-ordinate all process activities Ensuring all activities are carried out as required throughout the service lifecycle Appointing people to the required roles Managing resources assigned to the process Working with service owners and other process managers to ensure the smooth running of services Monitoring and reporting on process performance Identifying improvement opportunities for inclusion in the CSI register Working with the CSI manager and process owner to review and prioritise improvements in the CSI register Making improvements to the process implementation

Version 1

Page 23 of 36

[Insert date]

Change Management Process • • • • • • • •

Planning and managing support for change management tools and processes Coordinating interfaces between change management and other service management processes Driving the efficiency and effectiveness of the change management process Producing management information Managing the work of change management staff Monitoring the effectiveness of change management and making recommendations for improvement Developing and maintaining the change management systems Developing and maintaining the change management process and procedures

3.5 Change initiator The responsibilities of the change initiator are: • • • • • • •

Identifying the need for a change to be made Defining the requirements for the change Assessing the potential business benefit of the change Submitting the RFC to the process Providing any required clarification about the RFC Reviewing the effects of the implemented change against requirements Providing input to the change review

3.6 Change authority The responsibilities of the members of the change authority are: • • • • • • •

Assessment of RFCs from the viewpoint of their area of expertise/ responsibility Authorisation of RFCs for build/test Rejection of RFCs that represent unacceptable risk or impact Assessment of RFCs for deployment Authorisation of RFCs for deployment Rejection (or delay) of RFCs for which deployment is unacceptable Input to the post-implementation review of changes

Version 1

Page 24 of 36

[Insert date]

Change Management Process

3.7 Change builder/implementer The responsibilities of the change builder/implementer are: • • • • • • • • •

Build and test of changes according to the requirements defined in the RFC and applicable organizational and technical standards Feedback to the change manager regarding the progress and status of changes they are dealing with Creation of implementation and back-out plans and procedures Creation of post-implementation test plans and scripts Implementation of changes into the live environment Testing of changes in the live environment Back-out of failed changes Reporting of results of changes to the change manager Participation in the change review

Version 1

Page 25 of 36

[Insert date]

Change Management Process

4 Associated documentation The following documentation is relevant to the change management process and should be read in conjunction with it:

DOCUMENT

REFERENCE

VERSION

LOCATION

ITIL Service Transition Book

ISBN number

2011

[Network drive location]

Change Management Policy

ITILST0202

V1.0 Final

[Network drive location]

Problem Management Process

ITILSO0401

V1.0 Final

[Network drive location]

V1.0 Final

[Network drive location]

V1.0 Final

[Network drive location]

Configuration Management Process Incident Management Process

ITILSO0301

Change management system user guide

[Network drive location]

Change management system admin guide

[Network drive location]

Table 3: Associated documentation

In the event that any of these items is not available please contact the change manager.

Version 1

Page 26 of 36

[Insert date]

Change Management Process

5 Interfaces and dependencies The change management process has a number of interfaces and dependencies with other processes within service management and the business. These are outlined here and are described in further detail in the relevant procedural documentation.

5.1 Other service management processes ITIL LIFECYCLE STAGE

PROCESS

INPUTS TO CHANGE MANAGEMENT FROM THE NAMED PROCESS

OUTPUTS FROM CHANGE MANAGEMENT TO THE NAMED PROCESS

Service Strategy

Business Relationship Management

RFCs resulting from discussions with the business

Completed RFCs

Financial Management for IT Services

Budgets for changes

Cost of change information

Service Portfolio Management

Change proposals

New or changed services to be added to the portfolio

Information Security Management

Changes required to implement or improve security controls to address risk

Implications of changes on information security controls

IT Service Continuity Management

Changes required to improve service continuity

Implications of changes on service continuity plans

Change Evaluation

Completed change evaluations

Requests for change evaluations

Release and Deployment Management

Completed deployments; release policy and current release plans

Changes to incorporate into releases

Service Asset and Configuration Management

Details of configuration items and relationships between them

Updated configuration items

Service Validation and Testing

Test plans and results

Requirements for testing

Transition Planning and Support

Implementation plans

Status updates

Incident Management

Incidents requiring a change

Incidents to be closed as a result of a successful change

Problem Management

Problems requiring a change to resolve

Problems to be closed as a result of a successful change

Request Fulfilment

Information regarding standard changes implemented as service requests

Definitions of standard changes

Service Design

Service Transition

Service Operation

Version 1

Page 27 of 36

[Insert date]

Change Management Process

ITIL LIFECYCLE STAGE

PROCESS

INPUTS TO CHANGE MANAGEMENT FROM THE NAMED PROCESS

OUTPUTS FROM CHANGE MANAGEMENT TO THE NAMED PROCESS

Continual Service Improvement

7 Step Improvement Process

Process improvements

Details of improvements made; lessons learned from change reviews

Table 4: Interfaces with other service management processes

5.2 Business processes [Business processes will obviously be numerous and highly industry- and organizationspecific. We therefore recommend that you only address those that are closely linked to the process in question here.]

BUSINESS AREA

BUSINESS PROCESS

INPUTS TO CHANGE MANAGEMENT FROM THE NAMED PROCESS

OUTPUTS FROM CHANGE MANAGEMENT TO THE NAMED PROCESS

Human Resources Finance Sales and Marketing Production/Operations Legal and Compliance Research and Development Distribution and Logistics Customer Services Purchasing Public Relations Administration [Insert further business processes here] Table 5: Interfaces with business processes

Version 1

Page 28 of 36

[Insert date]

Change Management Process

6 Process measurements and metrics In order to determine whether the change management process is working effectively and achieving what we want it to achieve, we must first define our critical success factors and identify how we will determine if they are being fulfilled.

6.1 Critical success factors The following factors are defined as critical to the success of the change management process:

REF

CRITICAL SUCCESS FACTOR

CSF1

Changes to areas within scope are controlled through the change management process

CSF2

Changes are implemented successfully with managed risk

CSF3

Business benefits of changes are realised

CSF4

Accuracy of configuration management records is maintained

Table 6: Critical success factors

Achievement of these critical success factors will be measured via the use of relevant Key Performance Indicators (KPIs).

6.2 Key performance indicators The following KPIs will be used on a regular basis to evidence the successful operation of the change management process:

CSF REF

KPI REF

KEY PERFORMANCE INDICATOR

CSF1

KPI1.1

Number of changes per month that are known to have circumvented the change management process

KPI1.2

Number of emergency changes raised

KPI1.3

Percentage of changes that are classified as emergencies

KPI2.1

Percentage changes implemented successfully on first attempt

KPI2.2

Percentage of changes backed out

KPI2.3

Size of change backlog

KPI3.1

Percentage of changes for which the expected benefits are realised

CSF2

CSF3

Version 1

Page 29 of 36

[Insert date]

Change Management Process

CSF REF

CSF4

KPI REF

KEY PERFORMANCE INDICATOR

KPI3.2

Customer satisfaction scores for change management

KPI4.1

Percentage of configuration items found to have incorrect information when audited

Table 7: Key performance indicators

6.3 Process reviews and audits Reviews will be carried out by the process owner in conjunction with the process manager on a three-monthly basis to assess whether the change management process is operating effectively and delivering the desired results. These reviews will have the following as input: • • • • • • •

Follow-up action list from previous reviews Relevant changes and developments within the business and IT KPI reports from the previous period Details of all complaints logged during the period Internal and external audit reports Feedback from users and customers Identified opportunities for improvement

Each review will be documented by the process owner and actions arising agreed and published. Audits will be carried out on an annual basis by the internal auditing department. The scope and timing of the audit will be agreed in advance. Recommendations from the audit will be published and actions discussed and agreed with the process owner. All actions will be followed up by the internal auditor within the agreed timescales for each action.

Version 1

Page 30 of 36

[Insert date]

Change Management Process

7 Process reporting It is important that regular reports are produced for two main reasons: 1. To help to assess whether the change management process is meeting its critical success factors (see section 6.1 above) 2. To assist the change manager in the day-to-day management of the change management process and its resourcing These two purposes may require different views of the information available and will need to be produced at varying frequencies for differing audiences. The format of the reports produced will also be subject to regular review and amendment as requirements become clearer and the available reporting technology within the business matures. What must be avoided is the continued production of reports that are not read and serve no purpose. It is up to the process owner, in consultation with the process manager, to ensure that all reporting remains focussed and relevant. The following tables show the reports that will be produced together with their purpose, method of production, data source, audience and frequency. Some of the reports listed will be used for multiple purposes.

Version 1

Page 31 of 36

[Insert date]

Change Management Process

7.1 Process reports The following reports are produced by the process manager and are intended to help the process owner assess whether the CSFs for change management are being met.

REF

REPORT TITLE

DESCRIPTION

METHOD OF PRODUCTION

DATA SOURCE

FREQ

AUDIENCE

CSFR1

Unauthorised Changes

Number of changes per month that are known to have circumvented the change management process

Records form auditing tools; unauthorised changes found due to service issues

Audit tools; service and incident reviews

Monthly

Process Owner

CSFR2

Emergency Changes

Number of emergency changes raised

Report from change management system

Change management database

Monthly

Process Owner

CSFR3

Percentage Emergency

Percentage of changes that are classified as emergencies

Report from change management system

Change management database

Monthly

Process Owner

CSFR4

Successful Changes

Percentage changes implemented successfully on first attempt

Report from change management system

Change management database

Monthly

Process Owner

CSFR5

Backed Out Changes

Percentage of changes backed out

Report from change management system

Change management database

Monthly

Process Owner

CSFR6

Change Backlog

Size of change backlog

Report from change management system

Change management database

Monthly

Process Owner

CSFR7

Benefits Realised

Percentage of changes for which the expected benefits are realised

Report from change management system

Change management database

Monthly

Process Owner

CSFR8

Customer Satisfaction

Customer satisfaction scores for change management

Customer satisfaction survey

Survey results database

SixMonthly

Process Owner

CSFR9

Incorrect CIs

Percentage of configuration items found to have incorrect information when audited

Extract from audit report

Configuration Status reports

Quarterly

Process Owner

Version 1

Page 32 of 36

[Insert date]

Change Management Process

REF

REPORT TITLE

CSFR13

[Insert further reports]

DESCRIPTION

METHOD OF PRODUCTION

DATA SOURCE

FREQ

AUDIENCE

Table 8: Process reports

7.2 Operational reports The following reports are to provide further ongoing operational information to the process manager. They are in addition to the relevant process reports described above.

REF

REPORT TITLE

DESCRIPTION

METHOD OF PRODUCTION

DATA SOURCE

FREQ

AUDIENCE

OPR1

Changes Raised

Number of changes raised by type by month

Report from change management system

Change management database

Monthly

Change Manager

OPR2

Changes Closed

Number of changes closed by type by month

Report from change management system

Change management database

Monthly

Change Manager

OPR3

Time to Close

Average time to close by type by month

Report from change management system

Change management database

Monthly

Change Manager

[Insert further reports] Table 9: Operational reports

Version 1

Page 33 of 36

[Insert date]

Change Management Process

8 Glossary, abbreviations and references 8.1 Glossary For a full list of terms used and their definitions within ITIL, please refer to the back of any of the books in the ITIL Lifecycle Suite 2011. The following subset of terms is specifically relevant to this document:

TERM

MEANING

Assessment

Inspection and analysis to check whether a standard or set of guidelines is being followed, that records are accurate, or that efficiency or effectiveness targets are being met

Back-out

An activity that restores a service or other configuration item to a previous baseline. Back-out is used as a form of remediation when a change or release is not successful

Build

The activity of assembling a number of configuration items to create part of an IT service.

ITILST0202 Change Management Process

Articles inside

Copyright notice

Press F9 on the keyboard to update all fields

1 Introduction

2 Change management process

Press Ctrl A on the keyboard to select all text in the document (or use Select, Select