Service Management Functions

Change Management

Updated: March 26, 2004

Executive Summary

The IT environment is a dynamic one, constantly changing in response to changing business needs, the availability and introduction of new technologies, as well as normal business growth. The IT environment is also extremely complex, containing many interdependencies (often on a global scale) that have become increasingly crucial for the basic survival of a business. For these reasons, organizations require a disciplined process that can introduce required changes into this environment with minimal disruption to ongoing operations. The Change Management service management function (SMF) is designed to do this.

The organizational and infrastructural changes subject to this process include hardware, software, system components, services, documents, and processes—anything deliberately introduced into the IT environment that could affect its functioning. Often these will be reflected in the service level agreements (SLAs) existing between the IT department and the business it serves. (Note that this management process does not include changes to operational roles and responsibilities of IT personnel.)

IT personnel and named groups (who play well-defined roles) carry out the change management function, which can also be enhanced by use of technology.

This SMF guide for change management has been created in line with the processes and best practice successes that have been observed internally within Microsoft and externally with our partners and clients. Effective change management as described within this guide will enable organizations to optimize business benefit from changes to their IT environment while minimizing availability issues, costs, and risks to the production environment.

Top of page

Introduction

Document Purpose

This guide provides detailed information about the Change Management service management function (SMF) for organizations that have deployed, or are considering deploying, Microsoft technologies in a data center or other type of enterprise computing environment. This is one of the 21 SMFs defined and described in Microsoft® Operations Framework (MOF). The guide assumes that the reader is familiar with the intent, background, and fundamental concepts of MOF as well as the Microsoft technologies discussed.

An overview of MOF and its companion, Microsoft Solutions Framework (MSF), is available in the Overview section of the MOF Service Management Function Library document. This overview also provides abstracts of each of the service management functions defined within MOF. Detailed information about the concepts and principles of each of the frameworks is also available in technical papers available at http://www.microsoft.com/mof.

What’s New?

Since the release of the first version of this guide, we have received valuable feedback from our partners and clients regarding their experiences with change management, which has led us to revise some areas of the Change Management SMF. This new version focuses less on the technology used to manage and develop changes, and more on the fundamental principles for implementing a successful change management system within an organization.

These fundamental principles include the application of a more transparent change classification system and a simplified authorization process, as well as the incorporation of a less-complicated, embedded release management process. Our partners and clients have informed us that changes to these areas of change management will enable them to deliver better value from their IT infrastructure.

Feedback

Please direct any questions or comments about this SMF guide to msmfeed@microsoft.com.

Top of page

Change Management Overview

Goal and Objectives

The goal of the Change Management SMF is to provide a disciplined process for introducing required changes into the IT environment with minimal disruption to ongoing operations. To achieve this goal, the change management process includes the following objectives:

•	To formally initiate a change through the submission of a request for change (RFC).
•	To assign a priority and a category to the change after assessing its urgency and its impact on the infrastructure or end users. This assignment affects the speed at which the change will be addressed and the route it takes for authorization.
•	To establish an efficient process for passing the RFC to a change manager and the change advisory board (CAB) for approval or rejection of the change.
•	To plan the deployment of the change, a process that can vary immensely in scope and includes reviews at key interim milestones.
•	To work with the Release Management SMF, which is embedded within the change management process and manages the release and deployment of changes into the production environment. For more information about the Release Management SMF, see http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/default.mspx.
•	To conduct a post-implementation process that reviews whether the change has achieved the goals that were established for it and determines whether to keep the change or back it out.

Key Definitions

CAB emergency committee (CAB/EC). The subset of the CAB that deals only with emergency changes. It is established to be able to meet on short notice to authorize or reject changes with emergency priority.

Change. Any new IT component deliberately introduced to the IT environment that may affect an IT service level or otherwise affect the functioning of the environment or one of its components.

Change advisory board (CAB). The CAB is a cross-functional group set up to evaluate change requests for business need, priority, cost/benefit, and potential impacts to other systems or processes. Typically the CAB will make recommendations for implementation, further analysis, deferment, or cancellation.

Change category. The measurement of a change’s deployment impact on IT and the business. The change complexity and resources required, including people, money, and time, are measured to determine the category. The risk of the deployment, including potential service downtime, is also a factor.

Change initiator. A person who initiates a request for change; this person can be a business representative or a member of the IT organization.

Change manager. The role that has the overall management responsibility for the change management process in the IT organization.

Change owner. The role that is responsible for planning and implementing a change in the IT environment. The change owner role is assigned to an individual for a particular change by the change manager and assumes responsibilities upon receiving an approved RFC. The change owner is required to follow the approved change schedule.

Change priority. A change classification that determines the speed with which a requested change is to be approved and deployed. The urgency of the need for the solution and the business risk of not implementing the change are the main criteria used to determine the priority.

Configuration item (CI). An IT component that is under configuration management control. Each CI can be composed of other CIs. CIs may vary widely in complexity, size, and type, from an entire system (including all hardware, software, and documentation) to a single software module or a minor hardware component.

Release. A collection of one or more changes that includes new and/or changed configuration items that are tested and then introduced into the production environment.

Request for change (RFC). This is the formal change request, including a description of the change, components affected, business need, cost estimates, risk assessment, resource requirements, and approval status.

Top of page

Processes and Activities

Process Flow Summary

In the context of change management, change is defined as anything—hardware, software, system components, services, documents, or processes—that is deliberately introduced into the IT environment and may affect an IT service level agreement (SLA) or otherwise affect the functioning of the environment or one of its components. Changes can be either permanent or temporary. Changes can completely replace a current version of a component, either with a new component or a changed version of the component, or they can involve the installation of a completely different component or the removal of an outdated one.

Whether permanent or temporary, new or revised, all changes falling under this definition must be managed by the change management process. Change management should manage all changes within the IT environment. This is important because changes may:

•	Affect multiple users.
•	Potentially disrupt mission- or business-critical services.
•	Involve hardware (such as servers or networking equipment) or software modifications.
•	Affect data stored in IT systems. (This is dependent on the type of data—for example, updating a price list on an e-commerce website should be controlled by the change management process, whereas updating customer information in a company’s database would not be controlled in this way.)
•	Involve operational and process modifications that affect multiple users.

Change can be graphically represented as a process flow diagram that presents the key tasks needed to be performed in order to successfully deploy a change.

Figure 1. Change management process flow

This high-level diagram can be further organized to provide detailed end-to-end process descriptions that, if followed, provide the comprehensive blueprint for the change management process. Diagrams illustrating these detailed change management processes are included throughout the rest of this Change Management SMF guide.

Note The release management process is embedded into the change management process; further information on the specifics of release management can be obtained from the Release Management Service Management Function Guide, which is available at http://www.microsoft.com/mof.)

Change Request

Typically, any person within a business environment can request a change and, by doing so, become a change initiator. Because the pool of potential change initiators is large and consists of people with varying degrees of familiarity with the procedures involved, a process is required that produces change requests of consistent quality and completeness and discards irrelevant requests.

Although a change request can be requested by anyone in the business, it is typically initiated and submitted by one of the MOF Team Model role clusters. Normally, each role cluster submits requests for changes relating to its area of responsibility.

Table 1. Customary Types of Requests for Change by Team Model Role Cluster

Role Cluster	Type of Change Request
Infrastructure	New systems and improvements to existing systems and infrastructure.
Operations	Changes that affect or improve day-to-day operations of the technology.
Partner	Third-party and supplier-related changes—for example, changes to an outsourced partner system affecting in-house systems.
Release	Changes to the change, configuration, and release management systems and processes.
Security	Changes to security processes—for example, authentication or network security improvements.
Support	Changes enabling incident and problem resolution and changes to the help desk system.
Service	Changes driven by new service level requirements, service improvement projects, or business strategy.

The process for requesting a change is shown in Figure 2.

Figure 2. Change request process flow
See full-sized image

A need for change, whether it is an improvement to or phasing out of an existing service or the creation of a new one, drives the change management process. Within a controlled change management process, these needs all prompt the creation of a request for change (RFC). The RFC is a standard document in which all relevant information about the proposed change is recorded, ranging from basic facts about the change (for example, change to a field name on a data base system) to more detailed information, such as the wider-reaching effects of the change (for example, the systems that interact with or report on the changed field name).

The RFC must answer the what, why, who, when, where, and how questions of the proposed change. It must describe the change, the effort it will take to implement the change and by whom, the method of implementation, and the configuration items involved. It also includes supporting information about the purpose of the change, its impact on the organization, the backout plan in case of failure, the cost of the change, the budget approval sign-off if necessary, and the urgency of the proposed change. It should contain sufficient information to allow the change manager to quickly and accurately assess the change at the initial screening stage and again at its official review stages for approval or rejection.

The RFC should be created in a standard format, which ensures that the change initiator provides sufficient information to the change manager and subsequently the CAB to enable them to decide whether to implement the change. Using a standard format also forces the change initiator to identify and fully document the scope, implications, and risks of the change being requested, as well as the plans for recovery should the change be unsuccessful. In many cases, the change initiator will not know or fully understand the implications of the change. For this reason, the RFC needs to be considered by all of the MOF Team Model role clusters to determine the change’s possible impact on IT operations.

The RFC becomes the point of reference for all activities associated with the change. Using a standard format, such as a template in Microsoft Word, a Microsoft Outlook® mail form, a Microsoft InfoPath™ form, or a Web form, which can be easily accessed by all interested parties at any time, can be useful.

To aid the change management process, the RFC form can have validated, mandatory, and optional fields for completion to ensure that essential information is completed as early as possible and to reduce the need to return the RFC to the initiator for further information before it can be reviewed.

Create a Request for Change

A person (the change initiator) who wants to make a change to any part of the IT infrastructure governed by the change management process begins the process by completing an RFC. Events that typically generate an RFC include:

•	A proposed resolution to an incident or problem.
•	User or customer dissatisfaction expressed through a customer liaison (often the service desk) or from service level management metrics prompting an improvement to the service.
•	The proposed introduction or removal of a configuration item (CI).
•	A proposed upgrade to some component of the infrastructure.
•	Business strategy influencing the requirements from IT.
•	New or changed legislation prompting service changes.
•	Physical location changes.
•	Product or service changes from vendors or contractors.

The change initiator may be in the right position in the business to submit the change, but may not always be familiar with the IT environment itself. In these instances, a change owner from the IT environment should be assigned who will be able to provide the necessary information relating to the technology specifics of the change for the RFC.

RFC Information

When completing the RFC, the change initiator should provide as much of the following information as possible:

•	The change initiator’s name, position, and contact information.
•	The change owner’s name, position, and contact information.
•	Description of the change, that is, a full account of the nature of the change.
•	A suggestion for the priority and category of the change based on the information available.
•	Problem report (PR) number of any problem that relates to the change, or incident numbers, if known.
•	Description and identity of any items to be changed, including identification of the CIs.
•	Reason for the change.
•	A cost-benefit analysis of the change and budgetary approval, if required.
•	Implications of not implementing the change, including any SLA that is at risk.
•	Impact and resource assessment, that is, which users will be affected and how big the effect.
•	Location of the release and a suggested implementation plan with timescales.
•	Backout plan including triggers and decision-maker contact details.
•	Impact on business continuity and contingency plans.
•	Risk involved in making the change.

The change initiator might also need to provide supporting documentation, such as the business case, cost-benefit analysis, or proposed implementation plan, to the change manager and others involved in the change approval process.

Two of the RFC items in the change initiator’s list—the recommended or proposed change priority and category—merit further explanation.

Change Priority

There is often a degree of confusion surrounding the definition of priority; the dictionary definition states: “Precedence, especially established by order of importance or urgency.”

In the change management process, the urgency is determined by how quickly a change is required by the business.

There are four recommended levels of priorities:

•	Emergency. A change that, if not implemented immediately, will leave the organization open to huge risk—for example, applying a security patch.
•	High. A change that is important for the organization and must be implemented soon—for example, an upgrade in line with new legislation requirements.
•	Medium. A change that should be implemented to gain benefit from the changed service—for example, between versions upgrade to a customer feedback service.
•	Low. A change that is not pressing but would be advantageous—for example, a “nice to have” addition to a user profile.

These priority levels have been defined according to industry best practice. However, depending on organizational size, organizational structure, and the underlying SLAs existing between the IT department and the business it serves, organizations might need to modify their own priority definitions. In some organizations, for instance, if the individual who wants to add the “nice to have” addition to his or her user profile works in a business-critical area, then the change may be perceived as being a high priority. Conversely, if that same change is requested for a business area that is being phased out, the change may be perceived as a low priority. It is essential that each organization consider the correct use of these priorities for its own environment, since these priorities determine when and how the change is to be implemented. They also determine the order in which change requests are reviewed.

It is important to note, however, that an emergency priority change differs from the other change priorities in that it takes a different path through the review process in order to implement the change as quickly as possible. This priority is reserved for only those changes that, if not implemented quickly, might seriously affect service levels or result in a large cost to the business. Emergency changes must be kept to an absolute minimum due to the increased risk involved in implementing them; their use should not replace good planning practices.

Change Category

Whereas the priority of a change indicates how urgently a change is required to be implemented, the category of a change is used to define the change’s impact on the infrastructure, users, or business. For example, does the change affect one user, a department, or every user in the organization? Does the change involve updating a single switch, or is it a complete overhaul of the network? The answers to such questions determine the category of the change.

As with priorities, the decision of what constitutes each category of change is determined by the individual organization. As a suggestion, the following categories have been used effectively in other organizations.

•	Major. A change where the impact on the group could be massive—for example, a departmental or corporate-wide change, or a network-wide or service-wide change.
•	Significant. A change where the effect is widespread, but not massive—for example, a change affecting a group within a department or a specific group of CIs.
•	Minor. A change affecting small numbers of individuals or CIs—for example, a change to a printer used by a department consisting of just a few members.
•	Standard. A change that has been performed before and is part of the operational practice of the business—for example, an update to a user profile.

As with the change priority, the change category is also tied to the specific organization. A change affecting a particular department may be deemed significant in some organizations but may only be considered a standard category in another organization in which that department is regarded as less critical to the business. The same is true for changes to the delivery of specific services or the use of certain products. The information for defining the categories should be gathered from the Service Role Cluster, service catalog, and Service Level Management SMF.

One category of change that needs special attention, however, is called a standard change in this guide. A standard change falls at the bottom of the category scale in that its impact is low in terms of effect on users or infrastructure. The effort required to implement it is also relatively small, and its risk to the environment is correspondingly low.

A set of standard changes and standard procedures for implementing them is normally predefined by the change advisory board (CAB). This set of standard changes can be automatically approved without needing to be voted upon by the CAB or the change manager, thereby taking a shorter route through the change approval process. Only changes that fall into the predefined standard set can be classified as such. Examples of standard changes include regularly scheduled maintenance, frequently performed administrative tasks (such as profile changes), and lesser service requests.

Submit the RFC for Approval

The change initiator documents all the information necessary to describe a proposed change and submits the RFC to the change manager. (The change manager role is one of the roles included in the Release Role Cluster of the MOF Team Model. See the MOF Team Model for Operations paper for more information about role clusters.) In order to provide an initial level of screening and “reality” checking of RFCs, the number of users in an organization who have the authority to submit RFCs should be limited. If other users wish to initiate an RFC, someone else must first approve it before it can be formally submitted and passed to the change manager.

Screen RFC

Following its submission, the new RFC must be screened. This screening process is not concerned with the validity or approval of the change request, but determines whether a decision to authorize or deny the change can be made based on the information in the RFC and any references made by the RFC.

This initial screening must be carried out by someone who has been given the authority to screen an RFC or by the initiator’s manager. Such a chain of pre-approvals should be kept short—otherwise it becomes an administrative and logistical burden, subject to error.

This screening process should include:

•

A reality check to ensure that the RFC is appropriate. Because any user can create an RFC, it means that RFCs might be generated that are:

•	Not relevant to the IT change management process.
•	Not detailed enough.
•	Not fully understood as to their implications.
•	Not completed correctly due to the change initiator’s lack of knowledge of the change management process.

•

Addition of missing information needed by evaluators to fully understand the impact of the change (for example, impact analysis results from the change management database).

•

Reclassification of the priority and category if appropriate. If an RFC has been submitted as a standard change, for example, but does not conform to one of the predefined types of standard change, then it must be reclassified.

The person designated to screen RFCs is responsible for carrying out the screening of the RFC and other actions within a set period of time, depending on the priority of the requested change. Emergency changes should have a much shorter time limit for screening than non-emergency changes. These times are defined in an SLA. For those times when the change manager is unavailable or otherwise unable to screen RFCs within the set time limit, a change manager deputy or deputies should be designated and given the authority to act in the change manager’s place.

If the RFC is not screened within the set time limit, it should be automatically escalated to someone who has been designated as an alternate screener. This notification can be done through e-mail. If appropriate, this e-mail could also be copied to the IT executive committee or another escalation path. The details should also appear on a monthly escalation report to enable higher-level visibility. The fact that the RFC was not screened within the defined time limit should be added to the change log for that RFC.

If the person designated to screen RFCs determines that the RFC does not contain sufficient information for a decision to be made, the RFC is returned to the change initiator. The change manager specifies in the change log the additional information that is required and the reasons for needing it. The RFC status is set to pending and the change initiator should be informed. The change initiator can then add more information to the RFC and resubmit it, at which point the timeout period for screening restarts.

In the case of an RFC that has been returned for more information, the change initiator should resubmit it in a timely manner to prevent a build-up of pending RFCs awaiting resubmission or initial screening.

If the screening determines that the RFC has enough content and supporting information to warrant the discussion and authorization of the change, then the change log is updated and the change initiator is informed, and the RFC passes to the change classification stage.

Once an RFC has been screened, the change manager assigns it an ID for tracking purposes and records the fact the RFC has passed screening in the change log. The change log is a key component of change management and ensures all changes are controlled and reportable by the change manager. It acts as the repository of a detailed history of all changes—from RFC creation to change release or cancellation—and is updated with each change in status of the RFC. Organizations may decide to have the change log be a separate database or contained within the CMDB.

Summary

In summary, the process for requesting a change consists of the following steps:

•	The change initiator creates and submits a full account of the change needed in the form of an RFC.
•	A designated screener determines whether there is sufficient information present in the RFC for it to be authorized.
•	If sufficient information is not present, the screener returns the RFC to the initiator for more details to be added where required.
•	This cyclical process results in a screened RFC ready for entry into the change classification process.

Change Classification

At this stage, the change request has passed the initial screening although it has not yet been approved. The next requirement is to classify the priority and category of the change. Even though the priority and classification have been entered by the change initiator, the change manager or a designated deputy reviews them and has the authority to change them if necessary.

The process for change classification is shown in the flow chart in Figure 3 and indicates the path that the RFC will take through subsequent processes. (All the action on the flow chart is performed by the change manager or deputy.)

Figure 3. Change classification process flow

Set RFC Priority

The change manager reviews the RFC priority level suggested by the initiator and accepts or changes it. The priority level of the RFC affects how quickly the CAB will review the change request and how soon it will be implemented if approved. The change manager oversees all changes submitted and thus is in a good position to adjust the priority of the RFC compared to the priority of other RFCs.

Due to its direct effect on the order and timing of the review and implementation processes, setting priorities is extremely important. It is particularly important to assign the emergency priority classification to those changes calling for it since it expedites their path through the change process. This is also the point where RFCs that have been incorrectly prioritized previously are resubmitted to the change manager for reevaluation. The change manager may adjust the priority if he or she does not think the priority suggested by the change initiator is correct or if a change having an emergency priority was not deemed to be an emergency by the change advisory board emergency committee (CAB/EC).

If the change manager adjusts the priority, he or she also records the adjustment in the change log, together with the reasons for it. In all cases, the change log should record the adjusted priority of the change, along with the name and contact details of the change manager making the decision.

Change Priority Classifications

As mentioned previously, priority is derived from the need for the change. The priority rating is used to decide how quickly changes will be evaluated and implemented. Although each organization can define its own priority levels, the following table further illustrates the four-level classification system summarized in the change request phase.

Table 2. Suggested Best Practice Priorities for Change

Priority	Priority Definition
Emergency	Causing loss of service or severe usability problems to a large number of users, a mission-critical system, or some equally serious problem. Immediate action required. Emergency meetings of the CAB or CAB/EC may need to be convened. Resources may need to be immediately allocated to deploy such authorized changes.
High	Severely affecting some users or having an impact upon a large number of users. To be given highest priority for change building, testing, and implementation resources.
Medium	No severe impact, but rectification of an incident cannot be deferred until the next scheduled upgrade, for example. To be allocated medium priority for resources.
Low	A change is justified and necessary, but can wait until the next scheduled release or upgrade. To be allocated resources accordingly.

In the case of an emergency change being submitted, the change will immediately follow the specific fast-track path to be authorized by the CAB/EC as described later in this guide.

Set RFC Category

As with change priority, the change manager reviews the change category of the RFC submitted by the change initiator and accepts it or changes it as needed. Because several different tools and technologies may be needed to perform this task effectively, the change manager may call on subject matter experts (SMEs), technical experts, and third-party suppliers (as needed) to assist in the change categorization. To identify the IT components that will be affected by a change, for example, impact analysis needs to be performed on the CMDB. Information stored in Microsoft Systems Management Server (SMS) or Microsoft Active Directory® directory service may also provide information relevant to the change category.

The change category determines the path that most RFCs will take through the change management process. Standard changes, however, take a slightly different path compared to the other change categories in that they are automatically approved. The change manager must ensure that a change that has been classified as standard matches one of the change types predefined by the CAB as a standard change and is therefore safe to preapprove for deployment.

In all cases, the change log should record the category of the change along with the name and contact details of the change manager making the final decision.

Change Category Classifications

Whereas the change priority indicates how quickly a change should be implemented, the change category, as explained earlier, is a measure of the size of the change’s impact on users, the business, or the IT infrastructure. Organizations can tailor their change categories to their own needs. However, the following table illustrates a possible means of distinguishing the four categories and supplements the information provided in the change request phase.

Table 3. Possible Classification for Change Categories

Category	Category Definition
Major	Involves potential impact on the highest percentage of users or a business-critical system. The change may be new technology or a configuration change. It may involve downtime of the network or a service.
Significant	Affects a high percentage of users. The change is a nonstandard change, such as a new product, new users, or network changes, and may involve downtime of the network or a service.
Minor	Affects a smaller percentage of users and risk is less because of the organization’s experience level with the proposed change.
Standard	Affects the smallest percentage of users and has a set release process.

Summary

In summary, the change classification process:

•	Classifies the priority of the change by the urgency for the RFC to be deployed in terms of business need.
•	Classifies the category of the RFC by the nature of the change to be performed in the RFC.
•	Defines the path to follow for emergency changes, which go straight to the CAB/EC.
•	Defines the path for standard changes that have been preauthorized.
•	Defines the path for other changes for approval from the change manager, CAB, or CAB/EC.

Change Authorization

After a change has been correctly prioritized and categorized by the change manager, the change must be authorized. The process of authorizing a change request depends upon the category and priority of the change:

•	Emergency priority changes are escalated to the CAB/EC for fast-track approval.
•	Standard changes are approved automatically and progress directly to the change development and release phase.
•	Minor changes can be approved by the change manager without reference to the CAB.
•	All other changes must be approved by the CAB.

These approval processes are discussed in greater detail below. In each case, the appropriate person or body makes a decision on whether the change should be implemented based on the information supplied in the RFC.

If the RFC is rejected and the change is not approved, the RFC is closed and the change initiator is informed of the decision. The reasons for the rejection are added to the change log. After it has been closed, an RFC cannot be reopened. If the change initiator wishes to resubmit the request, he or she must open a new RFC, make reference to the original, rejected RFC, and add any additional information that is necessary to get the request approved. The recorded reasons for the denial of the original RFC should give an indication of the extra information that might be needed. All SLA timings defined for the different stages of the change process (for example, time to initial screening) are restarted because it is a new RFC. If the RFC is time critical, the resubmitted RFC may need to be given an increased priority over the original due to the delays incurred during the processing of the original request.

The activities of the MOF Team Model role clusters within change authorization depend on the size and nature of the change. Table 4 provides examples of each role’s involvement:

Table 4. Involvement of MOF Team Model Role Clusters in Change Authorization

Role Cluster	Standard Change	Minor Change	Emergency Change	Significant and Major Change
Infrastructure	Preauthorized	Not involved	CAB member	CAB member
Operations	Preauthorized	Not involved	CAB member	CAB member
Partner	Preauthorized	Not involved	CAB member	CAB member
Release	Authorize	Authorize	CAB member	CAB member
Security	Preauthorized	Not involved	CAB member	CAB member
Support	Preauthorized	Not involved	CAB member	CAB member
Service	Preauthorized	Not involved	CAB member	CAB member

Authorize Standard Changes

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 password changes or updates to certain document templates. The crucial elements of a standard change are:

•	The tasks are well-known and proven.
•	Authority is effectively given in advance by the CAB.
•	The change process can usually be initiated by the service desk.
•	Budgetary approval is typically preordained or within the control of the initiator.

Standard changes are automatically approved and move straight to the change deployment phase of the change management process (see the Change Development and Release section). Because the types of changes that have been preapproved as standard changes are known to have a low impact on the environment and are a low risk to it, they do not need to be reviewed again by the CAB or even the change manager. This, however, means that care must be taken during the initial screening to ensure that a change request that has been categorized as standard is, indeed, one of the preapproved change types.

Authorize Minor Changes

A minor change is one that falls near the end of the categorization scale—one that has a low impact and risk. It differs from a standard change in that although the risk is low, the change may not have been performed before and therefore has to be approved. What actually constitutes a minor change depends upon the criteria chosen by the organization. Because the impact and risk of a minor change are low and the requirement for resources to implement the change is small, a minor change does not need to go before the CAB for approval. Instead, the change manager has the authority to approve or reject the change. The change manager still has the option to present the RFC to the CAB if he or she thinks it necessary.

The process of authorization of minor changes by the change manager is shown in the flow chart in Figure 4.

Figure 4. Process flow for authorization of minor changes by the change manager
See full-sized image

If the information in the RFC is not sufficient to allow the change manager to make a decision, the change manager should contact the change initiator to obtain the required information.

When sufficient information is available to make a decision, the change manager applies the usual criteria for accepting or rejecting the RFC. Applying these criteria should provide answers to the following questions.

•	Is the change necessary?
•	Do the benefits of the change outweigh any risks of destabilizing the environment?
•	Is the cost acceptable?

Because only minor changes are approved by the change manager alone, this process should be fairly straightforward and clear. Any doubt over whether to approve the RFC should result in a change to its category and escalation to the CAB.

The change manager records the decision whether to approve or reject the change in the change log. If the change is rejected, the change manager adds the reasons for doing so in the change log, closes the RFC, and informs the change initiator. If the minor change is approved, the change initiator is informed and the change request moves on to the change deployment phase. Although the CAB is not involved in the approval of minor changes, the change manager should still inform them of the change at their next meeting.

It is useful if the change manager reports RFC status by using such simple queries as “display all major RFCs awaiting approval,” “display all minor changes,” or “display all standard changes in progress.”

Authorize Significant and Major Changes

As discussed above, any changes other than standard changes and minor changes must go before the CAB for approval. Because of the impact of such changes on the IT environment or the number of users who will be affected, these changes cannot be authorized by a single individual. The individual might not understand the full impact of the change or might not understand the impact from the point of view of a particular function within the organization. For example, the individual might not understand the implications of a change on security, capacity, or service levels. The CAB, on the other hand, has a broad membership that possesses enough cumulative knowledge to fully understand the implications of the change.

The CAB authorization process for significant and major changes is shown in Figure 5.

Figure 5. Process flow for authorization of significant and major changes
See full-sized image

Select CAB Members

A request for a significant or major change must go before the CAB, and the change manager must decide who should sit on that board to review this particular RFC. CAB members must be selected for each RFC, because the most appropriate people to review the requested change will depend on the exact nature of the RFC. The CAB includes a number of standing members who always sit on the CAB (or who have deputies who sit in their absence) and review all RFCs submitted to them. In addition to these, the CAB should include personnel and experts who are from departments affected by the change or who can add value to the discussion of the change. These additional members are chosen on a case-by-case basis. The CAB should contain at least one member from each role cluster as defined in the MOF Team Model.

The standing members of the CAB typically includes:

•	Change manager.
•	Customers or business manager representing the customer.
•	User managers or user group representatives.
•	Experts/technical consultants.
•	Security expert.

Other roles that may be required to participate in the CAB for some changes include:

•	Network infrastructure representative.
•	Applications developers/maintainers.
•	Services staff.
•	Office services staff (where changes may affect accommodation and vice versa).
•	Contractor or third parties’ representatives as required (for example, in outsourcing situations).

The process of selecting CAB members can be made easier by drawing up a CAB membership list for each type of change—for example, network infrastructure change, facilities change, new application, new data, operating system fix/upgrade, or desktop fix. For each change being reviewed, CAB members can be selected from the standing list and the optional lists. Individuals can be added or removed as necessary. The total number of CAB members should still be limited in order to make the CAB meetings more efficient and manageable.

The CAB normally meets on a regular basis—for example, weekly. The standing members always attend or send deputies who are authorized to make decisions in their place.

Notify CAB Members

Change advisory boards are normally convened on a weekly basis with all standing members or deputies present. Additional CAB members are normally notified of meetings that concern them through telephone calls or e-mail messages.

When the change manager has selected the CAB members who will review the change, the RFC is ready for review.

A few days before the CAB meeting, the change manager can send out a meeting notification and summary e-mail to all CAB members. The suggested contents of this e-mail are as follows:

•	Date, time, and location (if relevant) of the meeting.
•	Format of the meeting. As an alternative to holding face-to-face meetings, CAB meetings may be held using Microsoft NetMeeting® conferencing software or by telephone conference calls. NetMeeting is preferred because it enables CAB members to share documentation and use electronic whiteboards.
•	The reviewing order for RFCs (agenda). CAB members may be interested in only a small number of the proposed changes and might join the meeting only when necessary.
•	A link to all of the RFCs being reviewed at the meeting and a forward schedule of the change calendar for discussion. Note The meeting notification must be sent to the attendees sufficiently far in advance to enable them to review the RFCs before the meeting.

Affirm or Modify Voting Logic

After the CAB members have been selected and notified, the method by which they will approve the change must be determined. In an ideal world, a change request would get unanimous CAB approval. However, there will be changes that are controversial and changes where the risk/benefit balance is inconclusive. In such cases, the change manager must designate the voting criteria for approving the change prior to the CAB meeting so that everyone understands the rules before a vote is taken.

To define the voting process, a number of pieces of voting “logic” can be used either alone or in combination with one another. The change manager is responsible for establishing what voting logic the organization will use for change approvals and then applying it to each individual change. Examples of voting logic topics that might need to be addressed include the following:

•	Unanimous/majority decision/abstentions. Does the change require approval of all members of the CAB, that is, would a single vote for rejection cause rejection of the RFC? Or is a majority of approval votes sufficient to carry the change and, if so, what should be the size of the majority? Should abstentions be allowed, particularly when a unanimous decision is required?
•	Vetoes. Do any members of the CAB have the right to veto, meaning that if they reject a change, then the rejection stands, regardless of the size of the majority vote for the change? For example, the security manager’s veto might have such weight for any RFC concerned with changes to an external website. Similarly, a decision allowing the approval of a change despite a majority vote against it should not be permitted.
•	One “group,” one vote. The CAB is often made up of (potentially) a number of representatives from specific groups within the organization—for example, several people from the networking team might attend the CAB meetings. In cases like this, only one vote should be allowed from the networking team. This maintains the balance of the voting system.
•	Quorum/required voters. Should there be a minimum number of people attending the CAB meeting and voting in order for an approve/reject decision to be made? This should be considered in case some CAB members are unable to attend a meeting or provide deputies, in which case a decision might be made by a small set of unrepresentative people.

A voting logic should be in place that applies to all RFCs by default. For example, “a 75 percent majority vote is required, all standing CAB members must be present and vote, and the security manager can always block a change.” This logic can then be adjusted on a case-by-case basis by the change manager. Such adjustments will depend on the type of change and who is sitting on the CAB for that change.

The actual vote should ideally take place electronically. In face-to-face meetings, it can be difficult to enforce the defined voting rules and to keep the discussions neutral. Voters could be swayed by perceived intimidation (for example, someone with a more aggressive or extroverted personality might force his or her opinion on others) rather than on the facts and the merits of the change.

The change manager records the voting logic that applies to the RFC in the change log.

If the CAB is using a virtual format, the change manager can use voting forms to define the number of votes needed to approve the change (majority or percentage) and to identify the groups or individual members of the CAB who have the power of veto, although the same measures may not always be suitable for use in face-to-face CAB meetings.

CAB Members Review the RFC

Each RFC on the agenda is reviewed by the CAB at the scheduled meeting. The change manager schedules, coordinates, and facilitates all CAB meetings. For each RFC review, the change manager must first ensure that the required quorum of voters is present at the meeting, that is, that all the required voters (or deputies) and the minimum number of voters are present, as defined by the voting logic for the RFC. If a vote cannot take place, the change manager must reschedule the review, and the RFC is placed in a pending state until then. The review can be deferred to the next scheduled meeting if time constraints allow. If not (for example, because the change must be made before the next scheduled meeting), then the change manager must arrange an extra meeting to review the RFC and possibly increase its priority.

Note CAB members do not have to be present for the entire meeting. They may join to discuss and vote on the changes that concern them, and leave as appropriate.

Change initiators are normally present at the CAB session that considers their proposed change. They may be requested to obtain additional information and then to re-present the RFC, or additional supporting information might be required from some other member of the CAB. For example, more detailed information about the security implications of the change might be needed from the security manager, or data about the wider impact on service levels might be required from the service manager. The CAB then schedules another meeting to review the new evidence and places the RFC in a pending state while the information is being obtained. The change log is updated with the request for more information and the date and time of the next review.

The CAB may also want to make changes to the RFC. Because change initiators must agree to any alterations, their presence at the meeting will speed up the decision on the RFC in light of these alterations.

When reviewing the RFC for impact and resource requirements, the CAB should consider the following items:

•	The impact that the change will have upon the business operation.
•	The effect upon the infrastructure and customer service, as defined in the SLA, and upon capacity and performance, reliability and resilience, contingency plans, and security.
•	The impact on other services that run on the same infrastructure (or on software development projects).
•	The impact on non-IT infrastructures within the organization—for example, security, office services, transport, and help desks that serve business customers.
•	The effect of not implementing the change.
•	The IT business and other resources required to implement the change, including the likely costs, the number and availability of people required, the elapsed time, and any new infrastructure elements required.
•	Additional ongoing resources required if the change is implemented.

Based upon these assessments and the potential benefits of the change, each of the CAB members should be able to decide whether to approve the change.

The use of technology may allow CAB members to review and vote on an RFC without meeting in person. In cases where face-to-face meetings with all interested parties are impractical because of scheduling or distance restrictions, NetMeeting can be used. NetMeeting allows remote members to share documents, use an electronic whiteboard, transfer files, and hold text conversations. Note that NetMeeting can also be used to host voice and video conversations, if required.

CAB Members Vote on the RFC

After all necessary information has been presented, any agreed upon alterations to the RFC have been made, and discussions have been completed, the CAB votes on the change according to the defined voting logic.

For some changes, the CAB may determine that it does not have the authority to approve the change. For example, the CAB members may not have the required budgetary authority, or their span of authority may not encompass the anticipated business impact. In this case, the change request is escalated to the IT executive committee (ITEC), and the change log is updated accordingly by the change manager, who should include an objective executive summary containing the reasons for escalation and any relevant supporting documentation. The ITEC is a management committee with the budget and resource authority to make decisions about proposed major and significant changes within the IT environment. ITEC’s decision is final, and a representative from ITEC notifies the change manager of ITEC’s decision after it has been made. (The procedure for how the ITEC meets, reviews the change, and reaches its decision is not discussed here.)

When the CAB is able to approve or reject an RFC, they update the change log and inform the change initiator and all interested parties of the decision. If the decision is deferred to ITEC, its decision is again sent to the change initiator and other interested parties.

Authorize Emergency Changes

The emergency change process, which enables an organization to continue normal operations or restore them as quickly as possible, is an accelerated process that follows the normal change process to the extent that time constraints permit. Emergency changes need to be implemented quickly—for example, to prevent a potential security breach or fix a business-critical application. Because emergency changes are generally more disruptive and often prone to failure, the number of proposed emergency changes should be kept to an absolute minimum. Time constraints allow only limited testing and require that normal processes and controls be bypassed. Therefore, an emergency change needs to be fast-tracked through the change management system. Emergency changes cannot be authorized by a single individual and must be approved through a change advisory board emergency committee (CAB/EC).

The CAB/EC has the same purpose and performs the same functions as the regular CAB. The differences are that the CAB/EC membership is smaller than the regular CAB, and the CAB/EC is able to meet and make decisions at short notice. The CAB/EC must be empowered to make quick decisions without having to refer to the ITEC and must have the full authority to approve or deny emergency changes.

The process flow for emergency changes is shown in Figure 6 and is similar to the process followed for nonemergency changes.

Figure 6. Process flow for authorization of emergency changes
See full-sized image

Select CAB/EC Members

The CAB/EC membership consists of a number of standing members, plus other members, depending on the nature of the emergency change. Ideally, the standing members alone should possess sufficient knowledge and authority to make a decision. The more people asked to attend a CAB/EC meeting, the less likely it is that all can attend at short notice, especially if such meetings are not a part of their normal day. Extra members of the CAB/EC should be asked, therefore, only if absolutely necessary. An example would be a change that affects areas that lie outside the knowledge and authority of the standing members. The change initiator for a particular RFC is an exception. This person needs to be a member of the CAB/EC in order to provide quick answers to their questions.

Because an emergency change can be requested at any time and because the emergency change requested needs to be deployed quickly, the CAB/EC has a very short timeframe in which to meet and vote. Since voting requires a quorum, the standing membership or appointed deputies of the CAB/EC must always be able to attend at short notice. This availability can be achieved by having an “on-call” roster for each role of the CAB/EC, whereby a person is available for each position on the CAB/EC at any time of day—either in person, over the phone, or by using other technology solutions.

The change manager should be able to add members to the CAB/EC as needed.

For an emergency change, the voting logic is that the change requires unanimous approval.

Notify CAB/EC Members

The change manager must contact each CAB/EC member personally to inform him or her of the emergency change request, when it will be reviewed, and what form the meeting will take.

As explained above, CAB/EC meetings are held on an as-needed basis with little advance warning. This means that normal notification methods may not be sufficient. If e-mail meeting requests are used, invitees should be given a short time period to acknowledge the meeting to the change manager; otherwise more direct methods of contacting CAB/EC members must be used.

CAB/EC Members Review the RFC

The CAB/EC reviews the emergency change request using the same criteria used for a regular change. The assessment of the risks and the impact are, in some ways, more important for an emergency change because the risks are usually higher and the testing of the change is minimal or nonexistent.

The presence of the change initiator at the meeting allows questions about the change and its impact to be put directly and be answered immediately. There may be a need to collect additional information and re-present the RFC to the CAB/EC before a decision can be made. In this case, the RFC is placed in a pending state until the CAB/EC can reconvene, likely within a very short time (an hour, for example).

The CAB/EC may decide that the change is not an emergency change and should be handled by the normal change process. In this case, the change manager reclassifies the change and updates the change log with the reason for reclassification. If the change initiator wants the RFC to be considered again as an emergency change, this person must provide additional supporting evidence to justify the need and resubmit the RFC to the change manager. The change manager can then bring the RFC, containing the new information, back to the CAB/EC. Again, this process can happen very quickly—in minutes or hours rather than days. If the change initiator agrees that the change is not an emergency change, the RFC returns to the change classification stage of the overall process for subsequent scheduling at a regular CAB meeting.

If not all members of the CAB/EC are available to meet face to face, NetMeeting can be used to facilitate their communication.

CAB/EC Members Vote on the RFC

When discussions are complete and it is agreed that all necessary information has been presented, the CAB/EC votes on the change. For an emergency change to be approved, a unanimous vote is required. In this case, a majority is not sufficient, considering the risks involved in making an emergency change.

If the RFC is approved, the change moves on to the change deployment stage, which again follows an expedited path to implement the change as soon as possible. Whichever decision is made, the change initiator and all other interested parties are informed of the decision, and the change log is updated.

The change manager should record the decision and document the vote (for or against) the RFC by updating the change log.

Summary

In summary, the change authorization process:

•	Defines the structure for authorizing changes from all categories and priorities.
•	Incorporates feedback from all role clusters involved in the authorization process when required.
•	Defines the functions of the change manager and the composition and functions of the CAB and CAB/EC in the change authorization process.
•	Utilizes voting logic for effective decision making.
•	Offers a feedback cycle for the change initiator to be involved in the authorization process.

Change Development

After an RFC has been approved (using the appropriate path based on its priority and category), it moves into the change development phase. This phase is concerned with the steps necessary to plan the change, develop the deliverables of the change (for example, developing new code or configuring new hardware), and the handover to the release management process for the deployment of the change into the production environment.

The processes involved in the change development and release phase are shown in Figure 7.

Figure 7. Change development and release process flow

The speed with which the steps in this process are executed can vary greatly. A small—but emergency—change may be planned, developed, and implemented in minutes. A change involving deployment of a new software package to an enterprise may take months or even years in the development and deployment phases. Because of this wide variation, considerable flexibility is required in the individual steps. However, some steps, such as the reviews, must always take place, even if they constitute only a very brief conversation between two people.

Whereas change deployment is led and organized by the MOF Team Model Release Role Cluster, other Team Model role clusters are also involved at this stage. Although specific activities depend on the type of change being deployed, the following table gives some examples of the activities that may be undertaken by different role clusters.

Table 5. MOF Team Model Role Cluster Involvement in Change Development and Release

MOF Team Model Role Cluster	Change Development and Release Activity
Infrastructure	Provides additional technical expertise during change development and deployment.
Operations	Assists with the change development and deployment into the production environment, ensuring that the operational working practices can accommodate the change during and after deployment with minimal disruption.
Partner	Coordinates the involvement of any third-party resources and ensures that the change is successfully deployed into any outsourced services arrangement.
Release	Manages change deployment activity.
Security	Ensures that appropriate security features and elements are addressed in the change development, that security is not compromised during deployment, and that any additions or changes to security practices are implemented correctly.
Support	Provides support to the change development and deployment, ensuring that the help desk can assist users with any support needs during the deployment.
Service	Ensures agreed and projected service levels are not negated by the change development and that all changes have customer approval and fit into service improvement objectives.

Schedule Change

After a change has been approved, it must be decided when to deploy it. The date and time of the change is entered into the forward schedule of changes, which is maintained by the change manager. The forward schedule of changes shows when all changes are to take place. Having a single change schedule makes it possible to show the available change windows (the times during which changes are permitted). It also ensures that multiple, interdependent changes are not scheduled at the same time; sometimes a change might be scheduled that would prevent all other changes (including standard ones) from taking place. When scheduling the change, notice must be taken of other changes that are dependent on the scheduled change or on which the scheduled change itself is dependent—for example, a prerequisite.

In some cases, it may only be possible to enter a tentative date for the change. This is the case for large changes that require a long development phase. As the development project progresses and the development project plan is drawn up and tracked, the date when the change will be implemented in the production environment becomes more definite. Nevertheless, the change date must be reviewed at intervals and adjusted as necessary.

The forward schedule of changes contains only minor, major, and emergency changes. Standard changes are not considered to have an impact on other types of change. Although standard changes are automatically approved for deployment, they must still be scheduled with reference to the forward schedule of changes. For example, installing a software application (standard change) could be prevented by a network upgrade (major change).

When scheduling a change, it is important not only to take into account the category and priority of the change, as well as any impact from changes awaiting deployment, but also to confirm any schedule effects on business priorities. For instance, deployment of a change may be scheduled to occur outside of normal working hours in line with existing service level agreements for the service affected. However, this should be confirmed in case there have been any changes to business priorities that may be affected if the change occurs on that date. For example, there may be days where there is lower risk to business productivity should the change need to be backed out.

It is useful to highlight key business priority dates, such as financial year end or predicted periods of high sales revenue, in the forward schedule of change as these become apparent, since changes can then be avoided at these key times. The Service Role Cluster will be able to provide this information to the change manager.

The calendar on a Microsoft Outlook, Exchange, or other e-mail program can be used to administer the forward schedule of changes. Outlook can be used to create appointments in the change schedule, and permissions can be set that allow the majority of users to read the calendar but permit only a limited number (the change managers group) to update or change it.

Adding color coding and using meaningful text in the change schedule entries make it relatively easy to identify emergency, major, and minor changes, or changes that affect a specific part of the business.

Appoint Change Owner

After the change has been scheduled, the change manager needs to identify and appoint a change owner to manage the change through the development and release process and into the production environment. The change owner can also be the change initiator. The change owner may have been involved as a technical expert earlier in the change life cycle when the initiator may not have known the full IT impact of a change he or she raised, or the change owner may be a new appointment, a person who is likely to be a subject matter expert in the area connected to the RFC and thus possess the technical abilities needed to manage the change to completion. In the case of small changes, the change owner might carry out the change personally. For larger changes, the change owner acts in the role of a project manager during the development and test phases and oversees the implementation of the change. The priority and category of the change should be part of the criteria used to appoint the appropriate change owner for a particular RFC. For example, for a high priority, major change to be implemented, the selected change owner may need to possess a certain level of project management skills or high seniority within the organization.

When the suitable change owner has been appointed and assigned to the RFC, the change manager records the change owner’s name in the change log, and the change moves to the change development stage.

Change Development Methodology

All nonstandard changes pass through the change development methodology, which varies greatly in size and scope depending on the nature of the change. Some changes require more extensive and detailed work in each of the development phases than others.

Because they represent a repeated, low risk change, standard changes do not pass through the development phase. For the other types of changes, the choice of methodology used in the change development stage is open, and many such methodologies exist. It is possible to follow the simple steps of the change development methodology, or the development process used internally within the organization. In addition, the Microsoft Solutions Framework (MSF) Process Model, shown in Figure 8, can be used to structure the change development. More information on MSF can be found at http://www.microsoft.com/MSF.

Figure 8. MSF Process Model
See full-sized image

The development methodology chosen must be sufficiently flexible to handle development work of any size. For example, something as simple as amending a process document, which passes through change management, can still be developed using MSF informally. In this case, the Envisioning and Planning phases are very short and do not involve many people. The Developing Phase does not need a complex project plan because it is mainly an authoring exercise and might involve only one or two people. On the other hand, a complex change, such as upgrading all desktop computers to Microsoft Windows® XP, is a very large project, involving many people across the organization, requiring long planning and development stages, and costing a large amount of money. In such a case, it is important to follow a formal development methodology so that the change manager can track the change’s progress and coordinate any shift in the planned deployment date with other changes.

Emergency changes must also use the chosen development methodology, even though there is pressure to implement the change as quickly as possible. The amount of time spent in each phase is likely to be minimal, and reviews between the phases are likely to be merely quick meetings between the involved parties to verify that the milestone in question has been achieved. The methodology chosen should be flexible enough to allow this fast-track path through it, without skipping important checks along the way.

Note During the Developing Phase, and particularly at the milestone reviews (see below), the project team might abandon the change. This could happen for a number of reasons. For example, the Envisioning Phase might reveal that there is insufficient budget to achieve the change as desired; or during the Developing Phase, events such as a company takeover might make the change obsolete. For the sake of simplicity, these decision points are not shown on the flow diagrams. If, however, the change needs to be abandoned, it should be discussed at the next CAB, and the RFC closed as necessary. The change manager notes the reasons for abandoning the change in the change log and informs the change initiator and other interested parties.

Milestone Reviews

A solutions development framework such as MSF has review points as the development project moves from one phase to another—for example, from Envisioning through to Planning. The milestone review ensures that the preceding phase has been completed successfully and the project is ready to progress to the next phase. In some cases, as in a very small project, the review may be as simple as a discussion with a peer. However, before more complex changes can progress to the next phase, the approval of a number of people in different groups, perhaps a subset of the CAB representatives present for the change approval, may be required.

For any particular project, the milestone reviews may take different forms from one milestone to the next. For example, a full Vision/Scope Approved Milestone review by the CAB might be required at the end of the Envisioning Phase, when detailed costs of the deployment have been obtained and documented. A far smaller Project Plans Approved Milestone review might be sufficient at the end of the Planning Phase if there are no new issues requiring approval from the CAB.

The project review process ensures that progression from one MSF phase to the next is agreed upon by all the groups affected by the change. It links back into the change management process in that the RFC is referenced and updated in the review, and the reviewers have the option of halting the change and closing the RFC, if necessary, or escalating the decision to the ITEC.

The Project Plans Approved Milestone review is similar in many ways to the CAB review process, during which the initial decision about the change was made. The Project Plans Approved Milestone review can be regarded as reviewing the RFC again, but relying on more up-to-date information concerning costs or risks (bearing in mind that the basic change itself has already been approved). The same criteria used to select CAB members to authorize the change should be applied when selecting people to review the development process milestones.

For each milestone review, the change manager adjusts the CAB membership list as appropriate for the nature of the change, the milestone that has been reached, and the current overall status of the project (for example, more senior decision makers may be needed if the project is running late or is over-budget, or if other serious risks have been identified).

Milestone reviews normally occur at the same time as the regular (usually weekly) CAB meeting that reviews RFCs. If the milestone review must take place sooner than the next scheduled meeting, then an as-needed CAB meeting may be required. Each scheduled milestone review is reviewed by the CAB at the CAB meeting. When the presentation of information and discussions has been completed, the CAB votes on the change, using the defined voting logic. If no decision is made, the same principles and procedures are followed as in the initial CAB review: the decision is passed to the IT executive committee. See the CAB Members Review RFC section for a description of the escalation procedure, which is the same as for the original RFC review.

If the CAB votes to not approve the review, this can have one of two consequences:

•

The CAB may decide that all the criteria for passing the review have not been met, but that the project can meet them with more work in some areas. In this case, the CAB fails the project in the review, but the RFC and the approved change remain in effect. The RFC is returned to the Deploying Phase just completed. The change manager updates the change log, detailing the additional work required for the change to progress to the next phase.

•

Alternatively, the CAB (or possibly the ITEC if the decision was escalated) may decide to not approve the milestone and to cancel the change altogether. This might happen during the Planning Phase, for example, if it is decided that the project cannot be completed on time with the functionality required and within the available budget. Rather than rework the plan, the CAB might decide to cancel the project altogether and provide the solution in a completely different way, such as outsourcing. In this case, the RFC is closed.

In either case, the change is updated with the reasons for the decision and the change initiator and any other interested parties are informed.

If the CAB approves the milestone review, then the deployment process moves on to the next phase, the release process. Please see the Release Management Service Management Function Guide for more details on the specific practices involved in this process.

Summary

In summary, the change development and release process:

•	Schedules the change according to business priorities, change pipeline, category, and priority.
•	Appoints a suitable change owner according to the requirements of the change in terms of technology, size, priority, and category.
•	Ensures that the change development process follows a recognized development life cycle.
•	Conducts milestone reviews, with the participation of CAB members, to ensure that each phase has been completed successfully.
•	Ensures that the change developed and passed through to the release process has met acceptance criteria.

Change Review

Following a successful release and deployment into the production environment or, as in the case of a standard change, just a deployment into production, a review process must be conducted to establish whether the change has had the desired effect and has met the requirements from the original request for change. The process for the change review is shown in the flow chart in Figure 9.

Figure 9. Change review process flow
See full-sized image

In most cases, this review process might be very brief. For a standard change, for example, where the effect has been small and the results relatively predictable, the review process may be limited to checking that the user has the desired functionality from the change, such as the availability of a new Word template. The other steps in the process can then be carried out in as-needed meetings or telephone calls with the change manager.

In addition to changes that take the “normal” route through the change process, emergency changes should be reviewed as well, despite the speed in which the deployment may have been carried out. In fact, it is more important to review the implementation of emergency changes because their typically curtailed testing leads to greater risks. It is therefore necessary to determine as soon as possible if the change resulted in any adverse effects.

All of the MOF Team Model role clusters should be involved in the change review activity. As with the other change management activities, the Release Role Cluster takes the lead in directing the change review, but each Team Model role cluster has specific areas of concern related to its responsibilities, as listed in Table 6.

Table 6. MOF Team Model Role Cluster Areas of Concern in the Change Review Activity

MOF Team Model Role Cluster	Change Review Activity Area of Concern
Infrastructure	Did any technical or capacity issues occur during the change?
Operations	Did any operational issues occur during and after the change?
Partner	Were there any third-party or partner issues with the change?
Release	How did the change progress through the change management process and where can lessons be learned?
Security	Did any security issues become apparent with the change?
Support	Were any supportability issues evident during or after the change?
Service	Were any service levels breached during or after the change?

Monitor Change in Production Environment

In order to determine whether the deployed change has been effective and has achieved the desired results, it is necessary to monitor the changes in the production environment. For a small change, this may consist of checking on the desired functionality—for example, for a change in Group Policy allowing a desktop setting to be changed. For larger changes, it might require the monitoring of network and server information, performance data, event logs, or response times.

A number of different tools and technologies are available for monitoring a change in the production environment. These include but are not limited to Microsoft Operations Manager (MOM) and the Windows Network Monitor, Replication Monitor, and Performance Monitor tools. The actual tools used depend on the nature of the change, the components of the IT infrastructure that are affected, and the skills and experience of personnel performing the monitoring activity.

Hold Post-Implementation Review

After sufficient information has been gathered from monitoring to determine the effectiveness of the change, a post-implementation review is held. The time interval between the change implementation and the review depends on the size of the change made and how quickly the effect of the change can be measured. For example, a change may have immediately measurable adverse effects on users or the network, as evidenced by a large increase in calls to the service desk from users unable to access a network resource. In such cases, the review must be held within a very short time in order to decide whether to back out the change or make other changes to fix the situation. Other changes, such as an increase in network capacity, may require several weeks to gather enough data to measure the change’s effectiveness.

The format of the post-implementation review also depends on the planned and actual impact of the change. A standard change with little overall effect may require only the change manager, the change initiator, and the change owner to have a short meeting, possibly by telephone or NetMeeting, where they agree that the change was successful. In contrast, a major change involving the rollout of a new desktop operating system will probably require a formal meeting of several interested parties to review the data from the monitoring phase and compare the effects of the change to the initial objectives.

In all cases, the change manager schedules and moderates the review meeting and the change initiator should attend. During the review, reference must be made to the original RFC, which states the objectives of the change and, ideally, offers some measurable indicators for gauging the effectiveness of the change. The measured effects of the change can be compared with the desired effects in order to decide whether the change has met its objectives.

As well as making a success/failure decision on the change implementation, the review should also look at how the change was deployed and whether it was implemented on time and on budget. This exercise should result in the documentation of the lessons learned from the change. Review feedback is then sent to all parties involved in the change in order to encourage and enable future process improvements.

Depending on the number of changes being dealt with, several changes might be reviewed during one post-implementation review session. However, some changes—because of their size and complexity—might warrant individual reviews.

Close Successful Changes

If it was deemed that the change has met the objectives, the change log can be updated and the RFC closed.

Back Out Changes

If the change has not met the objectives, then a decision needs to be made about what, if anything, should be done. If the change is affecting users or parts of the IT infrastructure adversely, a decision might be made to back out the change and remove it from the production environment.

In such cases, the issues involved in conducting the backout should be evaluated, including:

•	The amount of effort required to perform the backout.
•	The effect it might have on other (either planned or already deployed) changes.
•	The possibility that users are already using the changed system, although not to the best effect, and removing some functionality that the users have become used to may be worse than leaving it as is.

In this last case, it may be better to initiate new RFCs to fix the problem, as discussed next in the Submit Additional RFCs section.

If it is decided that backout is required, the defined backout plan for the RFC is followed. The review meeting should decide on the timing. Although the backout would normally happen as soon as possible, it may need to wait until it can be implemented without causing additional adverse effects. For example, if the adverse effects of the change are not too great and a backout is nonetheless thought to be necessary, it might be delayed until the following weekend.

After the backout has been accomplished, further measurements and review should take place to ensure that it effectively restored the infrastructure to its pre-change state. If the backout was only partially effective, further RFCs may be required to fully restore the state of the infrastructure.

In all cases, the change log is updated with the reasons for the backout and the change initiator and other stakeholders are informed. The RFC is then closed.

When reviewing emergency changes, if it is seen that too many attempts to deploy a specific emergency change have failed, three questions need addressing:

•	Has the problem been correctly analyzed?
•	Has the proposed remedy been adequately tested?
•	Has the solution been correctly implemented?

In such circumstances, it might be better to provide a partial service (with some user facilities withdrawn) in order to allow the change to be thoroughly tested rather than to suspend the service temporarily, and then deploy the change.

The tools and technology used to back out the change will vary according to the type and nature of the change. Software applications deployed using Systems Management Server, for example, can normally be rolled back using the Uninstall option or Group Policy settings to disable or delete the appropriate Group Policy object.

Whether or not the change was successful, the fact that the RFC has been closed and the reason or reasons for closure must be recorded by updating the change log. An e-mail should be sent to the change initiator and other interested parties indicating that the change has been reviewed and is now closed. The e-mail should also provide information about the success or failure of the change and any detailed comments added by the change manager.

Submit Additional RFCs

Even if an implemented change has not fully met the objectives desired for the change, the review may determine that backing out the change is too costly or too risky, or the desired effect can be achieved with less expense by making additional changes. In the latter case, other changes may be required to rectify the problems caused by the change. For example, a service pack or hotfix may be required to fully implement the functionality to the level originally desired.

In this case, new RFCs should be submitted for any additional changes required to keep the production environment running and to achieve the results originally desired. The priority of such RFCs needs to be set appropriately: an emergency change might be required to minimize the time during which the adverse effects of the original change are experienced.

However, care must be taken not to implement “panic” changes to try to fix a problem caused by a previous change. This can become a vicious circle of changes to fix problems caused by a previous change that was itself implemented to fix a problem. If there is any danger of following such a spiral path, the change should be backed out instead.

In all cases, the change log is updated with the decisions made and the RFC is closed, although any new RFCs submitted will refer to the original RFC.

Accept Issues and Continue

Even if a change has not fully met the desired objectives for the change, the review may still determine that the change should not be backed out and that it is not desirable or cost effective to make more changes. For example, many users may already be using a new system, so backout is not a justifiable option, and the cost of fixing the problem may be too high. Instead, there may be options available to work around the shortcomings of the system. Such workarounds should be documented. If they are user workarounds, the service desk should be informed so that the information can be easily made available to the users. If the workaround is an additional manual process that some IT staff need to take, then they should be so informed.

In this case, the change log is updated with the reasons to accept the change and any workarounds that are implemented. The change initiator and other interested parties are informed and the RFC is closed.

Summary

In summary, the change review process:

•	Monitors and reviews performance of the change after implementation into production in line with the objectives of the original RFC and the objectives of the MOF Team Model role clusters.
•	Reviews lessons learned from the deployment and documents them for future benefit.
•	Deals with unsuccessful change implementations by backing out, considering further remedial changes, or using the “accept issues and continue” policy.
•	Closes successful RFCs and informs the initiator.

Top of page

Roles and Responsibilities

Roles associated with the Change Management SMF are defined in the context of the management function and are not intended to correspond with organizational job titles. Specific roles have been defined according to industry best practice. In some cases, many persons might share a single role; and in other cases, a single person may assume many roles, or at least more than one role. It is especially likely that a person will assume different roles with respect to different SMFs. For example, the change owner for change management is likely to be the release manager for release management.

The roles also correspond to the roles defined within the seven role clusters of the MOF Team Model. These role clusters (Release, Infrastructure, Support, Operations, Partner, Security, and Service) represent at a high level the functions that must be performed in an IT environment for successful operations. The roles within each cluster are closely related to each other.

The three significant roles defined for the change management process are:

•	Change initiator
•	Change manager
•	Change owner

Committees are also defined in terms of the roles they play and the responsibilities they have in the context of the change management function. Three committees typically have management responsibilities for the change management process. These three committees are:

•	Change advisory board (CAB)
•	CAB emergency committee (CAB/EC)
•	IT executive committee (ITEC)

Change Initiator

The change initiator initiates changes by submitting an RFC to the change manager. Everyone in the organization should be authorized to initiate an RFC. Below the manager level, however, it is recommended that employees submit RFCs to their managers who review them to ensure that the change requested is in keeping with business strategy and the vision for that area before passing them to the change manager. The change initiator is responsible for completely filling out the RFC form, which includes the reason for the RFC, the requested implementation date, and the systems and personnel affected by the change. This person is notified whether the change was approved and is kept up-to-date on the status of the RFC throughout the change process. The change initiator assists the change manager and CAB in determining the RFC priority and, at the conclusion of the change, participates in the post-implementation review.

Change Manager

The change manager is responsible for managing the activities of the change management process for the IT organization. This individual focuses on the process as a whole more than on any individual change. However, the change manager is involved in every step of the process—from receipt of an RFC to the implementation of the change in the IT environment—and is ultimately responsible for the successful implementation of any change to the IT environment. The change manager’s responsibilities include:

•	Receiving RFCs and ensuring that they are properly recorded in the change log.
•	Selecting CAB members and facilitating CAB meetings.
•	Preparing CAB meeting agendas and providing all necessary review information to the CAB members prior to the meetings.
•	If necessary, assigning teams to conduct RFC impact analyses and risk assessments.
•	Analyzing and prioritizing RFCs.
•	Categorizing, assigning change owners, and scheduling RFCs, subject to approval by the CAB.
•	Approving requests for minor changes.
•	Providing change notification to change initiator and other affected parties.
•	Monitoring the successful completion of all RFCs, including the change development project phases and ensuring that these processes follow the change schedule.
•	Reviewing and evaluating the change process.

Change Owner

The change manager assigns (with the CAB’s approval) an individual to be the change owner for a particular change. The change owner is responsible for planning and implementing a change in the IT environment. The change owner assumes responsibility upon receiving an approved RFC from the change manager or the CAB. The change owner is required to follow the change schedule approved by the CAB. For changes that are significant enough to require following a change development model—for instance, the MSF Process Model for application development—this individual is responsible for coordinating the project phases of the assigned change.

For standard changes, the service desk is typically the change owner. For major, significant, and minor changes, the change owner may also serve as the release manager.

The change owner should routinely provide project status feedback to the change manager and identify any problems as they arise. The change owner presents all formal updates and proposals to the CAB after the CAB approves the RFC for passage through the various MSF phases.

The change owner must work with the change initiator to ensure that the change meets the change initiator’s requirements and that it successfully corrects any problems or provides the correct system enhancements intended by the RFC.

After implementing the change, the change owner assists the change manager in evaluating the change process as it applies to the particular change. The change owner also coordinates and presents the post-implementation review analysis to the CAB.

Change Advisory Board (CAB)

The CAB is a decision-making body for the IT organization and evaluates and votes to approve or reject RFCs.

CAB Membership

The CAB is made up of individuals with stakeholder interest in the production environment. Since RFCs can impact any part of IT and any organizational group, the makeup of the CAB should reflect the focus of the particular RFC being reviewed. However, a core group of individuals from IT operations is permanently assigned to the CAB. This group may include representatives from the MOF service management functions (Release Management, Capacity Management, Configuration Management, Availability Man

Service Management Functions

Change Management

On This Page

Executive Summary

Introduction

Document Purpose

What’s New?

Feedback

Change Management Overview

Goal and Objectives

Key Definitions

Processes and Activities

Process Flow Summary

Change Request

Create a Request for Change

RFC Information

Change Priority

Change Category

Submit the RFC for Approval

Screen RFC

Summary

Change Classification

Set RFC Priority

Change Priority Classifications

Set RFC Category

Change Category Classifications

Summary

Change Authorization

Authorize Standard Changes

Authorize Minor Changes

Authorize Significant and Major Changes

Select CAB Members

Notify CAB Members

Affirm or Modify Voting Logic

CAB Members Review the RFC

CAB Members Vote on the RFC

Authorize Emergency Changes

Select CAB/EC Members

Notify CAB/EC Members

CAB/EC Members Review the RFC

CAB/EC Members Vote on the RFC

Summary

Change Development

Schedule Change

Appoint Change Owner

Change Development Methodology

Milestone Reviews

Summary

Change Review

Monitor Change in Production Environment

Hold Post-Implementation Review

Close Successful Changes

Back Out Changes

Submit Additional RFCs

Accept Issues and Continue

Summary

Roles and Responsibilities

Change Initiator

Change Manager

Change Owner

Change Advisory Board (CAB)

CAB Membership