Change management

The purpose of Change management process is:

• Standardization procedures for effective and fast execution of necessary changes.
• Recording of all changes in the Configuration management system.
• Optimalization of risk related to changes.

• Changes of much larger extent than a bare service change (e.g. cardinal organization changes). These cardinal changes can, however, lead to associated particular changes, that the Change management process will cover.
• Operational changes like printer or PC repair

Change management has a number of interfaces to other IT processes from area of IT Service Management (ITSM) or other areas (Programme and project management, Sourcing).

We distinguish following change types:

	Change type
	Normal change.
	Standard (pre-approved) change. The change is realized as a catalogue request in the Request fulfilment process.
	Emergency change. The change is realized with purpose to restore a service. The urgency of the change does not often enable the normal authorization process.

Change authorization

It is good to link the form of the change authorization to:

• risk ratio
• financial demands
• degree of the change impact.

Example:

Change Advisory Board assists in assessment and prioritization of changes. Potential participants are (actual composition can differ at different changes):

• Users
• Application administrators
• Service desk
• Infrastructure teams (Servers, Telco)
• IT security
• Enterprise architecture

Since there is not enough time for meeting all the CAB members when authorizing Emergency changes and decision about authorization of such a change has to be taken fast, it is recommended to establish also Emergency CAB with participation of the most important roles only.

Change management is an area that typically requires most attention when implementing ITIL processes, in order organization specifics are taken into account and the resulting process ensures required level of change management and at the same time it does not mean enormous cost and change slowdown (time-to-market).

In ObjectGears a key entity in the Change management process is Request for change. Request for change is created within a certain Project (see Project management) or as a response to a Problem (see Incident and Problem management). On the contrary processes of Test and Release management follow the Change management. Performed changes need to be reflected in the Knowledge Base (see Knowledge management) and Configuration database (see Configuration management). Change may relate to other processes as well and lead e.g. to modification of current cost models (see Financial management).

The Change management process can be described by the following scheme.

The first step is creation of the change request. It typically comes out of a project, which has in scope particular areas of necessary changes. Another source is Problem management (Change request solves a problem) or (rather in smaller organizations) Request fulfilment (initiative of an end user is transfered to a change request). Note: Complexity of changes in larger organizations requires usually more formal process of generating and assessing change requests. Relation to the Request fulfilment process is not used and the user is guided to process Project idea - see Project management process.

After creating change request it is reviewed. There are requests filtered out in this phase that are obviously impractical (without a real chance for implementation) or that occur again, no matter if there were already refused in the past, accepted for realization or still pending in the assessment process.

Requests, that passed through the review, are assessed from the perspective of their impact and demands. In this phase Change Advisory Board (CAB) comes in - it is a committee that recommends the change for realization based on the performed analysis and provides documents for an informed management decision.

After that the change request is approved and the change planned. When planning Project manager creates Tasks for particular roles (e.g. Analyst breaks down the Change request into Detailed requests and Test manager creates Test cases (see Test management).

The next phase is implementation. In this phase Project manager creates requests for development, Test manager organizes test rounds, Testers report Defects and Developers correct them. Project manager checks work progress (development tasks, tests, bug correction) and prepares with Release manager release into production (see Release management).

The last step is revision of the realized Change request and its formal closure.

ObjectGears supports above stated processes with activity automation (e.g. automatic creation of a task for testing after reporting Bug resolution), notifications to users, single queue of solver tasks, work status reports etc.

Examples of screens

Change detail

Detail of Change request (RFC)