Branimir Valentic If there is a nightmare in IT Service Management, its name is Change. It’s not only that people are, generally, reluctant to changes. Changes impose high levels of risk and no one likes disruption in running services. That raises a question: Why do we make changes, after all?
Reasoning
There are many reasons why changes are made. Roughly, there are two reasons for change:
Proactive Changes – improving processes i.e. services, or reducing cost of services. I am familiar with the case where an organization redesigned operational processes to consolidate Service Desk structure (each business unit had its own Service Desk) and respective functional teams to increase operational efficiency, customer satisfaction and achieve financial savings.
Reactive Changes – resolving errors or adapting to changed circumstances. Security issues, operating system patches, vendor-initiated changes, upgrades… usually such changes eliminate (or decrease) exposed level of risk.
ITIL postulates
ITIL defines changes as “the addition, modification or removal of anything that could have an effect on IT services,” and Change Management as “the process responsible for controlling the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.” Change Management begins in the Service Strategy part of the IT Service Lifecycle. Namely, the Request for Change (RfC) defines goals and objectives of the change. After evaluation, Service Design defines how to build the change. Service Transition is responsible for build, test and deploy of the change. The Service Transition and Service Operation phases of the lifecycle overlap after deployment, and Service Operation “takes over” after acceptance. This process is valid for Normal Changes.
There are two other types of Changes: Standard and Emergency Change. Standard Change is pre-approved, carries low risk (and known risk) and follows the same process. Therefore, there is no need to go through an evaluation and approval process every time. Examples of such change include a password reset or a desktop move for a single user. Emergency Change encompasses changes that must be implemented as soon as possible. Usually, we are talking here about security issues and remediation of security treats. There is no time to undertake lengthy evaluation or testing, but there is a procedure to implement emergency change, i.e. it is not an ad-hoc practice.
Figure: Change Management throughout the IT Service Lifecycle
Implementing Change Management
There are several parameters that have to be considered while implementing Change Management:
Policy – define what must be done and how Change Management is organized. Policy includes:
- Alignment with business
- Integration with other processes (e.g. Incident Management)
- Responsibility matrix
- Segregation of duty controls
- Change windows
- Performance and risk evaluation
Processes – as already mentioned, there are several types of changes. Each of them has to have well -defined processes with clear inputs, outputs, responsibilities and procedures. Poorly defined processes can have huge consequences due to the fact that processes impact change outcome.
Resources –individuals, teams/groups and organization have to be considered separately.
- Individuals are usually reluctant to change, and they have to be convinced and “taken on board” as motivated individuals to use the changed service. On the other side, some individuals are key players in leading the change implementation, and their skills and capabilities are crucial for change success (or failure).
- Teams or groups are introducing change. Not only technical skills, but their organizational skills (like roles, responsibilities, functions, and processes) are of highest importance to introduce change.
- Organization, its setup and structure dictate process of change introduction. My experience from both big, well-organized and hierarchical organization as well as small, fluid organizations, tells me that there is a different approach depending on the organization’s size, hierarchy and culture.
Responsibilities – it is crucial that responsibilities and duties are well defined. Responsibilities in the change process depend on the organization. I noticed that, particularly in big organizations with strong hierarchical structure, a rigid approach to the change process is usually a burden. Change implementation takes too long, costs are rising and motivation of involved people decreases. Often, the outcome is questionable.
Interdependencies with other processes – Change Management is bundled with some other process in the IT Service Management Lifecycle.
- Incident Management is, on one hand a trigger, and on the other hand a measurement of how efficient the change implementation was. Poorly implemented change will generate new or more incidents.
- Service Asset and Configuration Management (SACM) is a process that is usually considered very closely with change management, or, more accurately, Change Management relies on SACM. There are several areas where Change Management needs SACM:
- Scope of a Change – if SACM is not implemented, the scope of change (e.g. which Configuration Items are affected with change) is an approximation.
- Baseline – if Change is not successful, a backup procedure should be in place to revert to the starting point. SACM has a mechanism to define baseline (i.e. starting point).
- Status and Logging – Change considers change of state of the Configuration Item. Those changes must be logged (during the change process and after the finish) due to the fact that other processes rely on status information, and they are used in change evaluation of new/future changes.
From my experience, it is advisable to implement the Change Management process in one step. Contrary to Change Management, SACM is not expected to be implemented in a single implementation; rather, it will be implemented in phases.
The Change process is complex, but very important. A lot of parameters and interfaces (to other processes) have to be considered. Therefore, carefully implement an efficient Change process adapted to your organization and your needs. And, if needed, be ready to change it, because – Things are always changing!
Download a free sample of our Change Management process template to gain more knowledge about change management.
