This chapter is from the book
This chapter is from the book
This chapter is from the book
Change Management
Change Management refers to the process responsible for controlling the life cycle of all Changes, where a Change is the addition, modification, or removal of anything that could affect IT services. Change Management is about controlling proposed and actual Change to all CIs in the live environment and minimizing the business disruption from Changes the business requires. It is about ensuring the question "what changed?" can be answered effectively. For information about implementation of Change Management in Service Manager 2010, see Chapter 12.
The goals of the Change Management process are to ensure that standardized methods and procedures are used for efficient and prompt handling of all Changes, to minimize the impact of Change-related Incidents on service quality, and consequently to improve the day-to-day operations of the organization.
Table 3.9 presents Change Management key terminology.
Table 3.9. Key Terminology in Change Management
|
Term |
Explanation |
|
Change |
Any new IT component deliberately introduced or modified to the IT environment that may affect an IT service level, the functioning of the environment, or one of its components. |
|
Normal/Basic Change |
Any deliberate action that alters the form, fit, or function of CIs (typically, an addition, modification, movement, or deletion that affects the IT infrastructure). |
|
Standard Change |
Change that is recurrent and well known and has been proceduralized to follow a predefined and relatively risk-free path and is the accepted response to a specific requirement of set of circumstances, where approval is effectively given in advance by policy. |
|
Emergency Change |
A Change that must be introduced as soon as possible to alleviate or avoid detrimental impact on the business. |
|
Unauthorized Change |
A Change made to the IT infrastructure that violates defined and agreed Change policies. |
|
Change category (major, significant, minor) |
Measure of a Change's deployment impact on IT and the business. This is determined by measuring complexity, resources required (including people, money, and time), and risk of the deployment (including potential service downtime). |
|
Major Change |
Major impact or resources required or impact on other parts of the organization. The change manager seeks authorization from the CAB or top IT management for approval. |
|
Significant Change |
Moderate impact or moderate resources required. The change manager consults the CAB before authorizing or rejecting the change. |
|
Minor Change |
Minor impact and few resources required. The change manager authorizes or rejects, and informs the CAB. |
|
Change priority |
A change classification that determines the speed with which a requested Change is to be approved and deployed. |
|
Configuration item (CI) |
Any component of an IT infrastructure, including a documentary item such as a SLA or an RFC, which is (or is to be) under the control of Configuration Management and therefore subject to formal Change control. |
|
Change record |
This is a record containing details of which CIs are affected by an authorized Change (planned or implemented) and how. It is created from an accepted RFC. |
|
Change log |
Log of RFCs raised showing information about each Change; for example, its evaluation, what decisions have been made, and its current status (for example, raised, reviewed approved, implemented, or closed). |
|
Change Advisory Board (CAB) |
Cross-functional group set up to evaluate Change Requests for business need, priority, cost/benefit, and potential impacts to other systems or processes. The CAB makes recommendations for implementation, further analysis, deferment, or cancellation of Changes. |
|
Emergency Change Advisory Board (ECAB) |
A subset of the CAB who makes decisions about high-impact emergency Changes. |
|
Change schedule or forward schedule of change (FSC) |
A document that lists all approved Changes and their planned implementation dates. A change schedule is sometimes called a forward schedule of change, even though it also contains information about Changes that have already been implemented. |
|
Request for change (RFC) |
A formal proposal for a Change to be made. An RFC includes details of the proposed Change, and may be recorded on paper or electronically. The term RFC is often misused to mean a Change record or the Change itself. |
Change Management helps IT professionals, teams, and organizations achieve a critical outcome: minimizing the business disruption of IT changes and ensuring the question "what changed?" can be answered.
Because resources are to be allocated to the Change Management process, the value of that process to the business has to be determined so that the resources allocated can be justified. To determine the value the organization places on the Change Management process, consider these questions:
- What mechanism do you have in place to ensure that you can handle spikes in the quantity and complexity of Changes efficiently, promptly, and consistently?
- What mechanism do you have in place to ensure that the change schedule and impact of Changes is visible and communicated to the business?
- What mechanism do you have in place to ensure that there is a balance between the business getting the Changes it needs when it needs them for agility/speed to market and IT ensuring Changes are planned, with adequate resourcing, fewer emergencies, fewer surprises, risk mitigation and contingency planning, and fewer disruptive and failed changes?
- What provisions have you made to ensure the productivity of users, customers, and IT analysts in relation to changes?
- What mechanism do you have to determine the number of Changes implemented in a given period, broken down by the reasons for the Change, by CI, by service, and so on? Do you know trends in RFCs and where they are coming from, such as the number of RFCs rejected, Changes driven by Incident, unauthorized Changes, Changes completed on schedule, Changes in backlog, Changes that go badly and must be backed out, and emergency Changes?
- What mechanism do you have in place to reduce the number of Problems and Incidents caused by Changes?
- What mechanism do you have to reduce the cost and effort required to make Changes, including the cost of failed Changes and associated rework? What provisions have you made to ensure estimated and actual time, cost, and resources required for Changes match?
- What is the negative impact on service quality of Changes, and what mechanism do you have to reduce it?
- What provisions have you made to ensure that poor Changes do not move forward, and that badly done Changes are reviewed after implementation so that mistakes are not repeated?
The value of Change Management should drive all further discussions and decisions on scope, priority, resources allocated to, and automation of the Change Management process with Service Manager.
Reporting is a means of understanding and managing the performance of the Change Management process. Although Service Manager includes out-of-the-box reporting functionality for Change Management, you can look to MOF and ITIL for further guidance and what to report, when, and why (such as the number and trend of Changes requiring back-out, unauthorized Changes, number of rejected Changes, and percentage reduction in downtime due to scheduled and unscheduled Changes).
The activities in the Change Management process are shown in Figure 3.3.
)
Figure 3.3 Change Management process activities.
Table 3.10 lists roles in Change Management and associated activities as the Change process moves from start to finish.
Table 3.10. Change Categories and Descriptions
|
Role |
Activity |
|
Change initiators/requestors |
Submits RFCs. |
|
Change manager |
Filters (assesses—for impact, resource ($ and staff), and schedule requirements—and authorizes or rejects) RFCs. Accepted RFCs become Change records. |
|
Configuration manager |
Logs RFCs. |
|
Change manager |
Allocates initial priority to Change records. |
|
Change manager |
Chooses urgent, standard, or normal path for the Change. |
|
Configuration manager |
Updates Change log. |
|
Change builder |
Builds Change and devises back-out and test plans. |
|
Configuration manager |
Updates log with progress reports. |
|
Independent tester |
Tests the Change. If failure, it goes to the Change builder; if success, the process proceeds. |
|
Configuration manager |
Updates log. |
|
Change manager |
Coordinates implementation of the change. |
|
Configuration manager |
Informs users, updates log. |
|
Change builder |
If implementation fails, implements the back-out (that is, the reversion to a previous trusted state). |
|
Configuration manager |
Updates log. |
|
Change manager |
Reviews Change. If failed, the procedure restarts; if success, closes the Change. |
|
Configuration manager |
Updates log, associates any new RFC with an old one, and closes the Change in the log. |
Table 3.11 describes key inputs and outputs for Change Management.
Table 3.11. Change Management Key Inputs and Outputs
|
Input |
Output |
|
RFCs |
Change schedule or forward schedule of changes (FSC) |
|
Incidents |
CAB minutes |
|
Problem reports |
Management reports, Change statistics Change post implementation review (PIR) reports Change process review and audit reports |
The following key questions must be answered to drive decisions when implementing the Change Management process with Service Manager:
- What is the value of Configuration Management to the business?
- What is the appropriate scope of Change Management (which CIs should be under control of Change Management)?
- Who can initiate Changes, and is there any prior screening or approval required (for example, by the submitter's manager) before an RFC can be submitted?
- What mechanism do you have in place to screen Changes, and under what circumstances are RFCs rejected?
- What fields and drop-down (enumeration) list values will you have in your RFC form?
- What prioritization scheme will be used for Changes?
- What is your Change model? (In other words, what is your policy for what will pass as a standard, major, minor, significant, emergency, or unauthorized Change?)
- What Change categories will you use?
- Will you have a CAB and an ECAB, and if so, who will be members, when will they meet, and what is the agenda?
- Who will manage the change schedule and make sure it and the impact of Changes on service availability are communicated effectively?
- Will the Self-Service portal be used for Change submittal?
- What requirement do you have for automated, rule-based change notification?
- Which metrics will you track, and which reports will you produce as a basis for managing performance? Will custom reports be required?
- What role will announcements and knowledge articles play in the Change Management process?