ITIL Change Management

ITIL Change management

1. Introduction

Most incidents are directly related to change (e.g. user had installed a new cracked software and it was a virus).

Change management is like thermostat.

The goal of change management is to manage the changes process and to limit the introduction of errors and incidents related to the change. Any change has to be done properly and it should be controlled.

2. ITIL Change management terminology(ITILv3 glossary)

Change: Any addition, modification or removal of any entity that may affect on IT services/configuration. Any change in any document is also a part of the scope.

Change case: To predict what kind of impact of the proposed change on our environment. It’s important for any change or cost analysis.

Change Advisory Board (CAB): It’s a board for change management; they are assessing, prioritizing and scheduling the changes. It has to be presented to all 3rdparties and other business units.

Change History: documentation in the database has all information about changes. It’s history for all records.

Change model: It’s logical/repeatable method for handling particular change category. It’s predefined steps to make changes for particular item.
This type of change does not require approval such as changing password.

Change record: It’s a row in the database or spreadsheet. It’s a record for all changes.

Request For Change (RFC): Should be stored in Configuration Management System (CMS) even if it’s rejected.

Change schedule: It’s a document which contains list of all approved changes and their schedules. It’s called forward schedule of change.

Change management: It’s the overall processes and procedures that control the lifecycle of any change.
The goal of change management is to have the best change with minimal destruction to the other IT services or the business.

3. Change management processes(actions)

Recording: Making sure that the source of change can submit this request and it’s recorded in the database.
- All RFCs are logged with reference number of known error –if applicable-.
- Routine standard changes (e.g. changing password for user) do not generate RFCs. They will be handled by incident management or service desk
- RFC comes from problem management, IT staff, customer, Legislation & mandates, vendors, suppliers and projects.
- Log should contain: RFC unique ID, Cross-referenced of the known error/problem number, description, reasons for changes, new versioning, information about submitter, submission date, estimated to frame and resources allocation.

Acceptance: Filtering out requests and accepting them to further steps.
- Initial assessment with re-request option for RFC change incident aka Change Item (CI)
- Acceptance will lead to:
1- Status change of the existing CI.
2- Change in the relationships between CIs.
3- New CI.
4- New location or owner of CI.
-Information needed to further process change is included in the change record –which will lead to next process-.

Classification: Sorting out RFCs according to their categories and priorities
- Priority and category are designated for accepted RFC.
- Example of priorities: 1-Low, 2-Normal, 3- High & 4-critical.
- Priorities and categorize determined by CAB and possibly other steering committees
- Sample categories:
- Minor impact
- Substantial impact (e.g. change IP address for a machine)
- Major Impact (e.g. upgrading the operating system for a server)

Coordination: Coordinating the construction/pilot testing and rolling out the change.
- Approved changes go to product specialists who construct and integrate the change.
- Before implementation, changes should be pilot tested (e.g. upgrading OS).
- This may involve release management IT service.
- Phases:
1- Build: could phase could be skipped.
2- Test: To ensure that the rollout is possible.
3-Implement: Coordinate between all involved parties.

Evaluation: Checking if the change is successful (by meeting the expected goal), drawing conclusion and learned lessons how we can improve the process.
- All implemented non-standard changes should be assessed .
- Did change meet intended goal?
- Are all parties satisfied with the results?
- What were unplanned side effects of changes?
- Did implementation exceed the estimated costs or downtime?
- RFC is closed after success and evaluation (not only after success)
- Results are documented in the Post Implementation Review (PIB) after closing the change

4. Change manager roles

Overall responsibility for change management in the consullation with management liaison & CAB.

Maybe single individual or steering committee.

In charge of reaching all change management goals and developing methods to ensure from the effectiveness and efficiency.

Defines the scope of change management and associated processes.

Receives logs, prioritize RFCs, convenes CAB to review the changes.

Submits CAB recommendations.

Note: Change manager could be product, project or problem manager but not the incident manager.