Change Management Table of Contents
Change introduces potential sources of inaccuracies and failures into the infrastructure which, if not controlled through process and diligent effort, would soon overpower an organization. No matter how minor or beneficial a change may be, it should always be approached with a healthy dose of caution. Change management is a set of policies and procedures that can be used and followed to formalize that caution into a repeatable, consistent process. Process Requires Re-writing for conformance with ITIL Version 3. More...

Introduction to Change Management

Change Management is a process within the Transition module of the ITIL Service Lilfecycle.

The ability to effectively management an IT infrastructure can be generalized into one of three primary functional groupings:

• Knowing perfectly the current environment - components, services, business operations - that is "it’s known and trusted state"
• Highly reliable predictions of when elements of the infrastructure will wear and eventually fail and the organization's ability to proactively do something about it
• Since no environment will exist at an optimal state (if only because the definition of ’optimal’ will continue to be re-defined to higher performance levels), the need to introduce and manage Changes to the environment is crucial to sound management

No matter how large or small your network environment, change is inevitable. Hiring new employees, adding new offices, supporting new network services, improving security, fixing bugs—all of these activities result in change, especially to your network infrastructure devices, such as routers, switches, hubs, firewalls, and so forth. Although change is almost always a good thing in the end, change can cause bad things to happen. The enterprise must learn to live and manage change on a continuing basis. This vastly complicates it's attempts to maintain the "known and trusted state" of it's environment since each change must be reviewed in the context of all other components. Frequently, the need for early product releases will preclude complete assurances around component compatabilities. The organization can quickly loose any accumulated confidence in the stability and trustworthiness of its' environment.

Without the ability to introduce and manage change the organization would, indeed, become stupider. Change introduces potential sources of inaccuracies and failures into the infrastructure which, if not controlled through process and diligent effort, can soon overpower an organization. Changes are the single largest cause of incidents in the infrastructure and the organization's ability to handle change effectively will provide the highest return on investment of any ITIL process.

At its simplest, change management simply means keeping track of the changes you make and evaluating proposed changes for their effect before actually implementing them. In practice, change management involves some fairly well-defined tasks:

• Maintaining documentation that describes the current configuration of all network devices
• Maintaining documentation that describes the purpose and details of any changes
• Maintaining an archive of older configurations so that they can be used in an emergency
• Implementing policies that control the rate of change
• Implementing policies that control who may perform changes

Change Management

• that all proposed changes undergo appropriate risk assessments based upon established categories and that the assessments include a wide perspective of opinion including those of customer and business operations
• that business operations are informed of and provided adequate opportunity to adjust workload to minimize the business impacts of changes
• that all problematic changes can be restored to their condition prior to the initiation of change procedures
• reduced risk of change implementation by using established, tested and trusted procedures whenever possible
• that changes are implemented in time periods that minimize potential business disruption
• increased change success rates as a result of planning and testing
• that change costs are controllable and subject to productivity measures over time
• that change procedures are integrated within the context of the organization’s overall processes

Critical Success Factors

• Change policies are clear and known and they are rigorously and systematically implemented
• Change management is strongly integrated with release management and is an integral part of configuration management
• There is a rapid and efficient planning, approval and initiation process covering identification, categorization, impact assessment and prioritization of changes
• Automated process tools are available to support workflow definition, pro-forma workplans, approval templates, testing, configuration and distribution
• Expedient and comprehensive acceptance test procedures are applied prior to making the change
• A system for tracking and following individual changes, as well as change process parameters, is in place
• Well documented current configurations makes it possible to recover gracefully from failed change procedures
• A formal process for hand-over from development to operations is defined with a distinct segregation of duties between development and production
• Changes take the impact on capacity and performance requirements into account
• The ability to coordinate different changes, recognizing interdependencies
• An independent process for verification of the success or failure of change

Process Characteristics

This is done by ensuring that...

• all changes are discussed, reviewed and managed to reduce disruptions to business operations and impact on the "production environment"
• changes can be backed out if a problem occurs - ie., the original environment can be restored
• proper authorization is obtained prior to the implementation of all changes
• all parties involved adhere to the change management guidelines
• all staff affected by a change are informed before the change occurs and given ample opportunity to plan accordingly
• an audit trail of all changes is maintained
• trends are analyzed and meaningful reports provided to senior management
• Continually reviewing and improving the change process

Scoping

In Scope

• software release to production (whether full, delta or packaged releases),
• changes to application scripts which might potentially change more than a single record and hence corrupt or overburden indexing tables and increase network traffic
• instances of break/fix (which do not result in an Emergency Change requirement - covered separately) for an application or desktop productivity package
• a modification of a 'dll' or other application program component resident on a server attached to the infrastructure
• modification of supported hardware including upgrading of standard machine offerings
• revisions and changes to standard images placed on those machines
• resolution of known errors resulting from incidents and root cause analysis
• a service request
• acceptance of new or modification to existing routine procedures (eg. password reset)
• acceptance of new or modification of existing Business Continuity Plans (ie. Disaster recovery)
• a pre-production environment may be included in order to impose the rigour of Change Management on build and test procedures.

Usually Excluded

• Corporate and Vendor Changes - Parts of the infrastructure may be controlled by other service partners. Some, (eg., wide-area network), may even be administered at a higher organizational level than the IT Provider with responsibility for Change Management. The organization's role in Changes affecting these resources is as a reviewer of Changes controlled by the higher body. This might be accomplished through representation on a CAB representing the larger organization.^Note

• Changes to Project Plans - There are related Change Management processes and procedures in project management methodologies. Testing of new applications MUST always take place in environments dedicated to testing and should follow a strict set of rules and procedures before they become candidates for "release" into the ""live" (ie. production) environment. These processes are beyond the scope of Change Management process which deals exclusively with the "live" or production environment.

• Test Environments - Test environments and associated change processes pertaining to their use are controlled by application change builder(s). They are normally outside the domain of Change Management. However, if and when testing environments and/or processes might affect the live environment they become candidates for Change Management.

Discretionary

• Pre-production environment typically involve frequent modifications to simulate new production environment. Re-establishing the environment to its' original configuration may, or may not, be an explicit requirement of using the environment. Organizations may place the pre-production environment under Change Management to infuse rigour and control to the environment so that its' condition at any point in time is 'known and trusted'.
• the manner in which third party infrastructure participants establish Change Management may be a contractual condition. There may be established protocols for the movement of RFCs and Change documentation between respective systems as well as agreements on reciprocal representative on CABs

Relationship to Other Processes

Relationship with Release and Configuration Management processes

Discussion of area to be emphasized

When software is accepted from developers or suppliers, it is placed into the DSL and registered in the CMDB. Release Management is responsible for building Releases from the DSL into the controlled test environment. When testing has successfully concluded, Release Management should distribute the Release into the live environment through normal Change Management processes.

Service Desk and Incident Management

The service desk provides efficient and high-quality user support and incident management. The service desk should provide support during the pilot program and immediately following full release implementation. Defect Lists and Known Errors should be made available to the Service Desk as these are a prime source of possible failures and, hence, reported incidents. If adequate forewarning is not provided users frustration will be aggravated.

Problem Management

• any related Problems or enhancement requests should be closed
• Problem Management staff should be informed of the new Release or hardware upgrades so that they can support its' use in the live environment. Such staff should receive training in any new or revised support procedures.

Availability Management

Capacity Management

Security Administration

Policies & Guidelines

• The current and proposed state (i.e., pending changes) of the infrastructure should be defined and maintained in a Configuration Management Database (CMDB)
• All changes to Configuration Items (CIs) should be controlled through Change Management
• The rigor in which changes are evaluated and approved for implementation into the infrastructure is primarily determined by the risk associated with them.
• All changes should be submitted through a Request for Change (RfC) form.
• All changes must be approved by the Change Manager or by one of the following Change Advisory Boards (CABs), either during the RfC process or in advance in the case of blanket changes...
  • an Executive CAB will normally approve changes with major financial and/or customer implications
  • a Corporate CAB will approve "significant' and 'major' severity changes. The Corporate CAB is also responsible for approving which changes represent a low enough risk to the business that they would not have to be reviewed again by the Corporate CAB at the time of implementation. These changes fall in to the following two categories:
    • Severity = Standard: low risk changes that are performed on a regular basis in the normal course of providing service (e.g., computer Moves/Adds/Changes). Standard changes are not required to be scheduled through the change management process and are recorded directly in the CMDB.
    • Severity = Low: low risk changes that require a high degree of technical knowledge and must be scheduled through the change management process and approved by a Local CAB.
    Although Standard and Low changes will not require Corporate CAB approval at the time of change, they both should be initially approved for a specific period of time and will be reviewed on a periodic basis by the Corporate CAB to determine the appropriateness of their status.
  • Local CAB: approves changes that have a Severity = Low.
  • Emergency CAB: approves Emergency changes with short timeframes that, based on business or risk considerations, cannot meet the documented lead times.
  • Change Manager - approves minor changes.
• Release to production processes for IT Provider-owned CIs should be approved for introduction into the infrastructure through the Change Management process.
• Change Management should assist in coordinating project schedules when there are dependencies that require concurrent application and/or infrastructure releases.
• Service Partners should comply with the Change Management process when making changes that could impact the organization's IT environment.
• All change initiators should review the Forward Schedule of Changes (FSC) for the most appropriate time to implement their change.
• Wherever possible business applications should be encouraged to follow Change Management to minimize any impact to overall IT environment.
• All pre-defined business contacts, as maintained in the CMDB, should be informed of Changes which may affect their ability to operate at peak efficiency levels and, in other than emergency situations, should be given sufficient lead time to make contingency plans.
• Business Units should participate in test plan development and functional testing when appropriate.
• Changes should be implemented in pre-established, regular change windows whenever possible.

How the Process Scales

Project Change Management

Forward looking project managers will institute a Change Process which includes:

• mechanisms to control and priorize requirement changes,
• the identification of a single change control channel,
• participation by both developers and business users,
• an impact study to evaluate the effect of the requested change.

These principles have direct parallels in controlling changes in the production environment.

Awareness of the Need

If the environment is relatively stable then the volume of changes may be controllable without creating an undue number of incidents following the change. However, as the environment increases in the number of users or the complexity of the infrastructure there is increasing risks of failure caused by a Change. The need to test changes prior to introducing them increases exponentially with the number of failure points and the inherent complexity of the infrastructure. The Return on Investment on improving Change Management procedures makes it an increasingly attractive measure for the organization.

Network operations, application support, desktop management may undertake to standardize and re-use change procedures. While cooperation between these respective organizations may not be well coordinated, within each unit there may develop an awareness of the need to coordinate change activities - if only to distribute the workload.

These initiative will usually involve planning meetings amongst the change implementers and the creation of local change calendars denoting change activities to be implemented in Change windows associated with each area. Over time some cross-representation amongst the groups may appear.

Consolidating Change Management Activities

Initial attention will be devoted to managing changes in the most important parts of the infrastructure - the organization's mission critical systems.

Concepts

Change Priority

• The Impact of the CIs undergoing the change on the total infrastructure.
• The continuing exposure to the organization without the change being implemented.
• How quickly the change must be implemented.
• How easily the change can be implemented - i.e. its' complexity and costs.
• Business considerations.
• The ability to schedule the change in coordination with other changes happening to the infrastructure.

Severity

The severity will most often be associated with specific Configuration Item(s) impacted and, as such, a default Severity designation can be assigned to CIs maintained in the CMDB.

The following criteria are usually associated with Disaster Recovery and business continuity planning and can be applied to specific CIs or assessed manually when developing the RfC:

• Non Essential - applications that can be interrupted and integrity of the data is not essential. To the system user work stops and uncontrolled shutdown occurs. Data may be lost or corrupted.
• Business Essential - Highly Reliable - applications that can be interrupted as long as integrity of the data is assured. To the system user work stops and uncontrolled shutdown occurs.
• Mission Critical - Highly Available - applications requiring no more than minimal interruption during essential time periods, or during most hours of the day or week throughout the year. To the system user work is interrupted but they can quickly log back onto the system. However, some transactions may need to be re-run from a journal file and users may experience performance degradation
• Survival Critical - Continuously Available. This is accomplished through a High Availability Design:
  • Fault Resilient - applications requiring uninterrupted computing during essential time periods, or during most hours of the day or week throughout the year. Comprehensive monitoring tools are used to notify support staff to take corrective action. This means that the user stays on-line. However, the current transaction may need restarting and user may experience performance degradation.
  • Fault Tolerant - applications demanding continuous computing (7x24 operation), and where the application has been engineered to detect most causes of failure before they occur and take corrective actions automatically. This means no interruption of work, no transactions lost and no degradation in performance.
  • Disaster Tolerant - applications that absolutely must be available and where any failure must be transparent to the user. This means no interruption of work; no transactions lost; no degradation in performance and continuous computing services that are even safe from disasters because computing capability is available in multiple data centers/sites. Disaster Recovery is inherent.

The following categories are example codes which can be employed in establishing Severity:

Severity	Impact
Major	Major functions of a Survival or Business Critical application are unavailable or working below specified parameters. Needed capabilities may be unavailable. Workaround may be missing or inefficient and/or recovery may be difficult. The solution requires significant resources be allocated or has serious implications to the customer.
Significant	Major functions of a Business essential system are unavailable or working below specified parameters. Needed capabilities may be unavailable. Workaround may be missing or inefficient and/or recovery may be difficult.
Minor	Minor functions of the system are unavailable, unusable or overall performance of the system is below maximum load specification. There must be a correction but it can wait for a subsequent or packaged release. Work can proceed but with diminished efficiency and/or inconvenience. There may be temporary workarounds available which are acceptable.
Low	Low risk changes that require a high degree of technical knowledge and must be scheduled through the change management process and approved by a Local CAB.
Standard	Low risk changes that are performed on a regular basis in the normal course of providing service (e.g., computer Moves/Adds/Changes). Standard changes are not required to be scheduled through the change management process and are recorder directly in the CMDB.

Lead Times Required to Implement a Change

Heightened Awareness Period(s)

Recognized "busy times" should be identified and avoided when planning changes to the production environment. This issue is managed through the requirement to have change schedules approved by all owners of critical applications.

Maintenance Window(s)

Roles and Responsibilities

Change Initiator

Change Advisory Boards (CABs)

 

Local CAB

The Local CAB has overall responsibility for all changes submitted and implemented by their unit. This board is chaired by the Local Change Manager. The following is a list of their responsibilities.

• Works with the change initiator to understand the impact, resources required, and to ensure that the change has the support of the business area and that it is a necessary and practical change.
• Reviews the change and approve moving to the Planning stage.
• Ensures that all Build Plans, Test Plans, and Back-out plans have been created. (Unless not required for that CTI). This must be completed prior to the status being changed to Scheduled.
• Ensures adequate testing has been done in accordance with the test plan. This must be completed prior to the status being changed to Scheduled.
• Ensures appropriate lead times are provided in accordance with the documented Change Management process.
• Ensures that documented processes are followed for all changes implemented by their unit.
• Has complete approval and scheduling responsibilities for all RfCs assigned to their unit and designated as Severity = Low.
• Works with the Change Manager and the Corporate CAB as to which changes can be considered as a Severity = Low for a unit.
• Designates changes as an Emergency.
• Participates in the Emergency Change process for all Emergency changes submitted from a unit.

A Local CAB is made up of the following members.

• A Local Change Manager (should be a SME or Manager designated by the management of that technical unit).
• Subject Matter Expert (SME) for a unit.
• Implementer, if needed.
• Change Coordinator or Change Manager as needed (may be necessary to help with coordinating testing or communications across multiple business lines or technical areas).

Corporate CAB

The Corporate CAB has the same responsibilities as the Local CAB, but only for RfCs that have been designated for their review. Although the majority of changes that will be presented to the Corporate CAB are categorized as Significant or Major, the Change Manager has the authority to have other RfCs reviewed by the board. This board is chaired by the Change Manager.

CAB meetings should occur regularly but all of them do not need to be face-to-face. Teleconferencing will be used for members that cannot attend in person. Pagers will be used where necessary to assemble key staff for an Emergency CAB meeting to discuss Changes which might result from a high severity service outage. In some cases CAB members will be able to review RfCs and electronically be able to approve them, with overall responsibility of approving the change falling to the Change Manager.

The following is a list of responsibilities of the CAB.

• Reviews all changes submitted to Corporate CAB for approval ensuring that there is an understanding of the impact, resources required, business areas involved, and that it is a necessary and practical change.
• Ensures that the Local CAB has verified and approved the build plan, test plan and back-out plan.
• Ensures adequate testing has been done.
• Ensures appropriate lead times have been provided in accordance with the documented Change Management Process.
• Provides the Change Manager with appropriate information to allow a decision to be made to approve or reject a submitted change.
• Reviews Forward Schedule of Changes (FSC) to assure the change will not conflict with other activities.
• Participates in the approval process for all submissions of new changes to be considered for a Severity = Low or Standard.
• Helps determine if there is a significant financial or customer impact to justify sending the RfC for review by the Executive CAB.

The Corporate CAB is typically made up of the following members:

• All Local Change Managers.
• Change Manager.
• Change Coordinator.
• Representatives from the LOBs that wish to participate in the process.
• Representative from the Service Desk.
• Representative from Availability Services.
• Representative from Security Services.
• Representative from Finance.
• Local Change Managers for all areas that have a task associated with a change that is up for review at this board.
• Vendor support as required.

Executive CAB

This board will review changes that the Change Manager or the Corporate CAB has determined to have a major financial or customer impact. This board will be chaired by the Change Manager and will only be called to session as needed. This board does not have any of the responsibilities of the CAB (although they will probably want assurances that those responsibilities have been met) and will basically be responsible for reviewing the impact, from a financial, customer and enterprise level, to determine if this change should proceed.

The Executive CAB is made up of the following members:

• Senior level manager with financial responsibilities.
• managers (or their designates).
• Change Manager.
• Local Change Manager (for all areas with associated responsibilities to the change).
• Subject Matter Experts (for all areas with associated responsibilities to the change).

Emergency CAB

This board will only review changes that have been marked as an Emergency. This board will be chaired by the Change Manager and will only be called to session as needed. Depending on the risk associated with delaying the time to implement the change, this board may be convened as a formal face-to-face meeting for approval, a conference call approval or electronic approval. Members will be notified by pager and a voicemail and or e-mail will be distributed specifying the type of approval method for their review and approval. Not all Emergency Changes require review by the Emergency CAB. The Change Manager will make this determination with the help of the Local Change Managers and SMEs.

The following are the responsibilities of the Emergency CAB:

• Immediate response to a page to convene.
• Determine if adequate testing has been performed or if testing can be waived.
• Ensure build plan is adequate.
• Review back-out plan or waive the requirement of the plan.
• Assess impact of not performing the change.
• Assess impact of performing the change quickly.
• Review FSC to determine if requested time is appropriate.
• Determine actual approved time for implementation.
• Determine best means to communicate the change.

The Emergency CAB is made up of the following members:

• A subset of CAB.
• Local Change Manager.
• SME.
• Change Manager.
• Representative from the Service Desk.
• Representative from Security Services.
• Representative from Availability Services.

Change Managers

The following duties are the responsibility of both the Corporate and Local Change Manager:

• Ensures changes do not lead to unplanned unavailability of the IT environment.
• Ensures only authorized and necessary changes are implemented.
• Ensures changes do not lead to new incidents.
• Ensures that changes are sensitive to the needs of the business.
• Ensures that changes balance organizational risk and need.
• Ensures clear and effective procedures are in place.
• Review all changes that have not been completed with a code of Successful.
• Review all outstanding RfCs awaiting consideration or awaiting action.
• Participates in Configuration Management Process Review and Evaluation.

The following duties are exclusively the responsibility of the Change Manager:

• Recommends treatment for changes that are deemed as an Emergency.
• Convenes Emergency CAB meetings for all Emergency RfCs.
• Decides on CAB meeting attendance requirements based on content of scheduled RfCs and ensure review material is available.
• Chairs all Corporate and Emergency CAB meetings.
• Ensures accuracy and communication of the Forward Schedule of Changes.
• Ensures that all CABs are sufficiently authoritative and effective.
• Raises change related issues to the IT governing body.
• Tables all RfCs for a CAB meeting, issue an agenda and circulate all RfCs to CAB members in advance of meetings to allow prior consideration.
• Closes Unsuccessful, Backed Out and Canceled RfCs.
• Produces management reports citing performance statistics for Change Management.
• After consideration of the advice given by the CAB or Emergency CAB, authorizes acceptable Changes.
• Keeps informed of changes implemented by service partners which may impact the infrastructure. Imparts to those organizations any information on the impact of their changes and ensure that all such changes are included in the Forward Schedule of Changes.
• Keeps business areas contacts informed of Changes and help interpret Changes into "HOW THE CHANGE WILL AFFECT THEM" or "WHAT THEY MAY SEE" topics.

Change Coordinator

• Primary interface with Local CABs.
• Receive, log and allocate a priority, in collaboration with the initiator, to all RfCs.
• Reject any RfCs that are totally impractical or insufficiently documented.
• Work with implementer and business areas when necessary.
• Participate in CAB meetings and take minutes.
• Communicate minutes and attendance to all CAB members and management.
• Involvement in reviewing changes with a completed code other than Successful.
• Act on behalf of the Change Manager when unavailable.

Change Implementer

In general the responsibilities of the Change Implementer are:

• Provides preliminary information relating to the Change as early as possible to facilitate long range scheduling of the Change in relation to other pending and anticipated Changes.
• Firms up details of the Change by completing the RfC with appropriate information.
• Performs or arranges for testing of the Change in an environment as close as possible to the "live" environment - i.e., pre-production.
• Notes any risks which may result from the environment not being an exact replica of the production environment.
• Develop "Build Books" and back-out and recovery procedures.
• Tests back-out and recovery and certifies them for the implementation.
• Certifies that the Change is ready to be implemented into the Production environment.
• Presents Change Implementation Plan to CAB membership at a convened CAB meeting for approval.
• Supervises the Change implementation and certifies it as either:
  • Completed successfully, or
  • Completed with variations from Build procedures, or
  • Backed out - original environment re-created exactly, or
  • Backed out - differences from original environment - notes difference.

• leads post-implementation review of Change and logs results of review on RfC (or other vehicle for recording results).

Change Tester

• Provides independent assurance that a Change is technically advisable and that risks to implicated CIs have been properly considered
• Assures that testing includes adequate regression testing to ensure that other areas of the infrastructure are not adversely affected by the Change.
• The Tester role is responsible for the core activities of the test effort:
  • Planning and management of test resources
  • Assess the progress and effectiveness of the test effort
• Identify the test approach and use relevant test techniques:
  • Functional
  • Performance
• Defines appropriate tests and associated test data
• Implements and execute tests
• Evaluates the outcome of each test

Configuration Manager

• Facilitates negotiation of the scope of the configuration management process, in collaboration with the project steering committee, Owner and IT business stakeholders.
• Identifying which CIs need to be managed and controlled from this base of inventory - asset (including contracts, costs, vendors and warranties) and Configuration Management.
• Ensures data integrity and compliance, distributing management reports and defining integration with other IT systems and processes.
• Continually reviews the configuration management process for efficiency and effectiveness.
• Plans and executes population of the CMDB (manual or automated), performing regular housekeeping and plans for growth.
• Defines which CI types and attributes are to be tracked within their respective technical domain.
• Uploads the data from existing data repositories into the central CMDB.
• Updates the CI records under their control on an ongoing basis.
• Maintains the system and service relationships of the CIs under their control.
• Assists with periodic integrity audits on the CIs within their domain.

Service Desk

• Verify CI information related to user and assets are accurate and update if necessary.
• Remain aware of Change schedules and the impact areas which might be affected by Changes.
• Participates in CAB with the view of imparting a Service perspective to proposed Change requests.
• Is either direct responsibility for communicating information on Changes to Users and/or User Groups or for re-directing inquiries with regard to a Change to the appropriate person (e.g. Change Implementer and/or Change Coordinator).

Performance Measurement

Critical Success Factors	Key Process Indicators	Metric	Application/ Fields
Protect Service	Improvement in Customer Satisfaction Survey on Change	Survey Results	Manual Effort
	Percentage reduction in Changes causing Incidents	Changes causing incidents - by urgency	Online Services/Related IM Tickets
	Percentage reduction in Changes impacting SLA service hours	Changes impacting SLA service hours	Online Services/tbd & Manual Effort
	Percentage reduction in failed changes that do not have a recorded back-out plan	Failed changes without a back out plan	Online Services/tbd
	Percentage reduction in Incidents causing Change	Incidents causing Change - by urgency	Online Services/Related IM Tickets
	Percentage reduction of unsuccessful changes	Unsuccessful changes	Online Services/tbd
	Reduction in percentage of changes referred to the Emergency CAB	Changes referred to Emergency CAB	Online Services/tbd
Repeatable Process	Percentage Change Requests implemented on time	Changes Implemented on time	Online Services/vs Actual Start times
	Percentage fewer changes "backed out"	Changes Backed out by reason	Online Services/tbd
	Percentage fewer rejected RfCs	Rejected RfCs	Online Services/Approval Status = Rejected
	Percentage reduction in Changes required by previous Change failures	Changes related to Change failures	Online Services/tbd
	Percentage reduction in unauthorized Changes detected	Unauthorized Changes	Manual Effort
	Percentage reduction of Emergency Changes causing Incidents	Emergency Changes Causing Incidents	Online Services/Emergency CM & Related IM Tickets
	Percentage reduction of Emergency Changes requiring back-out	Emergency Changes backed out	Online Services/tbd
	Reduction in percentage of Changes implemented without being tested	Changes Implemented without being tested	Online Services/tbd
Show efficiency and effectiveness results	Percentage efficiency improvement based on number of RfCs processed	RfCs processed per unit time	Online Services/RfCs Per Group

Processes

CM0 - Change Management Overview

Inputs

• Request for Change

  The RFC is the primary form on which all information related to the change is recorded or referenced from. This form represents the permanent record of the Change and should be reviewed for accuracy and completeness by the Change Manager or Change Coordinator prior to CLOSING the Change. The results of a post-implementation review should be recorded for all Changes resulting from outages to Mission Critical systems.

• Change Calendar (FSOC)

  The Change Calendar (Forward Schedule of Change) lists the dates, times and resources required for all past and upcoming changes. It provides a database to notify interested stakeholders and users of outages and periods of heightened risk to the work environment.

• Incident Logs

  Detailed file of all incidents reported and recorded. These logs can contain information on the importance of the Change which can be used to determine its' relative priority amongst Change requests competing for a Change window.

• Cost Data

  Cost data provides information on the financial stakes involved in a Change and can be used to determine the relative importance of a Change Request.

  Problems

• Changes which are the result of a Root Cause Analysis performed by Problem Management will have valuable information for assessing the risks associated with a Change. Such factors might include:
  • any outstanding issues related to the solution (eg. solution might not work under certain conditions which are deemed low probability or risk)
  • the complexity of the solution and its' compatibility with products and services in use in the organization (perhaps as standards)
  • any phasing characteristics required for the solution or Change process
  • risk determination that the problem might re-surface in the future

• CMDB

  The Configuration Management Database contains the listing for all Configuration Items affected by the change and describes their inter-relationships and dependencies within the production environment. This information is used to assess the extent of the environment impacted by a Change and hence the risks associated with the Change. This assessment is recorded on the RFC by the Change Initiator and updated throughout the Change Process as the nature and extent of all risks become more apparent (eg. ability to back-out an implementation).

Controls

• Service Commitments

  Service Commitments determine how and when changes can be implemented. Ideally, they are expressed in SLAs outlining approved application change/maintenance windows. Associated Contracts with support vendors will also establish parameters around the change including timing, performance, backout procedures, etc.

• Training

  How well Change Implementers are trained in the specifics of particular changes will directly affect the degree of success in implementing changes. Foremost, amongst the qualifications should be a pre-disposition to plan and test a Change well so as to avoid unexpected results.

• Resources

  The availability of resources and specializations in the technologies and procedures of a change will affect the success of the venture. Specialized resources such as Testers and Risk Assessors will improve the outcomes from specific stages of the change lifecycle.

• Guidelines

  Documentation and guidelines for a change are important success factors. Build books and well established procedures used successfully in previous changes will go a long way to guaranteeing success. Building and updating a repository of Change material by type of change and the period review of this material will ensure that procedures are kept current and accurate.

Mechanisms

• Risk Assessment^R

  Change Management uses risk assessment to determine the extent of the potential threat and the risk associated with a change to the known and trusted state of the IT infrastructure. The output of this review helps to identify appropriate measures for reducing or eliminating risk during the change process or to avoid the risk entirely by not proceeding with the risk. To properly do this there must be a commensurate review of the risks associated with not doing the change.

  To determine the likelihood of a future adverse event, threats to an IT system must be analyzed in conjunction with the potential vulnerabilities and the controls in place for the IT system. Impact refers to the magnitude of harm that could be caused by a threat's exercise of a vulnerability. The level of impact is governed by the potential mission impacts and in turn produces a relative value for the IT assets and resources affected (e.g., the criticality and sensitivity of the IT system components and data). A risk assessment methodology encompasses nine primary steps:

  1. System Characterization
  2. Threat Identification
  3. Vulnerability Identification
  4. Control Analysis
  5. Likelihood Determination
  6. Impact Analysis
  7. Risk Determination
  8. Control Recommendations
  9. Results Documentation.

• CAB Meetings

  Minutes, decisions and notes are recorded following meetings of Change Advisory Boards. The mechanism by which this occurs will have a bearing on the effectiveness of a Change Management process. Variances may be attributable to:
  • the degree of expertise and authority granted to the membership
  • the extent of business representation
  • the degree to which the membership functions as a Team
  • the decision making model (eg. consensus, unanimity, etc)

• Change Scheduling

  The availability and accuracy of the Change Schedule will play a large role in determining customer and participant satisfaction with the Change Management process. To business the Change Calendar should be accompanied by broadcasts or selective e-mails noting any system outages or performance loss during change windows so that they can plan their business accordingly.

Outputs

• Implemented Change

  The net result of a change is an alteration in the 'known state' of the infrastructure. Hopefully, this results in a more reliable and stale production environment and/or one with greater capabilities for business operations.

  Unfortuneately, other outcomes are possible:

  • structural faults are introduced into the infrastructure;
  • these faults may result in incidents, problems, outages, reduced overall availability and performance;
  • the faults and ensuing issues may lead to the need to back-out the change at a convenient time;

• Completed RFC

  The RFC will be CLOSED following a quality review of its' content for completeness and accuracy.

• Updated Change Calendar

  The Change Calendar should indicate whether the change was successful or not. If not successful it should indicate any resulting, incident, problems or future change requests.

• CAB Minutes and notes

  The minutes and any notes attached to CAB meeting should be referenced on the RFC (the definitive document of the Change) and placed in a secure position under Change Management control. This information may be referenced for similar types of changes in the future - including subsequent iterations or related items to the change just completed.

• CMDB Updated

  New Configuration Items need to be recorded along with their associations in the CMDB. The replaced configuration items should be denoted in the CMDB as 'inoperative' or some other status denoting that they have been retired. These modifications are normally the job of the Configuration Manager.

Process Activities

CM1 - Log & Filter

CM1.1 - Initiate RfC

The Request for Change (RfC) serves as a formal record that is used to track the entire lifecycle of the change from initiation through completion recording the successes and failures of each step. RfCs should be submitted to the Change Coordinator and be assigned a unique identifier. At this time thed Change Coordinator or Local Change Manager will review and approval or reject them. The Change Coordinator or Local CAB may decide to appoint a different change implementer than the implementer designated by the change initiator.

An RfC should be submitted as soon as a change is contemplated including all know information at the time of submission and, over time, must contain all of the following information:

Change Initiator...

• A Categorization (Category, Type and Item [CTI]).
• The Severity (Major, Significant, Minor, Low).
• Short description.
• Detailed description.
• Lines of businesses, application and users impacted.
• The configuration items (CIs) impacted.
• Cross references to any reported Incidents, other changes and/or Problem Tickets giving rise to the Change.
• A description of the impact if the change were to take place or not be implemented.
• An assessment of the complexity.
• The change implementer, builder, support and backup personnel.
• An estimate of the time required to implement a change including time to implement the back out plan if required.
• Description of the testing methodology (including user acceptance testing) either already conducted or planned.
• Cross-reference to build books and back-out plans.
• Implementation date preference(s) and stated reason(s) for dates (e.g., available change window).

CM1.2 - RfC Filtering & Approval

The Local Change Manager is responsible for filtering and approving all Severity = Low RfCs. Working with the Local Change Coordinator, the Change Coordinator is responsible for filtering and approving all other RfCs. Filtering involves reviewing the RfCs for completeness including:

Change Coordinator or Local CAB...

• Determining if there is enough information to understand the Severity, urgency and priority.
• Estimating the likelihood of success and the potential effects of implementing.
• Comparing preferred dates with Forward Schedule of Change (FSC) to be aware of potential conflicts or redundant changes.
• Determining if this is a valid change and if resources can be assigned to this change.

Improperly filled out or incomplete RfCs will be returned to the Change Initiator for revision and the change log will be updated to reflect a status of "pending." This may occur if, for example, the change initiator did not provide enough information about the impact posed to the IT environment.

CM1.3 - Determine Treatment

Change Manager...

• Bring it to the Emergency CAB for authorization to implement (All Severity = Major Changes must be approved by the Emergency CAB).
• Approve the Change for immediate implementation and then review it with the Emergency CAB.
• Send it though the Change Planning process to be built and or tested.

CM2 - Change Planning

CM2.1 - Validate or Build Test Plan

Local Change Coordinator and Change Implementer...

• Document what is being changed
• Document what business areas will be impacted
• Work with impacted business areas to develop user testing requirements
• Work with business areas to coordinate the testing with the build process.

CM2.2 - Validate or Build Change & Back-out Plans

Local Change Coordinator and Change Implementer...

• Coordinate with all areas that have tasks associated with the RfC to build change procedures.
• Validate existing (e.g., Severity = Low Changes) or document build procedures

CM2.3 - Test Change & Back-out Plans

Local Change Coordinator and Change Implementer...

• Develop a test plan
• Test build procedures in a test environment that closely simulates the production environment
• Document all discrepancies between the test environment and the production environment
• Document the anticipated impact due to the documented discrepancies
• Document test results
• If testing cannot be done, document the reasons to justify the waiver of testing requirements

CM2.4 - Local CAB Review

Local Change Manager...

• Working through the Local CAB, the Local Change Manager approves or rejects all Changes where the Severity = Low
• The Local Change Manager may defer approval/rejection of Changes to Corporate CAB due to complexity of the Change

CM3 - Determine Priority & Authorize

CM3.1 - Determine Priority, Validated Severity & Urgency Priority

Change Manager, Initiator, Local Change Manager...

• Review all RfCs and work together to validate Severity, Urgency and determine Priority

CM3.2 - Corporate CAB Review

Corporate CAB...

• Reviews all Severity = Major or Significant changes
• Is a combination of formal meeting and electronic approvals as determined by Change Manager
• May defer approval/rejection of Change to Executive CAB due to financial or customer impact implications.
• Recommends approval or rejection of all Changes reviewed

  Change Manager...
  

• Chairs and publishes meeting minutes
• Approves or rejects Changes based on Corporate CAB recommendations
• Changes RfC status and updates ticket as appropriate

CM3.3 - Executive CAB Review

Executive CAB...

• Approval or rejection for all changes presented to them by the Change Manager

  Change Manager...
  

• Chairs and publishes meeting minutes
• Changes RfC status and updates ticket as appropriate

CM3.4 - Emergency CAB Review

Initiator...

• Submits RfC and marks the change as an Emergency
• Reviews RfC with Local Change Manager

  Local Change Manager...
  

• Reviews RfC with Initiator and verifies that the change is an Emergency.
• Reviews RfC with Change Manager.

  Change Manager...
  

• Calls and chairs emergency meeting and publishes meeting minutes
• Approves or rejects Changes based on Emergency CAB recommendations
• Changes RfC status and updates ticket as appropriate

  Emergency CAB...
  

• Reviews all Emergency Changes
• Is a combination of formal meeting and electronic approvals as determined by Change Manager
• May defer approval/rejection of Change to Executive CAB due to financial or customer impact implications
• Recommends approval or rejection of all Changes reviewed

CM3.5 - Change Manager Review

Change Manager...

• Approves or rejects all Changes where the Severity = Minor

CM4 - Implement Change

CM4.1 - Implement Change

Implementer...

• Start change at scheduled time
• Move the change status to WIP at start of implementation
• Follow documented build process
• Monitor activities and keep RfC log updated
• Test the success of the change (include user testing if necessary)
• If change is unsuccessful implement documented back-out plan
• Upon completion, change the status to completed with the appropriate completion code
• Update log with explanations for all changes with a completion code other than successful
• Participate in all reviews of your changes if necessary.

CM4.2 - Perform Back-ou

Implementer...

• If it is determined that the change is unsuccessful, back-out plan should be implemented as soon as possible.
• Be aware of other changes that may have occurred between the time of implementation and the completion of the Back-out plan.
• Assure that the production environment has been restored to the previous known state.
• Change the status of the RfC to "Completed" with a completion code of Backed Out.
• Update the log with all information related the decision for backing out the change.

CM5 - Change Review

CM5.1 - Change Review

Corporate & Local Change Manager, Change Coordinator, CABs, SME, Implementer, Problem Management
• It is the responsibility of the Local Change Manager to review how well their area implements changes into the environment. The Change Manager will randomly review all changes that have a completion code of 'Successful'. (These are changes that have met their objectives, were completed within the scheduled time frame and have no known incidents related to the change). These will be looked at for content, accuracy and actual date and time stamps to view the flow through the process. This will help manage improvement to the process.

  The Change Manager will be notified of all changes that are placed in a completed status with a completion code other than 'Successful'. These RfCs would not be automatically taken to a status of closed and must be manually closed by the Change Manager or Coordinator. The Change Manager will work with Incident Management, Problem Management, Implementer, Local Change Manager and SME to review these RfCs and determine what needs to be done to improve the success rate on changes of that type. There may be times when the CAB would be responsible for helping to provide a post mortem of the change because of the scope or impact of that change. A report will be created for each RfC reviewed that will contain answers to the following questions:

  • Why was the completion code chosen?
  • Was this issue caused by items within or outside of our control?
  • What could we do in the future to correct or prevent this from occurring again?
  • Process wise what can be done to correct or prevent this from occurring again?
  Was this change reviewed at the appropriate CAB level?

Appendix

Request for Change Processes

Throughout this process the RfC status indicates its' progress through the change lifecycle. The table below defines the various RfC statuses:

STATUS	DESCRIPTION
New	The RfC is considered New while it is being created.
Assigned	Once the RfC is saved its status moves to Assigned and it is automatically routed to the appropriate Change Coordinator or a Local Change Advisory Board (CAB) for authorization to proceed.
Approved	The RfC is considered Approved after it has been reviewed and accepted by the Change Coordinator or appropriate Local CAB who grants approval for the change build to occur. (Note: This is not approval to proceed with implementation -- that is granted after the build when the Change Implementer returns to the Change Manager or appropriate CAB for approval to proceed with implementing the change.)
Planning	Once an RfC has been approved, the status is changed to Planning by the Implementer. During this stage all areas involved in implementing this change will be responsible for creating build, test and back-out plans. This is also the time when testing of the build and back-out plans would be performed
Pending	At any point in time the RfC may be placed in a Pending status awaiting additional information, materials or other resources required to process
Scheduled	Once the change is ready for implementation and its schedule approved by the Change Manager or CAB, its status is changed to Scheduled.
Work-in-progress	The RfC is placed in Work-in-progress by the Implementer at the actual start time of the change implementation.
Completed	Upon completion of the change the implementer moves the RfC to the Completed status and chooses one of the following completion codes: Successful - The change should meet the designed objectives, completed within the scheduled change window, and have no known incidents associated with the change. Successful with incident - The change has met the designed objectives, and has known incidents associated with the change or was not completed within the scheduled change window. Known incidents must be associated with the RfC responsible for those incidents. Backed out - The change was unsuccessful or when it has been determined that, even though the change was successful, the new state of the environment is not acceptable. The back out plan has been implemented and the system has successfully been returned to its state prior to the change having been applied. . If any other changes have been made to the CI during the interim period consideration should be given to having them removed as well since the environment cannot be definitively returned to a known state unless they too are removed Unsuccessful - if, after evaluation, the change did not meet the design objectives. Any change that is deemed to be unsuccessful will have the reasons for the failure documented in the Change Ticket. Cancelled - At any stage prior to moving to a status of Work-in-progress, the status of the change may be changed to Completed with a completed code of Cancelled. If the change is in progress then it must be closed with a status of Unsuccessful or Backed Out .
Closed	All changes that have been marked completed with a completion code of Successful or Cancelled will automatically have their status changed to Closed, 10 days following implementation. RfCs with any other completion code will be reviewed by Change Management prior to closing. Rescheduling of Backed-Out, Unsuccessful, or Cancelled changes require a new RfC with the previous RfC related to it.

Change Action Summaries

Change Approval, Authorization & Scheduling Summary

The following outlines how the Change approval and scheduling process works:

1. Initiator submits the RfC with approval of their management. Items to be aware of prior to submittal are need for change, lead time of change, resource requirements and items already on the forward schedule of change calendar.
2. Change is reviewed and filtered for content and completeness by the Change Coordinator and or the Local Change Manager. At this point the RfC itself is either approved or rejected. This does not signify approval to perform the Change.
3. If the RfC is authorized to move forward, the Status is changed to Approved and the initiator and implementer are notified of the status change.
4. If rejected, the RfC is sent back to initiator with an explanation of why and what needs to be done prior to resubmission (All rejected RfCs must be resubmitted at the beginning of the process).
5. Once approved, the implementer will change the RfC status to Planning.
6. After the Change is planned (build and test change and back-out plans), depending on its Severity it must be authorized by one of the following approval authorities prior to implementation:
   • Major Changes require authorization from the Executive CAB.
   • Significant Changes require authorization from the Corporate CAB.
   • Minor Changes require authorization from the Change Manager.
   • Low Changes require authorization from the Local CAB.
   • Standard Changes do not require additional CAB approvals during implementation.
7. If authorized, the status will be changed to Scheduled and the Implementer and Initiator would be notified. Once placed in this status the proposed date and time of the change becomes the actual scheduled date and time and can only be changed by the Change Manager (this is required so that change Management can determine what level of review this change must undergo due to a date or time change). Prior to this RfC being moved to a Scheduled status the proposed date and time can be changed by the Initiator, Implementer or Change Manager.
8. The proposed date and time is a required field in the RfC. This is the field that is used for the scheduled date and time in the Forward Schedule of Change (FSC). As this field is changed the scheduled date and time is changed accordingly in the FSC. This allows areas to submit a change as early as possible and provide them with the flexibility to move that date until the change has been approved for implementation.
9. If rejected the RfC is sent back to initiator with an explanation of why and what needs to be done prior to resubmission (all rejected RfCs must be resubmitted at the beginning of the process).
10. In the case of an Emergency Change, the Initiator will mark the RfC as an Emergency. The Change Manager will be automatically paged and review the change with the Local Change Manager and SME to determine if they will have to invoke a session of the Executive CAB. The session of the Executive CAB may be conference call, electronic approval or a formal meeting depending on the perceived risk associated with delaying the time to implementation.
11. With the recommendations of the Local Change Manager and SME or of the Executive CAB, the Change Manager will approve the change update the status to Scheduled. In most cases the change would probably not be rejected but Change Management may determine that the requested window of the change be moved to accommodate customer needs or reduce the impact the change may have.

Severity, Urgency, Priority, Approval, and Authorization Relationships

Severity: (Degree of impact to business)	*Urgency: (Speed at which the change should be made)	Approved by: (Approved to move into the planning phase)	Authorized by:  (Authorized to Implement)	**Priority: (Speed at which the change will be made in relationship to other pending Changes)	RfC Lead Time:  (Minimum time the RfC should be submitted prior to the change implementation date)
Major	Emergency	Change Coordinator	Emergency CAB	Urgent	As Soon As Practical
	Low, Medium, High, Urgent	Change Coordinator	Executive CAB	Set by the Change Manager Low, Medium, High	Minimum 15 Business Days
Significant	Emergency	Change Coordinator	Emergency CAB	Urgent	As Soon As Practical
	Low, Medium, High, Urgent	Change Coordinator	Corporate CAB	Set by the Change Manager Low, Medium, High	Minimum 15 Business Days
Minor	Emergency	Change Coordinator	Emergency CAB	Urgent	As Soon As Practical
	Low, Medium, High, Urgent	Change Coordinator	Change Manager	Set by the Change Manager Low, Medium, High	Minimum 5 Business Days
Low	Low, Medium, High, Urgent	Local Change Manager	Local CAB	Set by the Local Change Manager Low, Medium, High	Minimum 2 Business Days
Standard	Low, Medium, High, Urgent	Service Provider	Pre-Authorized by Corporate CAB	Service Provider	n/a

Change Severity Selection Guidelines