8.3 Basic concepts

The basic concepts of Change Management are principally process-related and managerial, rather than technical (whereas Incident Management is primarily technical, with a strong emphasis on the mechanical nature of some of the processes). This section therefore focuses on providing the information you will need to identify the most important components for your organisation.

Figures 8.3a and 8.3b represent a flowchart of basic Change Management procedures. Figure 8.4 illustrates the use of standard Change Management procedures (Change models) within the Change life-cycle.

Figure 8.3a - Basic Change Management procedures - part 1.

Figure 8.3b - Basic Change Management procedures - part 2.

Figure 8.4 - An approach for standard Change Management procedures.

A standard Change is a change to the infrastructure that follows an established path, is relatively common, and is the accepted solution to a specific requirement or set of requirements. Examples might include an upgrade of a PC in order to make use of specific software, new starters within an organisation, and PC, software and network connections for temporary or seasonal changes to requirements. The crucial elements of a standard Change are that:

• the tasks are well-known and proven
• authority is effectively given in advance
• the train of events can usually be initiated by the Service Desk
• budgetary approval will typically be preordained or within the control of the Change requester.

Once the approach has been established and documented, a standard Change process should be developed and promulgated to ensure that such Changes are efficiently processed to support the organisation's business needs.

8.3.1 Requests for Change

Requests for Change (RFCs) are triggered for a wide variety of reasons, from a wide variety of sources. The reasons include:

• required resolution of an Incident or Problem report
• User or Customer dissatisfaction expressed via Customer liaison or Service Level Management
• the proposed introduction or removal of a new CI
• a proposed upgrade to some component of the infrastructure
• changed business requirements or direction
• new or changed legislation
• location change
• product or service changes from vendors or contractors.

RFCs can be concerned with any part of the infrastructure or with any service or activity. Here are some examples:

• hardware
• software
• documentation
• telecommunications facilities
• engineering cover
• training courses
• IT infrastructure management procedures
• tactical plans
• environmental infrastructure.

RFCs can, of course, be in paper form, or - as is increasingly the case - be held electronically, perhaps on the company intranet.

The following items should be included in an RFC form, whether paper or electronic:

• RFC number (plus cross reference to Problem report number, where necessary)
• description and identity of item(s) to be changed (including CI identification(s) if Configuration Management system is in use)
• reason for Change
• effect of not implementing the Change
• version of item to be changed
• name, location and telephone number of person proposing the Change
• date that the Change was proposed
• Change priority
• impact and resource assessment (which may be on separate forms where convenient)
• CAB recommendations where appropriate (which may be held separately, with impact and resource assessments, where convenient)
• authorisation signature (could be electronic)
• authorisation date and time
• scheduled implementation (Release identification and/or date and time)
• location of Release/implementation plan
• details of Change builder/implementer
• back-out plan
• actual implementation date and time
• review date
• review results (including cross-reference to new RFC where necessary)
• risk assessment and management
• impact on business continuity and contingency plans
• status of RFC - i.e. 'logged', 'assessed', 'rejected', 'accepted', 'sleeping'.

A Release or implementation plan should be provided for all but the simplest of Changes and it should document how to back out from the Change should it fail. On completion of the Change, the results should be reported for assessment to those responsible for managing Changes, and then presented as a completed Change for Customer agreement (including the closing of related Incidents, Problems or Known Errors). Clearly, for major Changes there will be more Customer input throughout the entire process, but the main point is that, no matter how small the Change, the Customer should be consulted before any Change is implemented.

As the Change proceeds through its life-cycle, the Change request and the CMDB should be updated, so that the person who initiated the Change is aware of its status. Actual resources used and the costs incurred should be recorded as part of the record. A Post-Implementation Review (PIR) should be carried out to confirm that the Change has met its objectives, that Customers are happy with the results; and that there have been no unexpected side-effects. Lessons learned should be fed back into future Changes. Small organisations may opt to use spot checking of Changes rather than large-scale PIR; in larger organisations, spot-checking will have a value when there are many similar Changes taking place.

8.3.2 Change Advisory Board

The Change Advisory Board (CAB) is a body that exists to approve Changes and to assist Change Management in the assessment and prioritisation of changes. As and when a CAB is convened, its members should be chosen who are capable of ensuring that all Changes are adequately assessed from both a business and a technical viewpoint. To achieve this mix, the CAB needs to include people with a clear understanding of the Customer business needs and the User community, as well as the technical development and support functions. See also Paragraph 8.5.5.

It is suggested that CAB membership, when needed, should comprise:

• Change Manager
• Customer(s)
• User manager(s)
• User group representative(s)
• applications developers/maintainers (where appropriate)
• experts/technical consultants
• services staff (as required)
• office services staff (where Changes may affect accommodation and vice versa)
• contractor's or third parties' representatives (as required - for instance in outsourcing situations).

It is important to emphasise that the CAB:

• will be composed according to the Changes being considered
• may vary considerably in make-up even across the range of a single meeting
• should involve suppliers when that would be useful
• should reflect both user and Customer views
• is likely to include the Problem Manager and Service Level Manager and Customer Relations staff for at least part of the time.

When major Problems arise, there may not be time to convene the full CAB, and it is therefore necessary to identify a smaller organisation with authority to make emergency decisions. Such a body is known as the CAB emergency Committee (CAB/EC). Change procedures should specify how the composition of the CAB and CAB/EC will be determined in each instance, based on the criteria listed above and any other criteria that may be appropriate to the business. This is intended to ensure that the composition of the CAB will be flexible, in order to represent business interests properly when major Changes are proposed. It will also ensure that the composition of the CAB/EC will provide the ability, both from a business perspective and from a technical standpoint, to make appropriate decisions in any conceivable eventuality.

A practical tip worth bearing in mind is that the CAB should have stated and agreed assessment criteria. This will assist in the Change assessment process, acting as a template or framework by which members can assess each Change.

8.3.3 Change metrics

Change Management (ideally in consultation with business managers) needs to think about measures that have specific meaning. While it is relatively easy to count the number of Incidents that become Problems that become Changes, it is infinitely more valuable to look at the underlying cause of such Changes, and to identify trends. Better still to be able to measure the impact of Changes and to demonstrate reduced disruption over time because of the introduction of Change Management, and also to measure the speed and effectiveness with which the IT infrastructure responds to identified business needs.

Measures taken should be linked to business goals wherever practical - and to cost, service availability, and reliability. Any predictions should be compared with actual measurements. Section 8.7, Metrics and management reporting, provides more information.

8.3.4 The Forward Schedule of Change, and Change models

One area of Change Management that has moved on more rapidly than any other is the concept of building Change models prior to implementation. These are mostly applied to smaller standard Changes such as new or upgraded desktop equipment. Capacity Management can help also, to build large models of complex Changes in order to assess the likely impact prior to the real thing. In general, capacity model-building takes place for Changes that are out of the ordinary, either in terms of complexity or scale - or both. See also Chapter 9 (Release Management).

The issue of responsibility for the assessment of the impact of major Change should be defined. It is not a best-practice issue in that organisations are so diverse in size, structure and complexity that there is not a 'one size fits all' solution. It is, however, recommended that major Change is discussed at the outset with all parties - program/project management and Change Management - in order to arrive at sensible boundaries of responsibility and to improve communications. Although Change Management is responsible for ensuring that Changes are assessed and, if approved, subsequently developed, tested, implemented and reviewed, clearly final responsibility for the IT service - including Changes to it - will rest with the IT director, the IT Services Manager and the Customers who control the funding available. The CAB will recommend the adoption (or not) of more significant Changes, but their impact should be discussed on a sufficiently wide stage and this may well take the final responsibility beyond that of the Service Management, or indeed the IT, Change process. 'Responsibility' here covers the whole scope of the Change process and associated risk and budgetary considerations.

A concept at the other end of the scale of Change Management and Configuration Management is that of small-scale Change that can be satisfied by use of 'standard' Change models - for example, a PC exchange or a regular software update. So long as a predefined schedule has been fulfilled, together with all criteria (perhaps criteria relating to build or test processes, for example), Change Management can authorise such Changes without reference to the full Change Management processes. Figure 8.4 illustrates how a process of using standard models of Change, predefined by Change Management with the agreement of the other service support managers, can be integrated within the usual Change processes. Note that the definition of the scope or severity of the Changes that relate to use of the model are organisation specific.

The concept of scheduling Changes for implementation remains constant, however it is recommended very strongly that Change Management install Changes to meet business schedules rather than IT schedules. It was not uncommon for IT management to schedule major Changes over the weekend to minimise disruption to services, but those same managers were also likely to schedule downtime during working hours for essential maintenance. Nowadays, most managers actively avoid any scheduled downtime within service hours and ensure that the majority of Changes are scheduled in the same way, with allowance made either for major Problems that may arise through delayed implementation or for very urgent Changes.

In order to facilitate this process, Change Management should coordinate the production and distribution of a 'Forward Schedule of Changes' (FSC) and a 'Projected Service Availability' (PSA). The latest versions of these documents should be available to everyone within the organisation, preferably contained within a commonly available Internet or intranet server. The FSC contains details of all the Changes approved for implementation and their proposed implementation dates. The PSA contains details of Changes to agreed SLAs and service availability because of the currently planned FSC. These documents should be agreed with the relevant Customers within the business, with Service Level Management, with the Service Desk and with Availability Management. Once agreed, the Service Desk should communicate any planned additional downtime to the User community at large, using the most effective methods available.

If your organisation has drawn up process models of the Change Management process and integrated those models within an overall Service Support model, it is a simple task to evaluate the effect of a Change without the risk and expense of changing the process in real life. Similarly, if you can build a model of a major Change, you can elicit the help of the Capacity Management, Business Continuity Management, Availability Management and Service Level Management to evaluate the impact of the Change on services, service levels and business continuity plans. With the aid of such a model, you can evaluate the Change for completeness and construct a schedule, perhaps of Changes to be phased in if necessary, or simply to ensure that everything that should be in place to make the Change successful is in place.

Be aware that there is a considerable difference between flowcharts and process models. Flowcharts (some useful examples of which are provided in this guide), allow Change Management to view simple information flows but do not abstract 'real life'. A process model, however, provides a picture that is capable of detailed evaluation and engenders confidence. A case study at Appendix B (based on anonymised data from a major outsourcing organisation that encountered Problems in a Europe-wide implementation of IT infrastructure library processes) will help you to evaluate the use of flowcharts and process models.

By planning a Change using models and schedules to support project plans, it is possible to predict the impact of the Change. You can also look at the implementation of the plans to compare predictions with reality, both to improve future planning and to ensure that the Change proceeds smoothly. See Paragraph 8.5.9 for information about building Changes.

8.3.5 Outsourcing and Change Management

In the case of outsourcing of service provision, bear in mind that those providing outsourced services often make economies of scale by using giant mainframes and large operational/ networking organisations, or perhaps they have massive purchasing power because of the scale of their buying. In this case, the adoption of ITIL guidance is clearly going to have a major impact in terms of reducing the cost of providing services, making service provision more reliable, and improving efficiency.

When outsourcing is under consideration, the receiver of services needs to take into account the following issues concerning the Change Management process:

• who is responsible for managing day-to-day Changes arising from RFCs, from whatever sources (see Paragraph 8.3.1)?
• what control do I have over the service provider so that I am not being made to pay for unreasonable Changes?
• how do I know that Changes are not approved piecemeal, with a consequent impact on service and service cost?
• who is responsible for ensuring that major business changes are properly costed, approved, planned, controlled and implemented?
• who is responsible for the integrity of systems and services following Changes?
• has security of systems been properly considered?
• who should sit on the CAB?

It is not practical to provide general advice because outsourcing contracts vary so much in terms of:

• cost
• ownership of hardware and software
• the degree to which the business enters into a partnership with the provider (rather than a simple provider-consumer relationship)
• the nature of the services provided
• the scope of those services (infrastructure, service/help desks, applications software development, etc).

It is thus up to you to ensure that service providers (outsourced or in house) provide the Change Management function and processes that match the needs of your organisation. Some organisations in outsourcing situations refer RFCs to their suppliers for estimates prior to approval of Changes.

Perhaps the most sensible piece of advice is the most obvious: ensure that you coordinate the Change Management, Incident Management, Release Management and Configuration Management processes across all of the organisations involved in service support, delivery and management. It may be necessary to model the processes in order to make meaningful comparisons.

8.3.6 Critical outage plan

Although planning for the recovery of critical business systems is not a task that is the direct responsibility of Change Management, their involvement is not merely sensible but essential. This is because any plans to recover IT systems and services that are fundamental to the business will be subject to Change and should be controlled to ensure smooth operation.

It is, of course, also necessary to consider what should be done in the event of the plans going awry - or even if you need to back out from Changes resulting from use of the plans. In these instances, the earlier advice about planning for back-outs very early in the planning phase becomes particularly germane. Clearly, there should be a link to Change scheduling processes.