The Change Management process is central to the entire transition phase; from the relevant function deciding that a change should be implemented in the Continual Service Improvement process, to the IT Operations Manager formally taking over responsibility for the change implemented.
A change is defined as:
“An addition, change or removal of something which can affect the delivery of IT services or associated documentation.”
Purpose of Change Management
The main purpose of the Change Management process is to ensure that changes are registered, evaluated, prioritized, planned, tested, established and documented in a controlled way.
This is achieved through, in all changes that are implemented:
- Ensuring that all information about the change is registered
- Assessing whether the change needs to undergo Service Design
- Using proven and documented methods and procedures
- Investigating what impact the change has on the IT environment
- Considering the risk for the business
- Ensuring that all relevant aspects of the change have been taken into account
- Coordinating the deployment with other changes
- Ensuring that there is a restore plan prior to deployment
Scope
Each IT organization must decide itself which changes should be registered in the Change Management process. There is no standard level which functions for everybody. Neither does it work to set a level for all services when, for example, replacing a spare part in a PC does not need to be registered in the change process, while the same spare part in a central storage solution needs to be checked more thoroughly as it entails a greater risk.
Besides the Change Management process, changes are also made in Daily Operations Management and in the Request Fulfilment process. Forcing the IT organization to also register these issues in the Change Management process is not effective.
As both Daily Operations Management and Request Fulfilment are based on documented procedures, the practical solution is to register each new procedure as a change in the Change Management process where the it is quality reviewed and approved as a standard change. The procedure can subsequently be implemented in the respective process without the issue being registered twice. What is important is that all changes are registered so that there is traceability if something was to go wrong.
Risk assessment
The objective of the Change Management process is to have as few disturbances as possible in the business when changes are implemented. Unfortunately, the resources are not usually available to review all changes that are implemented, which means that the IT organization has to prioritize which changes it should check more thoroughly. One way to prioritize is to conduct a risk assessment of the changes that are to be implemented and in that way to put resources into the change records that represent the greatest risk of disrupting the business.
The risk assessment is performed through assessing the likelihood of something happening and the consequence of it happening. Likelihood and consequence are assessed individually as low, medium or high according to the following table.
These values are subsequently combined in a matrix so that the total risk can be determined. In the combined matrix, consequence is evaluated higher than likelihood, which is due to the fact that a high consequence needs to be managed even though the likelihood of it occurring is slight.
The total risk assessment is subsequently used to determine the type of change, which level of approval is needed, and which preventive measures are required for the change to be approved for deployment.
Low – Can be approved by the Change Manager. A change which is implemented frequently should be documented as a procedure and be approved as a standard change.
Medium – Can be approved by the Change Manager. A simple restore plan at technical level must be in place.
High – Must be approved by the Change Advisory Board (CAB). A detailed restore plan must be in place.
Types of change
The Change Management process functions as a quality control of changes which are to be implemented in the IT environment. A thorough review of each change would take a lot of time and resources. Furthermore, the administration would delay the throughput of changes to such an extent that the IT organization would not accept the process.
Change records are therefore divided into different types based on the risk the change has of negatively affecting the IT environment if something was to go wrong.
Standard change
A standard change is one that is frequently implemented, and is well documented at instruction level, so that it is performed in the same way each time. It is approved by the Change Management process once and consequently does not need to pass through the process before establishment provided that the documentation is followed.
A standard change is characterized by:
- Proven and documented work procedures
- Usually associated with a low cost
- Low risk in connection with implementation
- Used to process orders in the Request Fulfilment process
- Used to perform change activities in Operational Maintenance
When a procedure for a new standard change is written, it should be submitted as a change through the Change Management process as a normal issue for quality review and approval.
Normal change
Changes of the normal type comprise just one service or a limited part of the IT environment, for example a server or a database. The risk is assessed as low or medium and it is implemented by experienced staff with proven methods.
This type of change does not need to be assessed by the Change Advisory Board (CAB). It can rather be approved for deployment by the Change Manager after inspection.
High risk change
Changes that are assessed as high risk or which affect several different parts of the IT environment need to be reviewed more thoroughly before deployment. There might also be a need for several different parts of both the IT organization and the business to participate in the decision.
These change records are managed by CAB prior to deployment. After deployment and any pilot operation period required, the issue is addressed in CAB again in order to approve the handover of responsibility from the project to Operation.
Emergency change
The purpose of the urgent change type is to enable incidents in the IT environment to be resolved rapidly where a change is required to do this. If the change requires a decision from CAB, but the incident’s negative impact on the business is so great that there is no time to wait for the next planned meeting, instead an emergency Change Advisory Board (eCAB) is convened.
eCAB consists of fewer persons than CAB, however, a minimum of the following:
- Change Manager
- Customers in the business that are affected
- Concerned service owner
- Expert who can report on selection and consequences
For this to function it requires that urgent changes are linked to a specific procedure with which everybody in the IT organization is familiar. Such a procedure should include:
- Brief description of the situation documented and change manager summoned
- Telephone meeting with concerned parties for approval
- Information to concerned stakeholders
- Implementation of the change
- Verification that everything has gone well
- Documentation of the entire process
- Closing the issue
- Presentation of the whole issue at the next CAB meeting
Change schedule
It is good to have a document or a calendar which lists all approved changes and their planned deployment date. It is beneficial if the requested deployment date is also entered in the schedule for deployment of forthcoming changes that are not approved, so that everybody can see what is planned and coordinate their releases. With a common change schedule, it is simple for the Change Manager to communicate dates when changes are not permitted through also entering these in the schedule.
Decision in the process
There are two levels of decisions in the process, one which determines whether a change should be implemented, and one which approves the quality prior to it being deployed. As the mandate for making decisions on whether a change should be implemented is located in different forums and at different levels in the governance model, the Change Control Board (CCB) is used as a general designation for these forums.
Change Control Board (CCB)
Change Control Board is a general designation for the forum which has the mandate to decide on proposed changes. For example, a function or a project steering group. Proposals for changes are investigated, assessed and prioritized together with all other proposals for improvements in the Continual Service Improvement process. The proposals that are approved for implementation are managed in the Change Management process and run by the respective forum.
Change Advisory Board (CAB)
The Change Advisory Board (CAB) is the forum which decides whether a change has sufficient quality to be implemented in the IT environment. CAB is led by the Change Manager, but consists of different participants depending on which issues are to be managed. The purpose of CAB is to coordinate, plan and quality review the deployment of major changes in order to minimize the risk of disturbances in the business.
An example of staffing of CAB is:
- Change Manager (Chairman)
- Representative for CCB (issue owner)
- IT Operations Manager (recipient)
- Service Desk Manager (recipient)
- Applications analyst (expert in the system)
- Technical analyst (expert in the infrastructure)
Each representative for the respective CCB presents its own issues. Even if there are no issues at the particular meeting for a specific CCB, there is a coordinating quality control in that all CCBs are represented at each CAB anyway.
Changes in the IT environment are often a part of a change in the business. With these types of changes, the business has a strong link to the decisions taken in the Change Management process. All decisions from design and financing to deployment and approval are actually decisions that are part of the business’s own decision-making process. In these situations, coordination between the change within the IT organization and the change within the business is dealt with by the CCB forum.
Activities
All requests and proposals for changes must be prioritized by the respective function together with everything else that has to be actioned in the Continual Service Improvement process. Only once the function has decided to proceed with a proposed change is the issue registered as a request for change (RFC) in the Change Management process.
If the change is complex, comprises several different areas or involves a high risk, a design package should be prepared in the Service Design process. The design package comprises all aspects of a change and ensures that the change actually achieves its aim and also that the IT organization can deliver the prospective functionality after deployment. Next step is to approve of the design. For proposed changes that are large and complex, it is only at this stage that the consequences are illuminated and CCB has complete data on which to base its decision. If the change is the result of a change in the business, the decision-making data must be elevated to the business’s decision process for approval.
After formal approval of the design, CCB should coordinate development and testing of the change. The scope at this stage can vary from a few hours to several months, depending on the size of the change. The development and testing activities take place in the Release Management process. A transition also takes place here from regarding the change as a single issue to managing several release packages. A major change is usually divided up into several releases and in the remaining part of the Change Management process, each specific release package is managed as an individual issue. The original change record remains throughout the change and links together all release issues.
The functional test of a release package takes place in the Release Management process. When the package returns to Change Management, it is the quality prior to deployment that has to be approved. This is the first time that the Change Advisory Board (CAB) meets to review the issue. CAB is also responsible for coordinating deployment of the change at an overall level, which takes place through planning the deployment of all relevant changes in the overall change schedule.
Deployment takes place in the Release Management process, which tests and ensures that the functionality and quality in the release package has been achieved. This test period can be several weeks for major releases. After deployment, the issue is dealt with again in the CAB forum for operational approval. This is where the formal handover between the project that developed the change and the IT Operations Manager takes place.
When a change or a release package is approved and handed over to Operation, the Change Manager evaluates and closes all changes that have passed through the process with the aim of identifying proposals for improvement. Standard changes that have been implemented are also evaluated in order to detect whether any of them have resulted in disturbances.
In the evaluation, the Change Manager asks whether a disturbance that has arisen is due to documented procedures not having been followed or if the procedures need to be improved. With major disturbances or problems that have arisen during the course of the issue, an investigation should be conducted to analyze the reason for that it happened and what can be done to ensure that it won’t happen again. This investigation is usually designated post implementation review (PIR).
Value for the business
Changes in the IT environment often have a negative impact on the business as they interrupt the delivery of services. The Change Management process supports the IT organization so that changes can be performed in a more controlled manner, which minimizes disturbances and creates a value for the business. The process also creates a clearer interface between the business’s decision-making process and changes in the IT environment, which contributes to the business being able to obtain better data on which to base decisions regarding its own changes, and thereby create a more complete picture of the consequences of prospective changes to the business.
Documentation
The following documentation should be included within the framework of Change Management:
- Procedures for RFC
- Design criteria
- Template for business case
- Procedures for CAB meeting
- Checklist for approval of deployment
- Template for standard change
- Change schedule
Relationships with other processes and functions
The Change Management process has links to many other processes. The most common are listed here:
Trigger
The Change Management process is triggered through:
- A function or another decision-making forum deciding to proceed with a proposal for improvement which comprises a change in the IT environment
- An incident requiring a change in the IT environment being resolved
- An operational task comprising a change in the IT environment
- An order comprising a change in the IT environment
Input
The following inputs are needed for the process:
- Complete documentation of services, system and products, as well as their dependence
- Clear governance model for decisions
- Description of change (RFC)
- Change schedule
Output
The following outputs are generated by the process:
- Changes implemented in the IT environment
- Reports and statistics
- Evaluations of failed changes
- Proposals for improvement
Measurement
This is how the Change Management process can be measured:
- Number of
- Open issues
- Deployed changes implemented
- Deployed changes rejected
- Urgent changes
- Deployed changes that disrupt the business in connection with implementation
- Deployed changes where restore plan has to be used
- Deployed changes that generate unexpected side-effects (Incidents)
- Average time for a change record from approval of deployment to the activity
Challenges
The Change Management process is complex, cutting through the entire IT organization and also integrated with the business. Changes in associated processes are also managed, for example in the business, within application development and at suppliers.
The greatest challenge is not to mix these different change processes together but instead to put energy into finding the interface between them. This requires that all parties involved have an open mind and understand that models need to be adapted to reality in order to function.
In addition, the following elements need particular attention when introducing the process:
- Training and information about the aim of the process so that the IT organization can perceive the overall efficiency gains with fewer disturbances instead of reacting to the additional administration that the change represents.
- Ensuring that all changes are registered. The most important factor by far is to include all changes as issues in the process from the outset. Quality reviewing each issue makes the process administrative and sluggish, which can lead to it not being used
- Ensuring the involvement of managers and people with responsibility in the business. Without constant reminders and follow-ups, it is easier not to use the process
