Change Management Process
Implementation Guidance (this section must be removed from final version of the 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.
Toolkit Version Number ITIL® 2011 Service Transition Process and Policy Pack Version 1 ©CertiKit 2015.
Acknowledgements ITIL is a registered trade mark of AXELOS Limited.
Copyright notice Except for any third party works included in this document, as identified in this Version 1
Page 1 of 35
Insert date Powered by CertiKit
Change Management Process
document, this document has been authored by CertiKit, and is Š copyright CertiKit except as stated below. CertiKit is a trading name of Public I.T. Limited, a company registered in England and Wales with company number 6432088 and registered office at 5 Falcons Rise, Belper, Derbyshire, DE56 0QN.
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 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 2 of 35
Insert date Powered by CertiKit
Change Management Process
Change Management Process
Document Ref. Version: Dated: Document Author: Document Owner:
Version 1
Page 3 of 35
ITILST0202 1 Insert date
Insert date Powered by CertiKit
Change Management Process
Revision History Version Date
Revision Author
Summary of Changes
Distribution Name
Title
Approval Name
Version 1
Position
Signature
Page 4 of 35
Date
Insert date Powered by CertiKit
Change Management Process
Contents LIST OF FIGURES .............................................................................................................................................. 6 LIST OF TABLES ................................................................................................................................................ 6 1
INTRODUCTION ....................................................................................................................................... 7 1.1 1.2 1.3 1.4
2
VISION STATEMENT .................................................................................................................................. 7 PURPOSE ................................................................................................................................................... 7 OBJECTIVES .............................................................................................................................................. 8 SCOPE ....................................................................................................................................................... 8
CHANGE MANAGEMENT PROCESS ................................................................................................... 9 2.1 OVERVIEW AND PROCESS DIAGRAM ......................................................................................................... 9 2.2 PROCESS TRIGGERS ................................................................................................................................. 11 2.3 PROCESS INPUTS ..................................................................................................................................... 11 2.4 PROCESS ACTIVITIES ............................................................................................................................... 11 2.4.1 Create RFC ................................................................................................................................... 11 2.4.2 Record RFC .................................................................................................................................. 12 2.4.3 Review RFC .................................................................................................................................. 12 2.4.4 Assess and Evaluate Change ........................................................................................................ 12 2.4.5 Authorise Change Build and Test ................................................................................................. 13 2.4.6 Co-ordinate Change Build and Test ............................................................................................. 14 2.4.7 Authorise Change Deployment ..................................................................................................... 14 2.4.8 Co-ordinate Change Deployment ................................................................................................. 14 2.4.9 Review and Close Change Record ................................................................................................ 15 2.5 EMERGENCY CHANGES ........................................................................................................................... 15 2.6 PROCESS OUTPUTS .................................................................................................................................. 16 2.7 CHANGE MANAGEMENT TOOLS .............................................................................................................. 16 2.7.1 Change Management System ........................................................................................................ 17 2.7.2 Configuration Management System .............................................................................................. 17 2.8 COMMUNICATION AND TRAINING ........................................................................................................... 17 2.8.1 Communication with Change Initiators ........................................................................................ 17 2.8.2 Communication with Change Authorities ..................................................................................... 17 2.8.3 Communication with IT Teams ..................................................................................................... 18 2.8.4 Communication with Projects ....................................................................................................... 18 2.8.5 Process Performance .................................................................................................................... 18 2.8.6 Communication with Incident and Problem Management ............................................................ 18 2.8.7 Training for Change Management................................................................................................ 19
3
ROLES AND RESPONSIBILITIES ....................................................................................................... 20 3.1 3.2 3.3 3.4 3.5 3.6 3.7
OPERATIONAL ROLES ............................................................................................................................. 20 RACI MATRIX ........................................................................................................................................ 20 CHANGE MANAGEMENT PROCESS OWNER ............................................................................................. 21 CHANGE MANAGEMENT PROCESS MANAGER (CHANGE MANAGER) ...................................................... 21 CHANGE INITIATOR ................................................................................................................................. 22 CHANGE AUTHORITY .............................................................................................................................. 22 CHANGE BUILDER/IMPLEMENTER ........................................................................................................... 22
4
ASSOCIATED DOCUMENTATION ..................................................................................................... 24
5
INTERFACES AND DEPENDENCIES ................................................................................................. 25 5.1 5.2
6
OTHER SERVICE MANAGEMENT PROCESSES ........................................................................................... 25 BUSINESS PROCESSES ............................................................................................................................. 26
PROCESS MEASUREMENTS AND METRICS .................................................................................. 28 6.1 6.2 6.3
CRITICAL SUCCESS FACTORS .................................................................................................................. 28 KEY PERFORMANCE INDICATORS............................................................................................................ 28 PROCESS REVIEWS AND AUDITS ............................................................................................................. 29
Version 1
Page 5 of 35
Insert date Powered by CertiKit
Change Management Process
7
PROCESS REPORTING ......................................................................................................................... 30 7.1 7.2
8
PROCESS REPORTS .................................................................................................................................. 31 OPERATIONAL REPORTS .......................................................................................................................... 32
GLOSSARY, ABBREVIATIONS AND REFERENCES ...................................................................... 33 8.1 8.2 8.3
GLOSSARY .............................................................................................................................................. 33 ABBREVIATIONS...................................................................................................................................... 35 REFERENCES ........................................................................................................................................... 35
List of Figures FIGURE 1 - CHANGE MANAGEMENT PROCESS ....................................................................................................... 10
List of Tables TABLE 1 - LEVELS OF CHANGE REVIEW AND AUTHORISATION ............................................................................. 13 TABLE 2 - RACI MATRIX ...................................................................................................................................... 20 TABLE 3 - ASSOCIATED DOCUMENTATION ............................................................................................................ 24 TABLE 4 - INTERFACES WITH OTHER SERVICE MANAGEMENT PROCESSES.............................................................. 26 TABLE 5 - INTERFACES WITH BUSINESS PROCESSES ............................................................................................... 27 TABLE 6 - CRITICAL SUCCESS FACTORS ................................................................................................................. 28 TABLE 7 - KEY PERFORMANCE INDICATORS .......................................................................................................... 28 TABLE 8 - PROCESS REPORTS................................................................................................................................. 32 TABLE 9 - OPERATIONAL REPORTS ........................................................................................................................ 32 TABLE 10 - GLOSSARY OF RELEVANT TERMS ....................................................................................................... 35
Version 1
Page 6 of 35
Insert date Powered by CertiKit
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®1 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)
1
ITIL® is a registered trade mark of AXELOS Limited.
Version 1
Page 7 of 35
Insert date Powered by CertiKit
Change Management Process
1.3
Objectives
The objectives of the change management process are to:
1.4
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 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 8 of 35
Insert date Powered by CertiKit
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 9 of 35
Insert date Powered by CertiKit
Change Management Process
Role Create RFC Change initiator
Record RFC
Change proposal (optional)
Change management Requested
Activities assigned to the role “Change management” may be carried out by a change practitioner, a change authority or the change management process owner, depending on organisational design
Review RFC Change management Ready for evaluation Assess and evaluate change Change management
Workflows Ready for decision Authorise change Build and test
Change authority Update information in CMS
Authorised Co-ordinate change build and test* *Activities to plan, create and deploy releases are part of the release and deployment management process
Change management
Workflows Created Authorise change deployment
Change authority Scheduled
Co-ordinate change deployment* Change management Workflows Implemented Review and close change record
Change management Change authority Change initiator
Closed
Figure 1 - Change Management Process
(Source: “ITIL Service Transition Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS)
Version 1
Page 10 of 35
Insert date Powered by CertiKit
Change Management Process
2.2
Process Triggers
The change management process is initiated as a result of one or more of the following triggers:
2.3
An RFC is submitted via one of the available channels A change proposal is raised as part of the service portfolio management process 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:
2.4
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 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 11 of 35
Insert date Powered by CertiKit
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: 1. Who raised the change? 2. What is the reason for the change?
Version 1
Page 12 of 35
Insert date Powered by CertiKit
Change Management Process
3. 4. 5. 6. 7.
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 Level 1 Level 2
Change Authority Business Executive Board IT Steering Group
Level 3 Level 4 Level 5
CAB or ECAB Change Manager Local authorisation
Level of Risk/impact High cost and/or risk Multiple services or organizational divisions Local service or organization Low risk 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. 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
Version 1
Page 13 of 35
Insert date Powered by CertiKit
Change Management Process
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 reauthorisation for deployment. 2.4.8
Co-ordinate Change Deployment
For releases (i.e. groups of change implemented together), the implementation will be co-ordinated 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 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.
Version 1
Page 14 of 35
Insert date Powered by CertiKit
Change Management Process
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. 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:
Version 1
Page 15 of 35
Insert date Powered by CertiKit
Change Management Process
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: 2.7
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 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 16 of 35
Insert date Powered by CertiKit
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 predefined 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. 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
Version 1
Page 17 of 35
Insert date Powered by CertiKit
Change Management Process
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. 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
Version 1
Page 18 of 35
Insert date Powered by CertiKit
Change Management Process
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 19 of 35
Insert date Powered by CertiKit
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
Role: Step Create RFC Record RFC Review RFC Assess and Evaluate Change Authorise Change Build and Test Co-ordinate Change Build and Test Authorise Change Deployment Co-ordinate Change Deployment Review and Close Change Record
C= Consulted
I= Informed
Change Initiator A/R C C C
Change Manager
Change Authority
Change Builder/ Implementer
A/R A/R A/R
I R
I
A/R
R
I
A/R
I
R
I
A/R
R
I
I
A/R
C
A/R
R R
C
Table 2 - RACI Matrix
Version 1
Page 20 of 35
Insert date Powered by CertiKit
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
(Source: “ITIL Service Transition Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS) 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
Version 1
Page 21 of 35
Insert date Powered by CertiKit
Change Management Process
Making improvements to the process implementation 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
(Source: “ITIL Service Transition Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS) 3.5
Change Initiator
The responsibilities of the change initiator are: 3.6
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 Change Authority
The responsibilities of the members of the change authority are: 3.7
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 Change Builder/Implementer
The responsibilities of the change builder/implementer are:
Version 1
Page 22 of 35
Insert date Powered by CertiKit
Change Management Process
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 23 of 35
Insert date Powered by CertiKit
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 ITIL Service Transition Book Change Management Policy Problem Management Process Configuration Management Process Incident Management Process Change management system user guide Change management system admin guide
Reference ISBN number
Version 2011
ITILST0202
V1.0 Final
ITILSO0401
V1.0 Final V1.0 Final
ITILSO0301
V1.0 Final
Location [Network drive location] [Network drive location] [Network drive location] [Network drive location] [Network drive location] [Network drive location] [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 24 of 35
Insert date Powered by CertiKit
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 Service Strategy
Service Design
Service Transition
Service Operation Version 1
Process Business Relationship Management Financial Management for IT Services Service Portfolio Management Information Security Management
Inputs to change management from the named process RFCs resulting from discussions with the business Budgets for changes
Outputs from change management to the named process Completed RFCs
Change proposals
New or changed services to be added to the portfolio Implications of changes on information security controls
Changes required to implement or improve security controls to address risk IT Service Continuity Changes required to improve service Management continuity Change Evaluation Completed change evaluations Release and Deployment Completed deployments; release Management policy and current release plans Service Asset and Details of configuration items and Configuration Management relationships between them Service Validation and Test plans and results Testing Transition Planning and Implementation plans Support Incident Management Incidents requiring a change Page 25 of 35
Cost of change information
Implications of changes on service continuity plans Requests for change evaluations Changes to incorporate into releases Updated configuration items Requirements for testing Status updates Incidents to be closed as a result of a Insert date Powered by CertiKit
Change Management Process
ITIL Lifecycle Stage
Process
Inputs to change management from the named process
Problem Management
Problems requiring a change to resolve Information regarding standard changes implemented as service requests Process improvements
Request Fulfilment
Continual Service Improvement
7 Step Improvement Process
Outputs from change management to the named process successful change Problems to be closed as a result of a successful change Definitions of standard changes
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 organization-specific. 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 Version 1
Page 26 of 35
Insert date Powered by CertiKit
Change Management Process
Business Area
Business Process
Inputs to change management from the named process
Outputs from change management to the named process
Public Relations Administration [Insert further business processes here] Table 5 - Interfaces with business processes
Version 1
Page 27 of 35
Insert date Powered by CertiKit
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. CSF1 CSF2 CSF3 CSF4
Critical Success Factor Changes to areas within scope are controlled through the change management process Changes are implemented successfully with managed risk Business benefits of changes are realised 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: CSI Ref. CSF1
KPI Ref. KPI1.1
CSF3
KPI1.2 KPI1.3 KPI2.1 KPI2.2 KPI2.3 KPI3.1
CSF4
KPI3.2 KPI4.1
CSF2
Key Performance Indicator Number of changes per month that are known to have circumvented the change management process Number of emergency changes raised Percentage of changes that are classified as emergencies Percentage changes implemented successfully on first attempt Percentage of changes backed out Size of change backlog Percentage of changes for which the expected benefits are realised Customer satisfaction scores for change management Percentage of configuration items found to have incorrect information when audited
Table 7 - Key performance indicators
Version 1
Page 28 of 35
Insert date Powered by CertiKit
Change Management Process
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 29 of 35
Insert date Powered by CertiKit
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 30 of 35
Insert date Powered by CertiKit
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. CSFR1
Report Title Unauthorised Changes
Description Number of changes per month that are known to have circumvented the change management process Number of emergency changes raised
Method of Production Records form auditing tools; unauthorised changes found due to service issues
Data Source Audit tools; service and incident reviews
Frequency Audience Monthly Process Owner
CSFR2
Emergency Changes
Report from change management system
Monthly
Process Owner
Report from change management system
Monthly
Process Owner
Monthly
Process Owner
Backed Out Changes
Percentage of changes that are classified as emergencies Percentage changes implemented successfully on first attempt Percentage of changes backed out
Monthly
Process Owner
CSFR6
Change Backlog
Size of change backlog
Report from change management system
Monthly
Process Owner
CSFR7
Benefits Realised
Report from change management system
Monthly
Process Owner
CSFR8
Customer Satisfaction
Percentage of changes for which the expected benefits are realised Customer satisfaction scores for change management
Change management database Change management database Change management database Change management database Change management database Change management database Survey results database
CSFR3
Percentage Emergency
CSFR4
Successful Changes
CSFR5
SixMonthly
Process Owner
Version 1
Report from change management system Report from change management system
Customer satisfaction survey Page 31 of 35
Insert date Powered by CertiKit
Change Management Process
Ref. CSFR9
Report Title Incorrect CIs
Description Percentage of configuration items found to have incorrect information when audited
Method of Production Extract from audit report
Data Source Configuration Status reports
Frequency Audience Quarterly Process Owner
CSFR13 [Insert further reports] 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. OPR1
Report Title Changes Raised
Description Number of changes raised by type by month
Method of Production Report from change management system
OPR2
Changes Closed
Number of changes closed by type by month
Report from change management system
OPR3
Time to Close
Average time to close by type by month
Report from change management system
Data Source Change management database Change management database Change management database
Frequency Audience Monthly Change Manager Monthly
Change Manager
Monthly
Change Manager
[Insert further reports] Table 9 - Operational reports
Version 1
Page 32 of 35
Insert date Powered by CertiKit
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 assessment
back-out
build category change Change Advisory Board (CAB) change history change management change model change proposal
change record change schedule
closed configuration item configuration management system continual service improvement
Version 1
Meaning 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 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 The activity of assembling a number of configuration items to create part of an IT service. A named group of things that have something in common The addition, modification or removal of anything that could have an effect on IT services A group of people that support the assessment, prioritisation, authorisation and scheduling of changes Information about all changes made to a configuration item during its life The process responsible for controlling the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services A repeatable way of dealing with a particular category of change A document that includes a high level description of a potential service introduction or significant change, along with a corresponding business case and an expected implementation schedule A record containing the details of a change A document that lists all authorised changes and their planned implementation dates, as well as the estimated dates of longerterm changes The final status in the lifecycle of an incident, problem, change etc. When the status is closed, no further action is taken Any component or other service asset that needs to be managed in order to deliver an IT service A set of tools, data and information that is used to support service asset and configuration management A stage in the lifecycle of a service. Continual service improvement ensures that services are aligned with changing business needs by identifying and implementing improvements
Page 33 of 35
Insert date Powered by CertiKit
Change Management Process
Term customer
deployment
emergency change emergency CAB escalation financial management impact incident incident management IT service
key performance indicator model
normal change PostImplementation Review (PIR) priority problem release remediation Request For Change (RFC) service desk service level agreement urgency
Version 1
Meaning to IT services that support business processes Someone who buys goods or services. The customer of an IT service provider is the person or group who defines and agrees the service level targets The activity responsible for the movement of new or changed hardware, software, documentation, process etc. to the live environment A change that must be introduced as soon as possible – for example to resolve a major incident or implement a security patch A subgroup of the Change Advisory Board that makes decisions about emergency changes An activity that obtains additional resources when these are needed to meet service level targets or customer expectations. A generic term used to describe the function and processes responsible for managing an organization’s budgeting, accounting and charging requirements A measure of the effect of an incident, problem or change on business processes An unplanned interruption to an IT service or reduction in the quality of an IT service The process responsible for managing the lifecycle of all incidents A service provided by an IT service provider. An IT service is made up of a combination of information technology, people and processes A metric that is used to help manage an IT service, process, plan, project or other activity A representation of a system, process, IT service, configuration item etc. that is used to help understand or predict future behaviour A change that is not an emergency or a standard change A review that take place after a change or a project has been implemented A category used to identify the relative importance of an incident, problem or change A cause of one or more incidents One or more changes to an IT service that are built, tested and deployed together Actions taken to recover after a failed change or release A formal proposal for a change to be made The single point of contact between the service provider and the users An agreement between an IT service provider and a customer A measure of how long it will be until an incident, problem or
Page 34 of 35
Insert date Powered by CertiKit
Change Management Process
Term
Meaning change has a significant impact on the business A person who uses the IT service on a day-to-day basis. Users are distinct from customers, as some customers do not use the IT service directly A description of what the organization intends to become in the future
user
vision
Table 10 - Glossary of Relevant Terms
(Based on “ITIL Service Transition Book 2011”. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS) 8.2
Abbreviations
The following abbreviations are used in this document: CAB CI CMS CSF CSI ECAB IT ITIL RFC SKMS 8.3
Change Advisory Board Configuration Item Configuration Management System Critical Success Factor Continual Service Improvement Emergency Change Advisory Board Information Technology Information Technology Infrastructure Library Request for Change Service Knowledge Management System
References
The following sources have been used in the creation of this process document and should be consulted for more information on particular aspects of it:
ITIL Service Transition Book 2011. Copyright © AXELOS Limited 2011 [Organization Name] IT organization structure, published dd/mm/yy [Organization Name] Business Strategy yyyy-yyyy [Organization Name] IT Strategy yyyy-yyyy [Organization Name] IT Service Management Strategy yyyy-yyyy
Version 1
Page 35 of 35
Insert date Powered by CertiKit