2 Change management process

2.1 Overview and process diagram

The process of change management is shown in Figure 1 and summarised below.

The process is initiated by the creation and submission of a Request for Change (RFC).

In line with the Change Management Policy, the following types of change will be processed:

• Standard • Normal • Emergency

This document mainly relates to the last two of these types, the normal and emergency changes.

Standard changes are low-risk, pre-approved changes and so do not need to follow the full review and approval process. Standard changes will generally be recorded in the service desk system as service requests and the implementation process of each standard change will be fully documented.

Normal changes are “business as usual” changes which are expected to make up the majority of the RFCs that are logged and handled through the change management process as described in this document. Although not emergencies, they will be prioritised in order that resources can be allocated in as effective a manner as possible.

Once an RFC has been submitted it is recorded in the change management system and reviewed for completeness and appropriateness. If acceptable it is then assessed and evaluated by the most appropriate people according to the nature and scope of the change. Major or high-risk changes may be escalated to the IT steering group or the executive board.

If the conclusion from the assessment is that the change should be authorised then it moves to the build and test stage, after which it is deployed under the control of change management. The success of deployed changes is then reviewed at an appropriate time after implementation. At each point, the CMS is consulted and if necessary, updated.

Figure 1: Change Management Process

Source: ITIL Service Transition Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS.

2.2 Process triggers

The change management process is initiated as a result of one or more of the following triggers:

• An RFC is submitted via one of the available channels • A change proposal is raised as part of the service portfolio management process

2.3 Process inputs

The process of change management requires a number of inputs in order to be able to function effectively. These may not always be available but will ideally be:

• Correctly raised RFCs • Change proposals • Business, service and technical knowledge relevant to the proposed change • Change evaluations and assessments • An indication of the prevailing risk appetite of the business and IT organization • Configuration management records • Build, test and implementation plans and status reports • Details of incidents and problems giving rise to the RFC • Details of incidents and problems resulting from the implementation of the RFC

2.4 Process activities

The individual process activities at each step are detailed as follows.

2.4.1 Create RFC

The RFC is created by the change initiator based on their requirements. RFCs may be submitted either using a template RFC form or directly into the change management system via the web portal or client software, depending on the access available to the initiator.

The minimum information specified on the RFC should include:

• Initiator name and contact details • Change title • Change description • Reason for the RFC • Business benefit of the RFC

For RFCs raised by technical staff it may be appropriate at this stage to include additional details (if available) regarding the testing and implementation plan for the change e.g.:

• Testing carried out so far with results • Back-out plan • Implementation plan • Post-implementation testing plan • Any supporting information e.g. related incident or problem references

If this information is not available at the time of raising the RFC, it will be added further on in the process.

Normal RFCs should be submitted at least two weeks before the desired implementation date but due to the diverse nature of changes the time taken to assess and authorise any particular RFC is not guaranteed.

2.4.2 Record RFC

The RFC is recorded within the change management system by the change manager (or deputy) and allocated a unique reference number. If the RFC was entered directly into the system this will have been done automatically when it was created.

2.4.3 Review RFC

Once created, the RFC is reviewed by the change manager to ensure that it is appropriate to progress to the next stage, including that:

• The initiator has the required authority to request the change • The RFC has been correctly completed i.e. all of the required information is included • It is not a duplicate of an existing RFC • It is a reasonable request e.g. it is not based on a misunderstanding about how the affected area works

The change manager may need to consult other people, including subject matter experts, in order to complete the review.

2.4.4 Assess and evaluate change

The RFC will then be assessed by a group of people appropriate to the subject of the change (the Change Advisory Board, CAB) initially to gain an idea of the significance of it. This assessment will consider the “seven Rs” of change management, namely:

1. Who raised the change? 2. What is the reason for the change? 3. What is the return required from the change? 4. What are the risks involved in the change? 5. What resources are required to deliver the change? 6. Who is responsible for the build, test and implementation of the change? 7. What is the relationship between this change and other changes?

(Seven Rs Source: “ITIL Service Transition Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS)

Based on advice from the CAB, the change manager will determine the type of assessment that should be carried out for each RFC and the level at which it will need to be authorised.

These change authority levels are summarised in the following table.

LEVEL CHANGE AUTHORITY LEVEL OF RISK/IMPACT

Level 1 Business Executive Board High cost and/or risk

Level 2 IT Steering Group Multiple services or organizational divisions

Level 3 CAB or ECAB Local service or organization

Level 4 Change Manager

Level 5 Local authorisation Low risk

Standard change

Table 1: Levels of change review and authorisation

For changes assessed to require authorisation at levels 1-3, the change manager may decide that it is appropriate to engage the formal change evaluation process.

For those changes that may be assessed by the CAB, the members may vary according to the subject of the RFC but will typically include representatives from:

• Change management (chair) • The business area affected • The IT service(s) affected • The team(s) supporting the technology involved

CAB meetings will be held weekly but frequent communication via phone, email or the change management system may be required to ensure that business requirements can be met, and changes assessed in a reasonable timeframe.

2.4.5 Authorise change build and test

If the conclusion of the change assessment is that it is acceptable in terms of risk and impact, it will be authorised by the appropriate level of change authority.

For changes assessed and authorised at levels 1 and 2 it may be the case that a project is initiated to implement the change and that service design activities are required. In such cases, liaison between the project manager and the change manager will be required to ensure that the status of the change is understood at key points in the project.

The RFC will also be prioritised so that guidance is given for the use of resources across multiple changes.

2.4.6 Co-ordinate change build and test

Once authorised, the change will be passed to the relevant team to build and test. For programming changes this may involve the creation or amendment of code and associated system and integration testing within separate test environments. For technical configuration changes, the build and test stage may consist of making such changes within a test server or network if available.

The team building and testing the change will liaise with change management and report the status of the change on a regular basis. Once ready for deployment they will inform the change manager.

2.4.7 Authorise change deployment

Once completed, the test results from the previous stage will be reviewed by the relevant change authority. Peer technical reviews may be requested where appropriate.

Authorisation will be given for the change to be implemented in a specific way and at a specific date and time. If these conditions cannot be met at the time of implementation, the change should be referred back to the change authority for re-authorisation for deployment.

2.4.8 Co-ordinate change deployment

For releases (i.e. groups of changes implemented together), the implementation will be coordinated via the release and deployment management process. For individual changes change management will provide co-ordination.

The change should be implemented at the agreed date and time and within the authorised scope. Post-implementation testing will be carried out to check that the implementation

was successful. If the change is not successful, then further actions will depend upon the actual effect of the change. The default situation will be that the change is backed out according to the agreed back-out plan but in some circumstances, it may be appropriate to raise an additional RFC to correct failed aspects of the previous one. Any such RFCs raised must go through the change management process as described here.

2.4.9 Review and close change record

After an appropriate period following the implementation of the change a review will be conducted to assess its success. This will typically be judged according to the following criteria:

• Have any incidents been raised that may be attributed to the change? • Has the change had the desired effect? • Is the change initiator happy with the change? • Are there any unexpected side-effects of the change? • Have the benefits of the change been realised? • Did the change implementation go to plan and if not, what lessons can be learned? • Were the resources allocated appropriate? • Were the costs of the change within the expected parameters? • Was the degree of testing adequate? • If the change was backed out, did the back-out plan work as expected?

For larger changes, the review may be carried out as part of the (more formal) change evaluation process.

Once reviewed, the results of the review must be recorded and the change record closed, along with any related incident or problem records.

2.5 Emergency changes

Whilst all changes likely to be required should be foreseen and planned, there will be occasions when business requirements demand that changes be made in an emergency situation. Such changes are those requests which impact on internal or external ‘live’ systems and require implementation in order to resolve (or prevent) a current high priority incident or problem.

In such cases a change request must be raised immediately even if the full change details are not available and the CAB must be notified. This is to ensure that all parties are aware at the earliest opportunity. From initial logging of the change, the principles of the normal change management process should be observed as far as is realistic, however, as an emergency changes may require swift approval from the CAB an Emergency CAB (E-CAB) meeting may be held.

If an emergency change cannot be formally authorised after reasonable efforts have been made to follow the process (e.g. out of hours) a local decision may be made as to whether this change will be implemented. However, details of the change must still be recorded, and the change management process followed retrospectively to ensure that records are maintained accurately, and the success or failure of the change can be reviewed.

Where timescales allow it, the Change Manager in collaboration with the relevant support groups will ensure the following:

• Sufficient staff and resources are available to action and support the change request • Back-out plans have been documented and passed to the change Implementer • As much testing as possible of the emergency change has been completed

When an emergency change request is logged the Change Manager will do the following:

• Assess who should form the Emergency Change Advisory Board (E-CAB) • Communicate with each member of the E-CAB by whatever means is appropriate (face-to-face, telephone, email) to obtain a combined impact assessment

The remainder of the process will then continue but under the auspices of the E-CAB rather than the scheduled CAB i.e. as quickly as possible whilst retaining control and managing risk

Changes processed as emergencies will be reviewed by the CAB on a regular basis to ensure that they are genuine emergencies and do not arise from a lack of forward planning.

2.6 Process outputs

The outputs of the change management process will be the following:

• Closed change records • Successfully completed changes • Rejected RFCs, where appropriate • Failed changes, together with relevant reviews and action plans • Updated configuration item records • Lessons learned from change reviews • Closed incidents and problems that are related to the change

2.7 Change management tools

There are a number of key software tools that underpin an effective change management process. These are subject to change as requirements and technology are updated and so specific systems are not described here. However, the main types of tools that play a significant part in the process within [Organization Name] are as follows.

2.7.1 Change management system

The change management system is a workflow system that allows the logging of RFCs directly into the process via a web interface and a desktop client. Changes are then managed and directed according to the defined process, under the control of the change manager. Tasks can be assigned to individual users for change assessment and authorisation and later on for change building, testing and implementation.

Results of all reviews can be recorded as notes within the system, along with pre-defined information at each stage of the process. Supporting information such as test and back-out plans may be attached to change records and accessed by those involved in the process for that specific change.

2.7.2 Configuration management system

The configuration management system provides the capability to link changes with the configuration items they affect, building up a change history for CIs such as servers, databases and applications. This is useful in incident management where a particular incident may be tracked back to a change made at an earlier date.

The status and version of CIs may be updated as the change management process progresses so that an accurate picture of the organization’s infrastructure is maintained at all times, even in the face of frequent change.

2.8 Communication and training

There are various forms of communication that must take place for the change management process to be effective.

These are described below.

2.8.1 Communication with change initiators

The initiator of the RFC may need to explain the rationale for the change in more detail and describe the benefits expected from it. Once the RFC is logged, the change initiator must be kept informed of its progress and ideally be given some kind of indication of its expected delivery date. After implementation, the change initiator will be a key contributor to the change review, including whether the benefits were realised.

2.8.2 Communication with change authorities

As part of the assessment and authorisation of changes, the change manager must communicate effectively with the members of the relevant change authority for that change. This will be achieved mainly via the change management system and email where appropriate.

2.8.3 Communication with IT teams

Often the implementers of a change will be one or more IT teams that support the specific area of technology involved. It is vital that they are accurately informed of the change requirements and expected benefits so that resources are not wasted, and the required results are achieved.

It is key to the change management process that the implementer(s) of a change keep the change manager informed about its progress, particularly if the build and test stage is lengthy.

2.8.4 Communication with projects

For those changes that are major in terms of their scope, risk and impact, a project will most often be used as the best method of delivery. The change manager must ensure that regular updates on progress are obtained and that all changes required as part of the project go through change management. It may be appropriate for the change manager to attend some project meetings. Similarly, it may be appropriate for the project manager to attend relevant CAB meetings.

2.8.5 Process performance

It is important that the performance of the change management process is monitored and reported upon on a regular basis in order to assess whether the process is operating as expected. The content of performance reports is set out in section 6 of this document, but it is vital that the reports are not only produced but are also communicated to the appropriate audience.

This will include the customers of the IT service and the management of IT concerning resource utilisation and allocation. Depending on the health of the process it may be appropriate to hold regular meetings with customers and IT management to discuss the performance and agree any actions to improve it.

2.8.6 Communication with incident and problem management

Some changes will have been raised in order to resolve one or more incidents and problems. The service desk manager will benefit from frequent updates on change management activity, including the timing of key changes that might give rise to further incidents. If this is the case, the service desk manager will need to inform the change manager so that this fact may be considered as part of the change review.

The change manager should inform the problem manager when changes that were raised to resolve problems have been implemented. Again, the success of the change in resolving the problem may be judged by the problem manager and input to the change review.

2.8.7 Training for change management

In addition to a well-defined process and appropriate software tools it is essential that the people aspects of change management are adequately addressed. The process requires that training be provided to all participants in order that it runs as smoothly as possible.

The main areas in which training will be required for change management are as follows.

• The change management process itself, including the activities, roles and responsibilities involved • Change management software tools such as the change management system and configuration management system • The basics of the technology and how it is implemented within [Organization Name] • The business, its structure, locations, priorities and people

In addition, training should be provided to the user population regarding how to identify and propose a change, including:

• The difference between an RFC, incident, a service request and a problem and how they are handled • How to submit an RFC via the various means available • What may be expected of them as part of change management

This training may be provided via short workshops and supplemented by on demand resources such as videos and user guides.