Home page | Pages by category | Page index Quick search

Edit

Related articles

• Change Management in Octopus - In development

Edit

1. Introduction

This article presents the key concepts of Change Management process according to the ITIL framework; the process described below has been simplified to suit the reality of small and medium-sized IT organizations to facilitate operating the process.

Octopus "Changes" module allows the implementation of Change Management activities and aims to establish better control IT changes. We invite you to read the article Change Management in Octopus to better understand the use of this module.

The Change Management process objective is to ensure that changes are recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.

To be carried out satisfactorily, the Change Management process must :

• Use standardized methods and procedures (which can be reused)
• Ensure the registration of all changes
• Consider the risks and impacts to the business

Which symptoms show a non-existent or deficient Change Management process? Unplanned service interruptions due to changes unregistered, unauthorized or inadequately assessed & tested Partial success of deployed changes - incidents occur after the implementation of the change (rather than being eliminated permanently) A high number of emergency changes Etc.

Every IT organization should define the scope of what a change is for them (i.e., an IT organization could identify the replacement of a computer hard disk as a Service Request and treat it as such in the Request Fulfillment process, not as a change in the Change Management process). It could simply be defined that everything that is not a service request is treated as a change.

Edit

2. Definitions

Term	Definition
Request for Change (RFC)	Formal request for change to be made. A RFC includes details of the proposed change and can be recorded on paper or electronically. The term RFC is often used to mean Change Record or the Change itself.
Change	Addition, edition or deletion of anything that may affect IT services. "Anything" is usually the physical or software infrastructure, but also includes changes to documentation, processes, service catalog, etc.
Change Advisory Board (CAB)	"Change Advisory Board" - A group of people that advises the Change Manager in the assessment, priority settings and schedule of changes. The CAB may be composed of representatives of all branches within the IT organization, including the business and third parties (vendors).
Change Schedule	Document that lists all the approved changes and their scheduled implementation date.

Edit

3. Change Classification

There are three types of changes:

• Standard Change

• Normal Change

• Urgent Change

Edit

4. Change Management Process Diagram

The Change Management process includes a set of activities which course may vary depending on the nature of change. For example:

• Standard Changes, which are actually Service Requests are managed in Request Fulfillment process, but the steps of execution are defined and validated by Change Management;

• Urgent Changes have a specific procedure defining how they will be evaluated, authorized, tested, and implemented in an urgent context.

The figure below shows an example of Change Management process diagram for a normal type change, showing the implication of different stakeholders in the process. To download the file in Visio 2007, click here.





Edit

5. Process activities

To better explain how the process works, here is a brief description of each activity. Edit

a) Record the RFC

The creation and registration of the change (or RFC) can be done by an individual or department requesting the change, which may come from the side of the business or IT organization (for example, a change to an application a change to an item of infrastructure, etc.).. All changes are recorded and identified by a unique number. The scope and impact of the change determine the amount of information required for its evaluation, and this aspect must be defined either in the process document templates to be filled, either by a specific procedure to follow.

Edit

b) Validate

RFC Of all the change requests submitted, some may be illogical, inapplicable or incomplete, or have already been submitted by someone else. If so, they refused and the reason is transmitted to the applicant.

Edit

c) Assess the RFC

First, confirm the type of change (category), taking into account the risk and impact of the change.

The change categorization is made to identify the level of authorization required for changes. Based on the impact and urgency, we can establish a guide matrix indicating the type of change and level of authorization. For example:





This matrix is only an example, each IT organization can define its change categorization according to their environment: this may differ depending on the business area, criticality or risk associated to some applications or hardware, etc.

Major Changes:

The major changes involve a significant amount of preparation and work with complex situations or major expenses.

Examples:

• Implementation / upgrade of a corporate business application
• Moving a computer room

Significant Changes:

Significant changes involve preparation and work, evaluation, authorization and planning for change.

Examples:

• The purchase and installation of a new server
• The re-segmentation of network
• The introduction of a new application to a small group of users

Minor Changes

Minor changes can be evaluated and authorized outside the authority of the CAB (eg by a coordinator).

Examples:

• The application of a "patch"
• Installation of a new printer model

Edit

d) Authorize the Change

Based on the impact, risk assessment, potential benefits and costs of the change, the change authority must agree to all changes. In the model we suggest, we consider:

• Change Manager role in the authorization of minor changes;
• CAB role in the authorization of significant, major and urgent changes (an "Emergency Change Advisory Board (ECAB) is invoked then, according to the special procedure defined for urgent changes).

The CAB is composed of anyone involved in the change, technical or operational (this includes customers and external suppliers). It meets or consult at regular intervals to prioritize changes, make a review of the presented changes, make a review of unsuccessful and / or unauthorized changes, to discuss the ongoing changes, etc. In principle, it is an advisory body only, but our model assumes that if all members agree, the CAB is the change authority. Otherwise, the IT manager can intervene and decide if the change can be implemented, needs to be reevaluated, ore rejected.

The CAB will be adapted to the context and the size of an IT organization, the important thing is to have an authority that ensures that changes are controlled, the risks and service interruptions are minimized in order to target succeeded deployment in first attempt. Relevant documents should be distributed in advance to allow CAB members a proper change evaluation and meeting preparation.

It goes without saying that a major or urgent change may require a higher hierarchical authorization, sometimes provided by the customer, especially when the risks and costs on business are high. It is the IT organization responsibility to define its own authorization process. Edit

e) Coordinate the implementation

Actions of implementation of approved changes must be submitted to the technical teams involved in the implementation. They must thoroughly test the changes, determine the backout procedure, document the temporary solutions that will resolve knwon incidents that will occur, and so on. Edit

f) Review and Close

Implemented normal and urgent changes are evaluated after a certain time, the CAB determines the necessity of doing so. The following questions may be addressed:

• Has the change reached the desired goal?
• Are the stakeholders satisfied with the result?
• Has there been any unexpected side effects?
• Were costs and efforts overrun compared to the initial assessment?
• Can we do better next time?

If the change is successful, it may be closed. Otherwise, Change Management or the CAB will have to decide what to do: a new change or modification to the existing change.

Upon closing, the Change Manager ensures that the documentation of the change is complete, and make sure to include the result of the change review. All this information is part of the knowledge base for any new change of a similar nature, or as a contribution to the continuous improvement process.