A partly implemented process (Part 1)

By Laurent Duenas, June 25th 2013 


Activities of Change Management


Before diving into the facts showing in what the Change Management process is partly implemented within IT organizations - and explaining the reasons why - let's have a look on what are the normal activities a Change Management process should contain, according to the ITIL V3 framework. If you already know them, you may not need to read to full page (sometimes is good to remember the best-practices) - but I suggest you to have a look on the 2 illustrations about the place of the Change Management activities within the Service Lifecycle (at the end of this page).


RFC formalization

Even if it is not an activity in itself, formalization of RFC (Request for Change) materializes change. From this action onwards, change becomes visible and can be controlled. Without RFC, changes cannot be identified before an incident linked to a random change occurs and impacts users in their business activity.


Creating an RFC is one of the basic actions mentioned at stage 1 of the maturity curve of the Change Management process. (See the chapter on implementation)


Create & review

This activity provides change traceability through a workflow tool. Once created, each request for change can be followed individually and contribute to change success throughout control operations.


When creating it, preparation, information, even risk assessment requirements can be applied. Reviewing it is the way to limit the number of insufficiently prepared and informed changes which prevent from conducting the impact evaluations specified in the process.


Classify, prioritize, assess & evaluate

In V3 this phase groups activities which used to be separated in V2:


Categorization aims at determining change category. Category is very important because it determines through which “process channel” change is to be performed. A “Channel” is nothing else but the implementation of a change model including: level of approval, design and integration principles, test requirement levels, even the deployment principles which guarantee most the implemented change. Among others, this classification makes it possible to implement change control requirement levels depending on risk, which loosens constraints. The greater the impacts on critical Services, the more demanding the controls and principles that must be applied. The lower the risk, the more flexible the controls.


Prioritization defines a priority level. However, priority level is not systematically reflected by the order in which changes are processed. (as it is commonly used in processes such as Incident Management or Problem Management). It is mainly a general indication targeting 2 types of prioritization:


►  Priority in resource allocations for change Design and Tests activities (we have a good notion here of “what must be processed first”)


►  The possibility or not, to postpone a change implementation or its release to a later date than originally scheduled, according to the business or technical impact of change. Should a time conflict occur between several changes, high priority changes are normally kept as originally scheduled, as opposed to lower priority changes which can be postponed with fewer impacts


Evaluations  Impact- Assessment


Assessment and evaluation include all activities prior to the decision to authorize change or not. These activities launch a few questions:


►  Is the requested change useful for the company business? What value does it bring? Does it really need to be done? (this is the key question, among others, to preserve efficiency through the Change Management process). This expected value will be further evaluated during test and approval stages (managed through a process not addressed in this book: Evaluation Management)


►  Does the budget to implement this change exist? With ITIL, no action is taken unless it is financed. This is a matter of good financial management


►  Can change be performed within the requested schedule? Do resources exist to carry out this change? If not, are there solutions to add resources while complying with budget? At this point, when we talk about planning, we mean all activities managed by the process (design, tests, then integration and deployment)


►  What are the impacts of this change on IT Service? What are the potential impacts, such as interruption, on business activity? And what precautions should be taken? (amongst others, test levels, back-out readiness, etc.)


►  What are the technical impacts of this change? Which other components (CIs) are impacted by this change, and should also be modified for the change to be successful? All this in order to coordinate all stakeholders without exception as early as possible and not have to involve others at the last minute (before deployment) because they would lack the initial briefing


Authorize & schedule "change build" and "test"


Before getting into the details of this approval stage, it is important to bear in mind that the Change Management process foresees two main “authorization” stages. Their number is not limited to two. It is up to each organization to specify where authorizations are needed. Two is a minimum: the first one takes place before any build activity starts. The second one, before any deployment is initiated without a minimum control. The latter takes place right in the middle of the Release and Deployment Management process.


At this stage, the approval (N° 1) (and the authorization deriving from it) formally represents the Change Manager's decision to authorize change build. They are the main authority as regards change. The decision is made with or without seeking advice from the CAB (Change Approval Board), sometimes even during a CAB session (which is often the case with organizations*).


This authorization is the signal to launch build operations, which implies that nothing happened before. It makes it possible to inform all stakeholders that change has been initiated. It is also the signal to raise the required funds and, generally speaking, mobilize all the means needed for this change.



Remark 1:

The process must be adapted, depending on the type of change; the more significant it is, the more it includes control and mobilization of technical, human and financial resources.


Remark 2:

Potential redundancies can exist here, because pre-project stages have the same purpose when it comes to evaluation, mobilization of resources and starting build activities, but within the scope of Project Management (see chapter “Difficult interfaces between frameworks”).


* This is the reason why we prefer to name it Change Approval Board in this book, because it is meant to approve rather than just consult, in order to encourage its members to involve themselves.


Coordinate "Change build" and "test"

Coordination consists in closely supervising change in design and test activities at the build stage, according to the control level wished*. These actions include change itself on the component(s) involved, or even on the process implementation unit mentioned before in the paragraph “Why 2 processes?”. 


Coordinate Change deployment

Change deployment coordination consists in following up this specific stage of Release and Deployment Management that takes place just after the “green light” (see next paragraph). It is meant to set up coordination, mostly through quality control or management of release impacts on the release environment.


Authorize Change deployment

The change deployment authorization is the second one mentioned before (in the paragraph dealing with approval). It is meant to give a “green light” (or “go / no go”) to the deployment of approved releases. Change Management is responsible for giving this authorization because it is in charge of impact management in the release change process.



These last paragraphs demonstrate the existence of an overlap between both processes. The Change Management process supervises that of Release and Deployment Management and gives authorizations based on controls carried out (see different perspectives mentioned above in the page “Why 2 processes?”).


Review and close change record

Here the process goes back to its initial intervention level, i.e. components concerned by change, and does not overlap any more with Release and Deployment Management activities (although it is more relevant to use the records of the “Early Life Support” activity to make to most of change progress).



The review focuses on 2 main points:


►  Feedback from change operations aimed at keeping a record of the right way of carrying out change, evaluating incidents and consequently bringing improvements. This review can generally be made in the week following change deployment, because it focuses mainly on the success of implementation operations

►  Evaluation of the benefit drawn from change and comparison with the benefit expected when change was initiated (see assessment of change benefit for business). This review can be made much later (after several months using the IT Service or the deployed evolution)


Time scales are totally different. Organizations often find different words to distinguish both points:


►  The first one is often equivalent to an “observation period” (“Early Life Support” activities are often associated with it). That is why it is called “User Feedback”

►  The second one is actually called “Post Change Review” (a kind of strategic analysis of change contributions)


Graphic representation of the Change Mangement process


Here is the chronological presentation of activities of the Change Management process: 



Full squares designate activities included in the Change Management process. Dotted squares are not formally included, but are managed by it.


Two key deliverables


Among all activities presented, two key deliverables must be highlighted:


The Change Schedule

The “Change Schedule” (as it is called in V3, or “Forward Schedule Change” in V2) is a calendar gathering all authorized changes. It is updated after the approval stage. It gives a visibility on planned changes at all stages, from design to release. It makes it possible to identify all workload, release, risk-taking incompatibilities, etc…


PSA (V2) or PSO (V3)

The Projected Service Availability (V2) or Projected Service Outage (V3) shows the actual availability of IT Services or the evolutions of existing Services. Just to be clear, it gives accurate information about change availability in the Live environment. Actually, it is not much implemented within companies. This concept is often considered as a level of information included and reported in the Central Change Schedule.


It specifies two useful pieces of information:


►  The actual change release date, determined after the change test stage (at Design stage). This information is thus available after change functional approval and therefore depends no more on business approval uncertainties (see above different perspectives in “Why 2 processes ?”). The only remaining point is the time linked to its deployment, an activity specific to Release and Deployment Management (normally much more predictable, since long-planned; see the “analogy with trains”, in the paragraph “Why 2 processes ?”).


►  It also gives IT Service unavailability slots linked to the necessary outages during deployment phases, addressed in the Release and Deployment Management process.


Remarks about the Change Management process illustration:

Build and Test activities are not specific to the Change Management process, but the latter does control them (not in terms of management, but in terms of quality control and guarantee that fixed SLA requirements can be met. It is necessary to take into account that V3 SLAs are defined as soon as the Service Build stage during Service Design). A change Build and Test activities belong to design project activities. As a result, Project Management processes are operational facilitators in Build and Test activities.



A more accurate vision would be


Illustration of the Change Management process activites including Project Management perspective. By this we mean the right positionning of build and test activities belonging to Development projects (or Build projects) such as software development for instance. 



* In this picture, we have the notion of “Build project”, because the notion of project could also relate to activities which take place later in the lifecycle (e.g. deployment projects). This is another source of confusion about responsibilities.



Copyright © 2013 - PRACT Publishing