by Amitabh Biswas
Implementing ITIL Change Management process -What is it?
The ITIL Change Management, one of the key areas of IT Service Management, is the sole focus of this blog. Before discussing ITIL Change Management process, let us first explore what ITIL stands for. The ITIL, popularly known as IT Infrastructure Library, came to limelight in 1989 as a collection of guidelines and principles covering the salient practices within IT Service Management. Interestingly, the ITIL framework was born in the cradle of bureaucracy - at the Central Computer and Telecommunications Agency (CCTA), an agency of the UK Government. Implementing change management, in simple words, covers the management methods of IT change control encompassing the change orders or change requests for the configuration items (CIs).
ITIL Change Management -what is the focus?
The prime goals of ITIL Change Management (often alternatively referred to as ITIL Change Control) are to (i) effectively respond to customer’s changing business needs while maximizing value, minimizing incidents, disruption and re-work and (ii) respond to the business and IT requests for change that will align the services with the business needs. The IT Change Control process ensures that the standardized methodologies are in action for efficient and effective implementation of change order or change requests in information technology with minimum adverse impacts upon service availability and quality. The pivotal ITIL concept, that propels all its IT service management processes, is the recognition of IT organization as a service provider - or in other words- all IT initiatives are ‘services’ and their infallible focus points are the ‘customers’.
Over time, since 1989 the ITIL concepts, policies and guidelines progressed through its stages of maturity. In May 2007, the version 3 of ITIL, known as ITIL v3, was published. It comprised 26 processes and functions, assimilated under 5 volumes, arranged around the concept of service lifecycle structure. Apart from limiting itself into improved concepts of the framework and standards and emphasizing the service delivery model, the ITIL v3 also popularized the concepts of IT service Lifecycle with a strong focus on the IT strategy and its business outcomes. In other words ITIL v3 further elevated the status of IT department from a service provider to that of a strategic partner.
ITIL v3 not only discusses change as the process mechanism, but adds also a dimension of value judgment – a perspective of business outcome, of adding value to business. The ITIL Change Control/ Management process recognizes that reliability and business continuity are crucial for survival and success of the enterprise. The change management process helps to add value to the business by providing a number of advantages like, responding and prioritizing the change requests, executing the requests within agreed time- frame to meet the service level objectives and expectations, enabling the enterprise meet regulatory, contractual and governance change-requirements, assessing the risks attached with the transition of services, and monitoring changes through the service life cycle and tracking it down to the level of assets.
The ITIL Change Management, one of the key areas of IT Service Management, is the sole focus of this blog. Before discussing ITIL Change Management process, let us first explore what ITIL stands for. The ITIL, popularly known as IT Infrastructure Library, came to limelight in 1989 as a collection of guidelines and principles covering the salient practices within IT Service Management. Interestingly, the ITIL framework was born in the cradle of bureaucracy - at the Central Computer and Telecommunications Agency (CCTA), an agency of the UK Government. Implementing change management, in simple words, covers the management methods of IT change control encompassing the change orders or change requests for the configuration items (CIs).
ITIL Change Management -what is the focus?
The prime goals of ITIL Change Management (often alternatively referred to as ITIL Change Control) are to (i) effectively respond to customer’s changing business needs while maximizing value, minimizing incidents, disruption and re-work and (ii) respond to the business and IT requests for change that will align the services with the business needs. The IT Change Control process ensures that the standardized methodologies are in action for efficient and effective implementation of change order or change requests in information technology with minimum adverse impacts upon service availability and quality. The pivotal ITIL concept, that propels all its IT service management processes, is the recognition of IT organization as a service provider - or in other words- all IT initiatives are ‘services’ and their infallible focus points are the ‘customers’.
Over time, since 1989 the ITIL concepts, policies and guidelines progressed through its stages of maturity. In May 2007, the version 3 of ITIL, known as ITIL v3, was published. It comprised 26 processes and functions, assimilated under 5 volumes, arranged around the concept of service lifecycle structure. Apart from limiting itself into improved concepts of the framework and standards and emphasizing the service delivery model, the ITIL v3 also popularized the concepts of IT service Lifecycle with a strong focus on the IT strategy and its business outcomes. In other words ITIL v3 further elevated the status of IT department from a service provider to that of a strategic partner.
 |
| Check ITSM-ITIL Resource Catalog |
ITIL Change Management- What is a Change?
ITIL Change Management - What are the inputs?
One relevant point to discuss is : what inputs are considered when assessing changes through the ITIL Change Management process.The salient inputs are namely - (i) The enterprise-level change policy or the change strategy or the guidelines adopted, (ii) RFCs , in other words, the formal requests for change which describes contents and the components of the change asked for, (iii) The Change Proposals - the detailed change procedure to follow , with specific context and background, based on the adopted change model, (iv)The service management plan to manage the life-cycle of the change phases including execution, release,deployment, QA,post-implementation evaluation and remediation if risks surface, (v) The affected services and/or the CIs, (vi) The Change Management documentations like change schedule (with all approved changes and listed imple mentation schedules) and projtected service outage documents which discuss the effect of possible service outage in executing planned changes, maintendance actions recommended, QA plans and agreed SLAs.
The Change outputs include (i) the RFCs , either approved or rejected, (ii) Resulted cahnges to the services or the configuaration items, (iii) Updated Change Schedules and published Project Service Outages (iv) Approved Change Execution Plan, (v) Change Documents and Records ( digitized or manually maintained and preserved) , (vi)Management Reports to analyse and review.
Change Management- What change does it track?
As you all probably know, ITIL talks about three types of change request or change order – normal, standard and emergency changes. The ITIL Change Management process embraces a long range of workflow typically comprised of drafting and registering/ recording the Change Request (usually known as RFC), reviewing the change, assessing the risk and impact of proposed change, its approval cycles with change authorization, planning, coordinating and implementing the change, communicating /reporting the stake-holders, performing the post-implementation review and, finally, closing of the RFC. The Change Advisory Board (CAB) plays the important role in ITIL model as the nodal authorization body, which examines the change proposals, approves and authorizes the change. For emergency change, ITIL v3 recommends Emergency Change Advisory Board (ECAB), a slimmer authorization body for quick emergency assessment and decision.
As you all probably know, ITIL talks about three types of change request or change order – normal, standard and emergency changes. The ITIL Change Management process embraces a long range of workflow typically comprised of drafting and registering/ recording the Change Request (usually known as RFC), reviewing the change, assessing the risk and impact of proposed change, its approval cycles with change authorization, planning, coordinating and implementing the change, communicating /reporting the stake-holders, performing the post-implementation review and, finally, closing of the RFC. The Change Advisory Board (CAB) plays the important role in ITIL model as the nodal authorization body, which examines the change proposals, approves and authorizes the change. For emergency change, ITIL v3 recommends Emergency Change Advisory Board (ECAB), a slimmer authorization body for quick emergency assessment and decision.
ITIL Change Management - the 7Rs of Change
ITIL change management recommendations emphasize the activity of assessing and evaluating the change requests or change orders. During change assessment, some generic questions, popularly known as 7 Rs of change management, play critical role in judging its potential impact on service assets and configurations. It includes two ‘who’s – who raised the change request/change order and who is responsible. And five ‘what’s – what are the reason, return expected from change request, risks involved, resources required and relationship with other change order or change request (either in pipeline or executed).
It is necessary to bear in mind that ITIL Change Control methodologies cannot effectively work in isolation and is a part of the integrative and interactive forces of IT service management. The ITIL Change Management module works seamlessly with the wide network of its partner service management components and the process interfaces like the CMDB or Asset and Configuration Management, IT Service Continuity Management, Request Management, Service Desk, Capacity and Demand Management, Release and Deployment Management and even with Knowledge Management processes.For example, an incident may lead to a change request and that change may require some CMDB change in terms of modification of some attributes of a CI; or it might alternatively bring a new CI in the CMDB database resulting in a new service enlisted on 'Service Catalog' and spawning associated access requests for that service through request management module.The new services, thus created, may also necessitate the associated SLA or SLO requirement.
Now,this does not mean that in absence of desired integration with the associated component services, it is not meaningful to start implementing ITIL change management processes. It is always necessary, for a start-up or a not-so-matured IT setup, to have a defined process-flow, procedure and guidelines for IT Change Management (in contrast with having no process at all in place), though initially it might not be hundred percent compliant with the ITIL framework.
ITIL change management recommendations emphasize the activity of assessing and evaluating the change requests or change orders. During change assessment, some generic questions, popularly known as 7 Rs of change management, play critical role in judging its potential impact on service assets and configurations. It includes two ‘who’s – who raised the change request/change order and who is responsible. And five ‘what’s – what are the reason, return expected from change request, risks involved, resources required and relationship with other change order or change request (either in pipeline or executed).
- WHO is the Requestor ?
- WHO is Responsible for the build, QA and final change implementation?
- WHAT is the Reason - what necessitates the change?
- WHAT is the expected Return from the change?
- WHAT Risk factors are associated with the change?
- WHAT Resources are required to execute the change?
- WHAT is the inter- Relationship between this change and other changes?
It is necessary to bear in mind that ITIL Change Control methodologies cannot effectively work in isolation and is a part of the integrative and interactive forces of IT service management. The ITIL Change Management module works seamlessly with the wide network of its partner service management components and the process interfaces like the CMDB or Asset and Configuration Management, IT Service Continuity Management, Request Management, Service Desk, Capacity and Demand Management, Release and Deployment Management and even with Knowledge Management processes.For example, an incident may lead to a change request and that change may require some CMDB change in terms of modification of some attributes of a CI; or it might alternatively bring a new CI in the CMDB database resulting in a new service enlisted on 'Service Catalog' and spawning associated access requests for that service through request management module.The new services, thus created, may also necessitate the associated SLA or SLO requirement.
Now,this does not mean that in absence of desired integration with the associated component services, it is not meaningful to start implementing ITIL change management processes. It is always necessary, for a start-up or a not-so-matured IT setup, to have a defined process-flow, procedure and guidelines for IT Change Management (in contrast with having no process at all in place), though initially it might not be hundred percent compliant with the ITIL framework.
ITIL Change Management process and Release Management
It is also relevant to briefly touch upon the realtionship between the ITIL change management process and Release Management. The latter encompasses the stream of activities of building/releasing changes, and is included as a component of the Service Support Set in ITIL. The dependencies between ITIL Change Management and Release Management are intricate.Release Management is proactive planning on how new or modified services,which are basically introduction of changes, are rolled out.It is a structured blueprint to bundle up the rolling out of changes in effective manner.The phased roll-out also minimises incidents affecting users and necessitates less reactive intervention.In other words, the central focus of release management is the planning and execution of the release. The release control follows the cycle of building, testing, preaparing the package and its deployment execution.The crucial aspect of release management, that distinguishes it from ITIL Change Managementproces is the range of activities that emphasize on deployment of changes - how, when and at what rate.