Introduction to the Change Management Process

This section covers the change management process. This is one of the process areas we cover in detail; when you come to the exam, you can expect to have questions that ask you about the activities and concepts of the process as well as the purpose of it.

It is important to start with an understanding of the purpose, objectives, and scope of the process, because this sets the scene for how the process will be used in the service lifecycle. We will also cover the activities of the process and the concepts of the types of change (normal, standard, and emergency). In addition, we cover the role of the change advisory board (CAB) and how the change management process interfaces with the rest of the service lifecycle processes.

The Purpose of the Change Management Process

Let’s begin by looking at the purpose of the change management process according to the ITIL framework. ITIL states that the purpose of this process is “to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.” This simple statement cuts right to the heart of successful change management for an IT department.

If, in an organization that has not adopted best practices, you review your records for incidents following a change to your infrastructure, it is very likely that there will be an increase in incident volume specifically associated to the change that has been made. Uncontrolled change may trigger or be the cause of incidents in the infrastructure. According to the IT Service Management Forum (ITSMF), 80 percent of all incidents are caused by changes to the IT infrastructure.

It is for this reason that best practices in service management suggest that change management should be controlled. But there are other equally compelling reasons to address the issues caused by poor change control, not least of which is the reputation of the IT department in the eyes of their customers.

This is an extract from a conversation heard in an office on a Friday afternoon:

This kind of attitude and expectation can be very damaging to the organization as a whole and demonstrates a lack of confidence in the IT department. Service management is about providing your customers with assurance that the IT services and systems that support the business will work as expected, when required. Unreliable changes that do not achieve their benefits cause adverse impact on the business as a whole, so the importance of controlling the change process is vital to business success.

Equally damaging is unplanned change, and often it is the IT department that carries this out. There is not usually malicious intent to bring down the service when making unplanned changes; it is much more likely to be carried out by a well-meaning individual with the intention of correcting an error that may have an impact on business performance. But if this is carried out without careful planning and assessment, there may be unintended and unexpected impacts on existing services.

Any failure in the management of change will potentially require additional work and rework following the implementation, and this has perhaps the most significant impact of uncontrolled change in your organization. It may incur additional costs, for which there may be no budget, and this can contribute to the view that IT departments are endless “money pits” into which the business pours funds for little perceived reward.

Objectives of the Change Management Process

The objectives of the process reflect some of the issues identified in the previous section on its purpose. A key objective is to keep abreast of the changes that happen in the business environment. This objective specifically states that while responding to the changing business needs, you should be reducing incidents, disruption to the services, and rework. In this way, the process can assist with maximizing the value of the IT services provided to the business.

It is an important objective to support your business, and as organizational needs evolve, the IT department or service provider should continue to ensure that the services align to business needs. This will require the management of changes to the services to meet the challenges of a changing business.

The next objective identified by the ITIL Service Transition publication begins to show the process in action. It states that the service provider should “ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.” This states the steps of the change management process as a clear objective and sets the expectation for how changes should be controlled. Note that the objective stresses authorized changes as part of the process flow and emphasizes the need for recording changes.

As part of the management of change in the IT environment, one of the objectives for successful change management is to control the items recorded in the configuration management system (CMS). This, of course, assumes that the IT service provider has a functioning CMS. We will be covering the CMS in Chapter 9, as part of the process of service asset and configuration management (SACM). The SACM process is an important one in the overall approach of the service lifecycle, because it helps identify the components that make up our services and how they all relate to one another. Once we have made the effort to capture this information to maximize its use, it needs to be maintained and kept accurate. The process of change management is key for enabling this and ensuring that we have relevant information maintained in the CMS.

The ITIL framework also suggests that an additional objective of the change management process is to optimize risk for the business. The reason for a change may often be to minimize risk, but it is also common to accept risk for a beneficial result. Often the reason for carrying out a change is that the risk of not doing it far outweighs the risk of doing it. We will be covering this important aspect when we cover the individual steps of the process later in this chapter.

The objectives set the expectations of what will be achieved by the process.

Scope of the Change Management Process

Change can be looked at in many different ways, so it is extremely important to understand the scope for this process so that it can be handled effectively. The ITIL framework defines a change as “the addition, modification or removal of anything that could have an effect on IT services.”

This means the scope of this process covers everything from the architecture and infrastructure to the processes, documentation, metrics, and tools that support your services, as well as changes to IT services and configuration items.

With a scope as large as this, it is even more important to ensure the control of the environment with a manageable, repeatable process. ITIL suggests that the process should cover all stages of the service lifecycle, from strategy right through to operation and into continual service improvement. Changes to configuration items across the lifecycle should be managed in a controlled manner, including changes to contracts, agreements, or physical assets such as servers or networks and virtual assets in a virtualized environment. This should also include the management of changes to the five aspects of service design (which were covered in Chapter 4):

• Service solutions for new or changed services, which include the resources and capabilities needed for the service and the functional requirements for the solution
• Management systems and tools, particularly the service portfolio, allowing management and control of the services throughout their lifecycle
• Management and technology architectures required to deliver the services
• Processes that support the services by managing design, transition, operation, and improvement activities
• Measurement systems, methods, and metrics for the services

Defining the changes that are out of scope is equally important for the successful management of change. Typically these will include changes that have a significantly wider impact than just the services themselves, such as changes to departmental structures, business policies, or operations. These changes may have associated IT service changes, which would be managed through the change process, but the initial management would be through business and organizational change processes. But at the other end of the scale, the minor operational changes that need to be done as part of day-to-day management of the infrastructure may also be excluded from the change management process. Examples of these would be routine maintenance changes such as simple repairs to printers.

Management of change needs to take place at all levels of an organization—strategically, tactically, and operationally. Agreeing on the scope between the IT service provider, business, and any suppliers is essential for success, particularly where there are shared assets and a shared responsibility for the delivery of services to the organization. The ability to interface our IT change management process with those of the business and the suppliers to effect a seamless introduction of change will be a major factor in the successful management of changes in a complex environment.

The service portfolio, with its capture of the details relating to all services, including current, planned, and retired services, is a valuable tool for understanding the impact of changes in a supported environment.

Changes may be triggered from a variety of situations and still remain in scope for your process. Strategic changes may be introduced through a change proposal, whereas design driven changes may occur in response to design requirements as part of the development of a new service. Service operations or external suppliers may initiate changes that arise from improvement initiatives or in response to operational requirements for corrective actions. Change management is not responsible for the coordination of processes for the successful implementation of projects; this will be handled through the planning and transition support process.

So, defining the scope can be complex but is important for the successful management of the process and will require negotiation and discussion throughout the organization to ensure everyone has a clear understanding and expectation for the management of changes.

Types of Change

Many different types of change exist in operational environments. As we discussed in the previous section about the scope of change, it is a wide subject area. A change is captured as a formal request for alteration of a configuration item. There are a number of ways of handling this formal request; it could be a service call to the service desk, a completed request for change form, or even a project initiation document. A request for change is commonly referred to as an RFC.

One of the most common complaints when you try to introduce a new change management process is that it is too bureaucratic. There is often reluctance to update documentation if it is seen as unnecessary with no obvious benefit to the individual who has to complete it. When introducing a request for change form or procedural documentation, it is advisable to think about the culture of the organization and how processes are viewed. If processes are seen as unwieldy and ineffective, if you introduce a complicated or overly detailed form for requesting a simple change, then people are unlikely to use it. Many people do not like documentation, so the simpler the form and detail required, the more likely people are to support the process. So, introducing a formal document to capture change requests means that you have to be aware of the requirements of the business and be sensitive to its needs. The ITIL framework identifies different types of change, and each has a different handling procedure, so you can adapt the request for change (RFC) to meet the individual requirements of each change type.

There is sometimes confusion over the terminology that is used around the change management process. For clarification, the ITIL framework identifies the difference between a change, a request for change, and a change record.

Change models can be used to manage specific types of change, such as standard changes, emergency changes, regular maintenance changes, and service requests from users. Now that we have clarified the terminology, we’ll cover the different types of change that ITIL identifies: standard change, emergency change, and normal change.

Standard Change

A standard change is a change to a service or other configuration item, which has a preauthorized approach to its execution. These are changes with a well-known and clearly understood risk. Examples of this type of change are the provision of a user profile for a new starter or software download from a standard list or a desktop move for a single user. The approach follows a set of predefined and agreed steps providing a model that can be used and reused consistently. This model will determine the requirements for logging the change, handling the change, and implementing the change. It will be an established and tested procedure that has been proven in practice. The change authority that has the budget for the activity grants authorization of the standard change.

These key elements identify a standard change:

• There is a clearly defined trigger for the initiation of the change, such as an exception generated by an event management tool or a request via the service desk.
• The actions are understood, proven in practice, and documented.
• Authority is effectively given in advance.
• Financial authority either is in the control of the requestor or is granted in advance under an agreed budget.
• The risk is low or well known and understood.

Example of a Standard Change

The following is an example of a standard change in a working environment. In the car manufacturing industry, cars are often sold by franchise garages or dealerships, rather than directly from the manufacturer. In one such organization, the manufacturer uses the standard change model for the IT requirements when introducing a new dealership. Let’s explore whether this use of the standard change meets the specifications identified by the ITIL framework. The standard change in this case covers a number of activities, each of which is documented. The activities are all clearly understood (equipment and software are sent to the dealership, user profiles are set up, access profiles are applied to the firewalls, and so on) and so are the risks. There is a well-known and documented trigger for the change. Most importantly, because the decision is in the control of the business, the authority for the budget is agreed upon, and the authority for the implementation of the change is part of the business decision to engage the dealership. So, even though this change has a number of activities and involves considerable cost, it has been proven, the risks are well known and understood, and it is requested and classed as a standard change. It follows a defined model, which includes documentation specifying each step of the activities, including the lead times for ordering equipment, so that the requestors understand the timeframe for the whole activity. It meets the requirements for the key elements of a standard change.

---

Introduction of standard changes can greatly enhance the effectiveness of the change management process and increase the buy-in for the management of change within the organization, because it can be seen as improving responsiveness and efficiency and minimizing bureaucracy. Each standard change model should be approved and agreed upon prior to its use, and the records of the standard changes should be reviewed on a regular basis to ensure that there is no adverse impact from the implementation. The content of the individual change records for the standard changes will potentially vary, based on the requirement of the change itself, but it should contain sufficient detail to manage the change and provide a track record of the activity undertaken.

Emergency Change

Another change type, which has a different model, is the emergency change. This type of change is in response to or in order to prevent a business-critical error. There is the potential for the impact of a poorly handled emergency change to be greater than the incident it is attempting to solve because of tight timescales, reduced assessment, and testing of the change. The number of emergency changes should be kept to a minimum, because they are more likely than the other types to be disruptive and prone to failure. Ideally, changes should be planned, but emergencies do happen, and there needs to be a recognized approach to manage the implementation of the response. These procedures take into consideration the need for urgency but also the need to have a clear record of the actions that will be carried out in response to the emergency.

There needs to be a clear definition of the authority levels associated with emergency changes, and if that authority has been devolved (perhaps to a duty manager on a night shift or manager on call), this should be clearly documented as part of the procedures. If it is necessary, emergency changes may have to be assessed by a group of people or referred to an advisory board, which is known as the emergency change advisory board (ECAB). The ECAB is the emergency authority for assessing emergency changes covering the same responsibilities as the change advisory board, which we will review in the normal change process. Any decisions to authorize an emergency change must be documented in the change record so that there is a clear audit trail for all activities.

Once authorized, there may be no time for full testing of the build and implementation while the change is carried out. This will increase the risk of failure, so as much testing as possible should be completed. It is also recognized that during this activity, there may be little time given to the update of the change record, so there is a recommendation that the documentation is updated after the implementation.

So, the key elements of the emergency change approach are as follows:

• Authorization and assessment may be completed by the ECAB rather than waiting for a CAB meeting.
• Testing may be reduced or, in extreme cases, be missed completely, if this is an acceptable risk to resolve the emergency.
• Documentation, once the change record has been raised, may be completed retrospectively.

Emergency changes should not be carried out to address poor planning. As can be seen, the approach increases the risk of failure and may cause additional issues in the operational environment. So, they should be tightly controlled and implemented only when absolutely necessary, according to a business-critical need.

---

Normal Change

The next type of change we are going to review is the normal change. This section will cover the normal change process flow and the roles and responsibilities of the change advisory board.

The typical process flow includes these steps:

We will cover each step of the process in turn (Figure 8.1).

FIGURE 8.1 The normal change process

Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.

You can see in Figure 8.1 that there is a reference to a change proposal. A change proposal may be required if the change is potentially going to have significant and costly impact on the business. Authorizing the proposal for a change means that the wider implications can be reviewed against any other changes and proposed new services.

The proposal should include a high-level description of the change, a detailed business case including a risk assessment and profile, and an outline schedule for the design and implementation of the change. Once authorized, the proposal will be used as a basis for raising the changes required to achieve the requirement or perhaps chartering a new service.

The first step of the process is the creation of the request for change (RFC). The change can be initiated by anyone within the organization (or supported by the service provider), and this request will trigger the creation of a change record. The RFC should specify the details of the change, including the risks, benefits, costs, and proposed schedule for implementation. The level of detail required in the request will depend on the nature of the request; for example, a change requiring significant technical engagement should cover the tasks in detail. But it may be that the relevant details cannot be provided at the point of request, so there needs to be clear guidance on the minimum content required.

Raising an RFC will trigger the change record. The details and updates captured in the change record will be managed through the CMS. We cover the description and use of the CMS in the discussion of the service asset and configuration management process in Chapter 9.

Change logging is an important part of the overall change process. Keeping an accurate change record provides an audit trail for the actions carried out in the lifecycle of the change. All RFCs should be logged with a unique identifier, and where the trigger for the change is captured in another record (such as an incident or problem), the original reference number of the initiating document should be captured as part of the change record. A good service management tool will have the functionality to link these records and be able to capture the relationship between the RFC and any associated configuration items, records, and other service components. It is the responsibility of change management to ensure that the change record is created and logged correctly.

Once the change has been raised and logged, the change should be reviewed against some basic criteria to establish whether the change should continue through the process:

• Is it completely impractical?
• Has the change been raised and logged with sufficient information and appropriate budget?
• Is it a repeat of an earlier RFC or one that is still being considered, or a previously rejected request?

If rejected, the initiator must be provided with a reason for the rejection and have right of appeal through normal management channels. This review is the responsibility of the change manager but can be carried out by others if there is agreement with the change management process owner. For example, for minor changes that require authorization, often the line manager of the initiator carries out the review, ensuring that no incomplete or impractical changes are raised.

Once the RFC has been accepted into the change process, the next step is that of evaluation and assessment. If the change has a significant impact, it may require a specific and separate formal evaluation activity; otherwise, the assessment can be managed as part of the normal change process. The framework provides a set of seven questions that should be asked during the assessment of a change. These are known as the seven Rs of assessment:

• Who raised the change?
• What is the reason for the change?
• What is the return required from the change?
• What are the risks involved in the change?
• What resources are required to deliver the change?
• Who is responsible for the build, test, and implementation of the change?
• What is the relationship between this change and other changes?

Assessment should include all potential factors that may impact the success of the change. This may require the RFC to be reviewed by a number of people, and it is the responsibility of the change manager to ensure that the assessment is completed. This is where the change advisory board is used. We cover the roles and responsibilities of the CAB later in this section.

Following the assessment, the change schedule (CS) can be updated. This is an important output from the change process and shows the details of all changes authorized for implementation and their proposed implementation dates. In fact, this is both an input and an output for the process, because the change schedule will need to be consulted when considering the scheduling for new changes. The schedule should be published so that all interested parties can understand when planned changes are to take place.

The projected service outage (PSO) document should also be updated at this point, with the impact to the business of the service outages clearly identified. This allows stakeholders to understand when any additional outages outside of the agreed service level agreement will take place and when the planned maintenance outages will take place.

Both the CS and the PSO provide important information for assessing new changes. It is the responsibility of change management to ensure that these documents are available and accurate for use by the CAB as part of the assessment activity.

Another important element for assessment is the remediation plan. A remediation plan should be in place for all changes so that if the change fails, the infrastructure can be returned to normal. Often concentration is placed on mitigation against the risk of failure, which is an important part of managing a change implementation, but if that mitigation is unsuccessful, then return to normal must be considered. This may be achieved by envoking service continuity plans, or back out or rollback plans, dependent on the nature of the change.

While we are engaged in the updates to our plans for the change and producing the documented outputs, the change record is updated with the plans for executing the change. In Figure 8.1, you can see that there are workflows associated with this step. This indicates the potential requirement for additional activity outside of the assessment itself, perhaps to obtain further information to enable an informed recommendation to be made, such as a feasibility study for a proposed activity.

Once a recommendation has been made for a change to be authorized, either by the change manager or by the CAB, it is time to engage the change authority for approval for the change to be built and tested. This includes prioritization of the change among other changes and releases.

Formal authorization is granted for each change by the change authority, which may be a role, person, or group of people. The levels of authorization will be determined by the significance of the change in terms of size, risk, cost, and potential business impact. Change authorization is often dependent on the culture of the organization. In a hierarchical organization, authorization may be part of that multilevel management structure, whereas another organization may take a more streamlined approach.

However the authority is structured, once a decision is made and communicated, there should be a right of appeal for the initiator if the change has been rejected at this stage.

Following authorization of the build and test of the change, the coordination of the build, test, and implementation of the change can take place. During this stage, the change will be assessed for release, either as part of a release package through the release and deployment process or as part of operational release into the production environment. You can see in Figure 8.1 that there are workflows associated with this step in the process so that engagement of technical resources can be managed and coordinated to deliver the required activity. Change management is responsible for ensuring that this step in the process takes place efficiently.

Once the build and test has been approved, then authorization for the deployment can take place.

You can also see workflows in the diagram associated with the coordination of the deployment step, indicating that activity outside the change management process may take place. The actual work of deployment is managed through the release and deployment process. Activities to plan, create, and deploy releases are part of the responsibility of the release and deployment process. Change management’s responsibility during deployment is coordinating the activity being carried out if it is a simple change that is not part of a release.

Change management is responsible for ensuring that the changes are deployed as scheduled. The role of coordination will be shared with release and deployment management. Any release activity should be scheduled to minimize the impact to the business.

Finally, we come to the review and closure of the change. In this step, the change is evaluated to ensure that the actual performance has been achieved. If this has been realized, the change can be closed. But closure should take place only after a period of time has passed, so the true effects of the change can be assessed. All feedback should be captured and presented to the CAB or the change authority via the change process.

Where a change has not met the acceptance criteria for success, change management may identify a number of options. If it is possible, the change can undergo remediation and return to normal, or if this is not possible, then additional changes can be raised to correct any issues. These will be managed through the change process, and once the original change meets its acceptance criteria, it can be closed. It may also be agreed on that nothing will be done to achieve the original success criteria, if the business agrees that what has been delivered is sufficient to meet their needs.

Whatever the decision made, once closure has been agreed, this should be recorded as part of the change record, and the record should be closed. This is change management’s responsibility.

Throughout the process, any activities associated with the role of the change manager may be carried out by a change practitioner, a change authority or the change management process owner, or a change management team, dependent on the size and structure of the organization.

---

The Role of the Change Advisory Board

The change advisory board (CAB) is a group of people brought together to review and assess changes to determine whether they should be authorized. In some organizations, the CAB will also act as the change authority for certain levels of change, but the main role is to provide advice and guidance. The makeup of the group is entirely dependent on the RFCs that are under discussion. The membership will, therefore, potentially change for each meeting. It is important to ensure that the group consists of all those who have an interest in the outcome of the change. This should include a customer representative who can assess the business impact of a change and also a technical representative who can assess the change for the requirements relating to the infrastructure. There will be a number of stakeholders involved in the execution of the change, including suppliers, and they should also be represented as part of the CAB. You may be familiar with a CAB in your own organization or, using your own experience, be able to identify the relevant roles who might attend a CAB in your own company. It is potentially quite a large group of people, and it may be quite challenging to arrange a meeting that all can attend face to face. Some organizations address this by holding “virtual” meetings, either through conference calls or electronically via email. Others adopt an approach that has a tightly controlled meeting schedule, and the relevant people are called in for the appropriate time slot to discuss the RFC that affects them.

To ensure the meeting is productive and efficient, it is the responsibility of the change manager to circulate the RFCs for discussion prior to the meeting. This means that each person can review the RFC and gather any relevant information that will aid in the discussion and decision making.

As the assessment is carried out, it is important that the CAB has visibility of all changes that are being considered or have already been approved. This will ensure that the RFC under review can be assessed for the impact and relationship to other changes.

How the Change Management Process Interfaces with Other Service Management Processes

We begin by looking at the service transition processes that have an interface to change management, but it is important to remember that change management affects the entire service lifecycle, from strategy to continual service improvement.

There needs to be a close relationship between change management and transition planning and support so that transitions can be coordinated successfully.

Relationships between change management and release and deployment management should be carefully integrated with the project management and business change processes so that clear boundaries and dependencies can be established for transitions that involve project management. This may also include working with suppliers, so supplier management should engage with change management to ensure that all activity can be coordinated. If the change has a wide impact or scope within the organization, there may be other business processes that need to work with change management.

The process of change evaluation in the service transition phase is not covered specifically in the foundation course syllabus, but the concept of change evaluation is there to ensure that you have a review and evaluation of the actual performance of the change against the predicted performance as specified in the change proposal. Change management has to be able to integrate with change evaluation and should be able to indicate which changes are to be subjected to formal evaluation. Change management provides the trigger for change evaluation, and the timescales required for the evaluation should be part of the overall planning for the change, because the evaluation report will be an important input to the CAB or other change authority when making decisions on authorization.

When we consider the integration and cooperation between business processes, program and project management processes, and organizational change processes with change management, it is important to understand the requirements for supporting these activities even though they are outside the scope of change management. Change management representatives may be called on to attend meetings associated with these business programs so that all approaches can be consistently delivered.

Integration with other service management process is also vital for the success of change management. Many processes are going to interface with change because they will raise changes in response to either operational outages or improvement initiatives. Service asset and configuration management has very strong connections to change management, because the information it captures about the overall infrastructure provides valuable data that can be used for the assessment of change impact on the environment. Problem management raises changes and has a responsibility to attend the CAB for inclusion in the assessment activity for those changes. Processes such as information security and IT service continuity management need to be included in the change management assessment for the impact of changes on the security policies and continuity plans. Capacity and demand management are also critical in change assessment and may raise changes to address new requirements for capacity to meet altered demands. Service portfolio management provides input for the change assessment activity and may be responsible for raising strategic changes to address new requirements for the business. Service level management needs to be included in the change assessment to ensure that the agreed-on service targets will not be impacted. Availability management will also be a key process in the assessment of changes, because many of the business-critical targets will involve the availability of services.

This is only a selection of the processes that relate to change management, but it does show the breadth of engagement that change management has throughout the service lifecycle.