What is Change and Change Management?

Objectives of Change Management?

In IT, change is anything that impacts and changes the IT infrastructure. For example, it can be a downed storage server or a software upgrade request. It can include switching to a knowledge management system or moving a server room. It also includes the global changes that affect several IT operations areas such as data centre changes, desktop replacement or operating system upgrades.

ITIL (v3) terminology defines a change as:Change Management process objective is to ensure that changes are recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.

What is Change Management?Change Management is an organization’s ability to take stock of its IT inventory and infrastructure, and to ensure consistent procedures for handling changes with minimum risk to IT infrastructure. The goal of Change Management is to ensure that standardized methods and procedures are used for efficient handling of all changes to minimize the impact and risk of change-related incidents and to improve day-to-day operations.

The main purposes of Change Management are:

• Minimal disruption of services;• Reduction in roll-back activities;• Cost-effective use of resources involved in the change.

Effective Change Management also means all processes are in place to streamline IT changes.

The objective of Change Management is to ensure that all changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner. Change Management gives an IT service department the ability to:

• Have a birds-eye view of the entire IT infrastructure;

• Respond, manage and track requests for IT changes using standardized procedures;

• Assess the cost of proposed changes before they are incurred;

• Have fewer changes that are aborted, or fail;

• Increase productivity of key personnel through decreased urgent changes;

• Absorb a large volume of changes.

Overall Change Management gives IT clients an enhanced business perception of IT because they receive a professional, process-oriented, timely delivery of service. It’s about IT operations running smoothly with less risks.

Types of Change

Standard Change

A standard change is a change that is pre-approved by the Change Management process, evaluated as low-risk, relatively common and performed according to a procedure or work instructions. It involves configuration items (CIs) which changes need to be managed by the Change Management process.

Page 2 | Unravel Change Management

Normal Change

Change that is not a standard change, or an urgent change; it follows a pre-defined workflow within the Change Management process. It is divided into 3 categories, which are evaluated according to the impacts, risks, benefits, and costs: minor, significant, and major.

Urgent Change

An urgent Change is a change that must be implemented as soon as possible. Essentially, it will follow the same normal change procedure with a few exceptions: Emergency Change Advisory Board, (ECAB) may be invoked if the Change Advisory Board, (CAB), is not available, testing can be reduced, and documentation of the change and configuration data can be delayed.

The Change Management process includes a set of activities that can differ depending on the nature of the change. For example:

Standard changes are generally pre-approved and have their own workflow. They can be processed in a pre-established maintenance time frame, or when there is not impact on business outside office hours. Standard changes are procedures which are to be reused in certain, predefined situations with-out further process. It is often small, structured, frequent, trivial and easily understandable changes, it is possible to give acceptance in advance – as a standard change. However they must be logged, but the Change Manager or CAB is not involved in each specific case.

Normal changes are managed according the change category structure (minor, significant or major) and the IT organization defines categorization parameters and the authorization level to apply to them.

Urgent changes must be implemented as soon as possible, in a controlled context of evaluation, testing and authorization. If absolutely necessary, every non-essential, non-technical stage can be circumvented however the

procedures for such change must be defined for the organization in advance:

• CAB/EC is a sub-set of CAB and it is easier to arrange for a meeting

• Change Manager can make decisions by himself• Testing, documentation etc. can be done post

change.

Examples

Standard ChangesRoutine Changes that follow an established procedure & do not disrupt IT services

• Updating the Anti-Virus software• Creating a New Starter

Emergency ChangesCrucial to an organization and have to be implemented immediately.

• Emergency Changes are disruptive and prone to failure

• A critical switch has broken down. Therefore, a new switch needs to be installed

1 2 3

What is the process for Change Management

1. Identify a potential change and create Request for Change Incidents, upgrades to the infrastructure, or changes in the business requirements generate the need for a Request for Change (RFC). A proposed change request should include a complete description and the intent or purpose of the change. In addition, the person or department who requests the change should include information that describes who or what will be affected during implementation and after deployment. This could include locations, departments, user groups, servers, and applications.

2. Change Manager A must for successful change management is the change manager. The Change Manager is the process owner and controls the lifecycle of all changes. The Change Manager filters requests and plan changes in the order of their impact and urgency based on business impact. For important changes or significant impact changes, the Change Manager will refer the authorization of Changes to the Change Advisory Board (CAB) and for minor impact changes, the Change Manager authorizes, schedules and notifies CAB. Finally, for major impact changes the Change Manager refers changes to senior management or Board level.

Page 3 | Unravel Change Management

3. CAB/ECABThe Change Advisory Board (CAB) approves Changes after assessing and prioritizing the RFCs. All CAB members should have sound technical knowledge and good business perspective. The permanent members on the CAB/ECAB is normally:

• Change Manager • Problem Manager • Service Level Manager The other members vary depending on the change but could be the following:

• Affected customers and users• Development staff• Consultants / Vendors / Outsourcers• Services Staff• Service Desk• IT Security• IT Audit

CAB advises the Change Manager about the changes and the Change Manager authorizes or rejects the change on behalf of the CAB and communicates the outcome of the decisions.

Emergency Change Advisory Board (ECAB) is a subgroup of the change advisory board that makes decisions about emergency changes. Membership may be decided at the time a meeting is called, and depends on the nature of the emergency change

4. Building the changeOnce a change has been approved, the next step is to communicate details of the change by setting expectations, aligning support resources, communicating operational requirements, and informing users. The risk level and potential impact to affected groups, as well as scheduled downtime as a result of the change, should dictate the communication requirements..

Page 4 | Unravel Change Management

5. Release managementRelease management engages to oversee testing, rollout planning for the change. The approved changes are applied systematically, making certain to monitor the results. If the changes being made are having an adverse effect on other systems or applications, back out of the change. In the event a planned change does not produce the expected results, make certain to document the process that was followed so that future plans will not include faulty design.

6. Configuration managementThe single most overlooked part of change management is documentation. All activities performed before, during, and after a change should be documented. IT staff often fail to document changes as they are applied. Failing to keep a log of all changes may lead to confusion and ongoing problems associated with previously implemented changes. The change controller should always make certain they receive formal documentation regarding every change. Additionally, configuration management tracks relationships with the change.

As with any process, there is always room for improvement. Everyone involved with a change management process, including the IT staff members, the change controller, the change advisory board and executive management should meet and review the processes in place and look for areas of improvement. As an organization changes, so will the processes in place that help to manage it. Flexibility will lead to overall success.

Connected ITIL processes

Change management is an IT service management discipline and is part of the ITIL framework. The below illustrates how it fits in the framework.

Where does Change Management fit in the ITIL framework?

Page 5 | Unravel Change Management

Incident ManagementIncident management’s primary goal is to ensure all incidents are resolved in a timely manner dictated by the service level agreements. There are situations when a helpdesk cannot resolve the incident and requires a change that needs to be coordinated with Change Management. A request for change is then submitted to Change Management and the helpdesk is kept up to date with the change status.

Problem ManagementProblem management provides input into the change management process through the formal issuing of RFC’s. Changes arising from the generation of workarounds from known errors as well as final solutions are processed through Change Management and the Problem Manager sits on the CAB. Additionally, changes (especially urgent changes), are prone to causing errors in which the problem management team has to intervene and investigate.

What metrics is useful in Change Management

Availability ManagementThe objective of availability management is to ensure that all application systems are up and available for use according to the conditions of the service level agreements (SLA’s). They ensure proper contingency plans are in place and tested with any change.

Release ManagementRelease management uses formal controls and processes to safeguard the production environment. One such process is release planning where authorized changes are assigned to release packages. The planning process develops a schedule for building, testing and deploying the release. At the end of the build process, all changes

There are a few Critical Success Factors (CSF’s) for change management expected from various stakeholders.

Some of these include:• Protecting the business from adverse impact of IT

change• Facilitate the rate of change that the business needs• Provide knowledge and information about new and

changed services needed by IT and business staff• Make efficient use of IT resources

To demonstrate that you have achieved each CSF or how well you are doing against that CSF, key performance indicators (KPI’s) are used against each CSF.

For example, let’s take the CSF “Protect the business form the adverse impact of IT change”

Page 6 | Unravel Change Management

Some KPI’s (key performance indicators) would be:

• Reduced number and percentage of changes that cause incidents

• Reduced total business impact of incidents caused by changes

Below are some additional reports and KPI’s that help gauge the effectiveness of your change management process.

• Number of rejected RFCs• Number of incidents occurring due to implemented

Changes• Number of incidents resolved by implementation of a

Change• Number of successful changes• Number of unsuccessful changes• Number of backed out changes• Average time needed to implement a Change• Average time to perform a Change• Costs related to changes• Number of changes that are within time and budget

included in the build are read to enter the testing phase. Once fully tested, the changes are rolled out into the live production environment and this process is sometimes responsible for end-user training.

Configuration ManagementConfiguration management assists change management by recording which configuration items (CI’s) have been changed and controlling the status of CI’s throughout the entire CI lifecycle. It focuses on tracking and documenting configurations and then providing this information to other areas including Change and Release Management. Configuration tracks relationships to understand who is affected and assess impact.

Corporate Headquarters 3675 Mt. Diablo Blvd., Suite 200 Lafayette, CA 94549 Tel: (925) 871-3900 Fax: (925) 871-3991 www.techexcel.com

TechExcel EMEACrown House, 72 Hammersmith Road London W14 8TH, UK Tel: +44 (0)20 7470 5650 Fax: +44 (0)20 7470 5651 Email: emeainfo@techexcel.com

The seven R’s of change management is a quick check list of what should be covered when submitting a RFC. It’s a practical way to reduce the number of unnecessary changes at the first point of logging.

• Who RAISED it• What is the REASON for change• What is the RETURN expected from change• What could be the RISKS involved in change• Which RESOURCES are needed to implement change• Who is RESPONSIBLE for build, test & implement

change• Is there any RELATIONSHIP between this change &

other changes

Change will inevitably happen, and changes will happen daily in a busy IT department, and the only chance of controlling the risks and volumes of change is by having a formal Change Management Process. Change Management needs to be effective in order to benefit the organization and this whitepaper will highlight some of the key points that will help you accomplish your goals.

7 R’s of Change