Assess and evaluate the change Changes that are considered to be significant

should be subject to the formal change evaluation process, as described in section 4.6. There should be well-defined criteria to determine whether this formal change evaluation is needed, and this will normally be documented in the relevant change model. A formal request for evaluation should be submitted when required to trigger the change evaluation process. If formal change evaluation is not required, then the change will be evaluated by the appropriate change authority as described in this section.

The potential impact on the services of failed changes and their impact on service assets and configurations need to be considered. Generic questions (e.g. the ‘seven Rs’) provide a good starting point.

Table 4.4 continued

Attribute on the change record RFC/change

record

Change proposal (if appropriate)

Related assets/CIs

Test results Summary and

pointer to details Change implementation details (success/fail/

remediation)

ü ü

Actual implementation date and time ü

Evaluation report Summary and

pointer to details

Review date(s) ü

Review results (including cross-reference to new RFC where necessary)

Summary

Closure Summary

74

^| Service transition processes

The seven Rs of change management The following questions must be answered for all changes. Without this information, the impact assessment cannot be completed, and the balance of risk and benefit to the live service will not be understood. This could result in the change not delivering all the possible or expected business benefits or even in it having a detrimental, unexpected effect on the live service. The questions are:

■ 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?

Many organizations develop specific impact assessment forms to prompt the impact assessors about specific types of change. This can help with the learning process, particularly for new services or when implementing a formal impact assessment step for the first time.

Responsibility for assessing each category of change should be assigned to a clearly identified change authority. It is not a best-practice issue because organizations are so diverse in size, structure and complexity that there is not a

universal solution appropriate to all organizations.

It is, however, recommended that major change is discussed at the outset with all stakeholders in order to arrive at sensible boundaries of responsibility and to improve communications.

Change management is responsible for ensuring that changes are evaluated and, if authorized, subsequently developed, tested, implemented and reviewed. Final responsibility for the IT service – including changes to it – will rest with the service owner. They control the funding available and will have been involved in the change process through direct or delegated membership of a CAB or other change authority.

When conducting the impact and resource assessment for RFCs, change management, the CAB, ECAB or any other change authority should consider relevant items, including:

■ The impact that the change will make on the customer’s business operation

■ Any associated change proposal

■ The effect on the infrastructure and customer service (as defined in the service requirements baselines, service model, SLA) and on the capacity and performance, reliability and resilience, contingency plans and security

■ The effect of the change on the organization’s green IT or sustainability plans

■ The impact on other services that run on the same infrastructure (or on projects)

■ The impact on non-IT infrastructures within the organization – for example, security, office services, transport, customer help desks

■ The effect of not implementing the change

■ The IT, business and other resources required to implement the change, covering the likely costs, the number and availability of people required, the elapsed time, and any new infrastructure elements required

■ The current change schedule and projected service outage (PSO)

■ Additional ongoing resources required if the change is implemented

■ Impact on the continuity plan, capacity plan, security plan, regression test scripts and data and test environment, service operation practices.

no change is without risk

Simple changes may seem innocuous but can cause damage out of all apparent proportion to their complexity. There have been several examples in recent years of high-profile and expensive business impacts caused by the inclusion, exclusion or misplacing of a single dot in software code.

It is best practice to use a risk-based assessment during the evaluation of a change or set of changes, for example the risk for:

■ An individual change

■ A set of changes implemented in the same change window

Service transition processes ^|

75

■ Impacting the timescales of authorized changes on change and release schedules.

The focus should be on identifying the factors that may disrupt the business, impede the

delivery of service warranties or impact corporate objectives and policies. The same disciplines used for corporate risk management or in project management can be adopted and adapted.

Appendix B describes a number of different approaches that can be taken to assess and manage risks. Each organization should have its own approach to risk management, but this will often be based on one or more of these best-practice approaches.

Many organizations use a simple matrix like the one shown in Table 4.5 to categorize risk for changes, and from this the level of change assessment and authorization required.

Example of change in a high-risk industry In one volatile and competitive business environment, the mobile telephone supply business, customers asked IT if they were now able to implement a much-needed change to the business software. The reply was that it could not go forward to the next change window because there was still a 30% risk of failure. Business reaction was to insist on implementation because, in their eyes, a 70%

chance of success, and the concomitant business advantage, was without any hesitation the right and smart move. Very few of their business initiatives had such a high chance of success.

The point is that the risk and gamble of the business environment (selling mobile telephones) had not been understood within IT, and inappropriate (IT) rules had been applied.

The dominant risk is the business one and that should have been sought, established, understood and applied by the service provider. Sensibly, of course, this might well be accompanied by documentation of the risk-based decision, but nonetheless it is necessary to understand the business perspective and act accordingly.

The risk that should be considered is the risk to the business service. Changes require thorough assessment, widespread communication and

appropriate authorization by the person or persons accountable for that business service. Assessing risk from the business perspective can produce a correct course of action very different from that which would have been chosen from an IT perspective, especially within high-risk industries.

Change evaluation

Based on the impact and risk assessments, the output of any formal evaluation, and the potential benefits of the change, each of the assessors should indicate whether they support authorization of the change. All members of the change authority should assess the change based on impact, urgency, risk, benefits and costs. Each will indicate whether they support authorization and be prepared to argue their case for any alterations that they see as necessary.

It is likely that each change or release will require authorization from change management at multiple points in its lifecycle, for example:

■ Before service design activity takes place

■ After service design is complete to authorize check-in of the service design package and start of release planning

■ After release planning, to authorize release build and test

■ After release build and test to authorize check-in of the release package to the DML

■ Before each deployment, to authorize the deployment

■ After deployment to authorize activating the release in the target environment

■ Before closure of the change to accept the final configuration.

Table 4.5 Example of a change impact and risk categorization matrix

Change impact

High impact Low probability Risk category: 2

High impact High probability Risk category: 1 Low impact

Low probability Risk category: 4

Low impact High probability Risk category: 3 Probability

76

^| Service transition processes

Not every change will require all of these

authorizations. Each change model should include information about when authorization is required.

Before each authorization the change should be evaluated to ensure that risks have been managed and that predicted and actual performance match the business requirements. Some organizations require a separate RFC for each of these steps;

others use a documented workflow to manage all of these stages with a single change request.

Section 4.6 describes a formal change evaluation process which may be used for evaluation of changes that have a significant impact, such as the introduction of a new service.

Allocation of priorities

Prioritization is used to establish the order in which changes that have been put forward should be considered.

Every RFC will include the originator’s assessment of the impact and urgency of the change.

The priority of a change is derived from the agreed impact and urgency. Initial impact and urgency will be suggested by the change initiator but may well be modified in the change authorization process.

Risk assessment is of crucial importance at this stage. The change authority will need information on business consequences in order to assess effectively the risk of implementing or rejecting the change.

Impact is based on the beneficial change to the business that will follow from a successful implementation of the change, or on the degree of damage and cost to the business resulting from the error that the change will correct. The impact may not be expressed in absolute terms but may depend on the probability of an event or circumstance; for example, a service may be acceptable at normal throughput levels but may deteriorate at high usage, which may be triggered by unpredictable external items.

The urgency of the change is based on how long the implementation can afford to be delayed.

Table 4.6 gives examples of change priorities for corrective changes (fixing identified errors that are hurting the business) and for enhancements (which will deliver additional benefits). Other types of change exist, e.g. to enable continuation of existing benefits, but these two are used to illustrate the concept here.

Change planning and scheduling

Careful planning of changes will ensure that there is no ambiguity about what tasks are included in the change management process, what tasks are included in other processes and how processes interface to any suppliers or projects that are providing a change or release.

Many changes may be grouped into one release and these may be designed, built, tested and deployed together if the number of changes involved can be handled by the business, the

Table 4.6 Change priority examples

Priority Corrective change Enhancement change

Immediate

Treat as emergency change (see section 4.2.5.11)

Putting life at risk

Causing significant loss of revenue or the inability to deliver important public services Immediate action required

Not appropriate for enhancement changes

High

To be given highest priority for change building, testing and implementation resources

Severely affecting some key users, or impacting on a large number of users

Meets legislative requirements Responds to short-term market opportunities or public requirements Supports new business initiatives that will increase company market position Medium No severe impact, but rectification cannot

be deferred until the next scheduled release or upgrade

Maintains business viability

Supports planned business initiatives Low A change is justified and necessary but can

wait until the next scheduled release or upgrade

Improvements in usability of a service Adds new facilities

Service transition processes ^|

77

service provider and its customers. However, if many independent changes are grouped into a release, then this may create unnecessary dependencies that are difficult to manage. If insufficient changes are grouped into a release then the overhead of managing more releases can be time-consuming and waste resources (see section 4.4 on release and deployment management).

It is strongly recommended that the change management schedule should be prioritized based on business rather than IT needs, avoiding critical business periods, but ensuring that required changes can be implemented in a timely manner.

Pre-agreed and established change and release windows help an organization to improve the planning and throughput of changes and releases.

For example, a release window in a maintenance period of one hour each week may be sufficient to install minor releases only. Major releases may need to be scheduled with the business and stakeholders at a predetermined time. This approach is particularly relevant in high-change environments where a release is a bottleneck or in high-availability services where access to the live systems to implement releases is restricted. In many cases, the change or release may need to be adjusted ‘on the fly’, and efficient use of change windows will require:

■ A list of possible substitutes to make use of the unexpectedly vacant slot

■ Empowerment to make and implement release decisions

■ Internal metrics that monitor (and reflect and encourage best use of) change and release windows

■ A clear understanding of any sequential dependencies and impact on users.

Whenever possible, changes should be designed, built, tested and deployed in releases.

Change management is accountable for producing and distributing a change schedule and projected service outage (PSO). The change schedule contains details of all the changes

authorized for implementation and their proposed implementation dates. It also contains estimated dates of longer-term major changes that have been authorized as change proposals. The PSO contains details of changes to agreed SLAs and service availability because of the currently planned

change schedule, in addition to planned downtime from other causes such as planned maintenance and data backup. These documents are agreed with the relevant customers within the business, with service level management, with the service desk and with availability management. The PSO may be produced jointly with other processes, including:

■ Service level management, which is responsible for negotiating and agreeing availability targets and planned outages

■ Business relationship management, which manages communication with senior management of the customer

■ Availability management, which is responsible for ensuring that the planned and unplanned downtime are within agreed targets

■ IT service continuity management, which may require planned downtime for testing and may contribute to alternative arrangements for avoiding planned downtime.

Inputs to the PSO should include:

■ The change schedule

■ Release schedules

■ Planned and preventive maintenance schedules

■ Limits for planned downtime from availability management

■ Availability testing schedules

■ ITSCM and business continuity management testing schedules

■ Information from the business relationship management and the service level management processes about the customer’s ability to accept planned downtime.

Once agreed, the service provider should

communicate any planned additional downtime to the user community at large, using the most effective methods available.

The latest versions of these documents will be available to stakeholders within the organization, preferably contained within a commonly available internet or intranet server as part of an SKMS.

This can usefully be reinforced with a proactive awareness programme where specific impact can be detected.

78

^| Service transition processes

AssessingremediAtion

It is important to develop a remediation plan to address a failing change or release long before implementation. Very often, remediation is the last thing to be considered; risks may be assessed, mitigation plans cast in stone. How to get back to the original start point is often ignored – or considered only when regression is the last remaining option.

4.2.5.5 Authorize change build and test

In document 03 - ITIL V3 2011 Service Transition.pdf (Page 87-92)