Optimize IT Change Management

Optimize IT Change Management

Right-size IT change management practice to protect the live environment.

EXECUTIVE BRIEF

Analyst Perspective

Balance risk and efficiency to optimize IT change management.

Change management (change enablement, change control) is a balance of efficiency and risk. That is, pushing changes out in a timely manner while minimizing the risk of deployment. On the one hand, organizations can attempt to avoid all risk and drown the process in rubber stamps, red tape, and bureaucracy. On the other hand, organizations can ignore process and push out changes as quickly as possible, which will likely lead to change related incidents and debilitating outages.

Right-sizing the process does not mean adopting every recommendation from best-practice frameworks. It means balancing the efficiency of change request fulfillment with minimizing risk to your organization. Furthermore, creating a process that encourages adherence is key to avoid change implementers from skirting your process altogether.

Benedict Chang, Research Analyst, Infrastructure and Operations, Info-Tech Research Group

Executive Summary

Your Challenge

Infrastructure and application change occurs constantly and is driven by changing business needs, requests for new functionality, operational releases and patches, and resolution of incidents or problems detected by the service desk.

IT managers need to follow a standard change management process to ensure that rogue changes are never deployed while the organization remains responsive to demand.

Common Obstacles

IT system owners often resist change management because they see it as slow and bureaucratic.

At the same time, an increasingly interlinked technical environment may cause issues to appear in unexpected places. Configuration management systems are often not kept up-to-date and do not catch the potential linkages.

Infrastructure changes are often seen as “different” from application changes and two (or more) processes may exist.

Info-Tech’s Approach

Info-Tech’s approach will help you:

• Create a unified change management practice that balances risk and throughput of innovation.
• Categorize changes based on an industry-standard risk model with objective measures of impact and likelihood.
• Establish and empower a Change Manager and Change Advisory Board (CAB) with the authority to manage, approve, and prioritize changes.

Balance Risk and Efficiency to Optimize IT Change Management

Two goals of change management are to protect the live environment and deploying changes in a timely manner. These two may seem to sometimes be at odds against each other, but assessing risk at multiple points of a change’s lifecycle can help you achieve both.

Your challenge

This research is designed to help organizations who need to:

• Build a right-sized change management practice that encourages adherence and balances efficiency and risk.
• Integrate the change management practice with project management, service desk processes, configuration management, and other areas of IT and the business.
• Communicate the benefits and impact of change management to all the stakeholders affected by the process.

Change management is heavily reliant on organizational culture

Having a right-sized process is not enough. You need to build and communicate the process to gather adherence. The process is useless if stakeholders are not aware of it or do not follow it.

Increase the Effectiveness of Change Management in Your Organization

Of the eight infrastructure & operations processes measured in Info-Tech’s IT Management and Governance Diagnostic (MGD) program, change management has the second largest gap between importance and effectiveness of these processes.

Source: Info-Tech 2020; n=5,108 IT professionals from 620 organizations

Common obstacles

These barriers make this challenge difficult to address for many organizations:

• Gaining buy-in can be a challenge no matter how well the process is built.
• The complexity of the IT environment and culture of tacit knowledge for configuration makes it difficult to assess cross-dependencies of changes.
• Each silo or department may have their own change management workflows that they follow internally. This can make it difficult to create a unified process that works well for everyone.

“Why should I fill out an RFC when it only takes five minutes to push through my change?”

“We’ve been doing this for years. Why do we need more bureaucracy?”

“We don’t need change management if we’re Agile.”

“We don’t have the right tools to even start change management.”

“Why do I have to attend a CAB meeting when I don’t care what other departments are doing?”

Info-Tech’s approach

Build change management by implementing assessments and stage gates around appropriate levels of the change lifecycle.

The Info-Tech difference:

1. Create a unified change management process that balances risk and throughput of innovation.
2. Categorize changes based on an industry-standard risk model with objective measures of impact and likelihood.
3. Establish and empower a Change Manager and Change Advisory Board (CAB) with the authority to manage, approve, and prioritize changes.

IT change is constant and is driven by:

Change Management:

1. Operations - Operational releases, maintenance, vendor-driven updates, and security updates can all be key drivers of change. Example: ITSM version update
   • Major Release
   • Maintenance Release
   • Security Patch
2. Business - Business-driven changes may include requests from other business departments that require IT’s support. Examples: New ERP or HRIS implementation
   • New Application
   • New Version
3. Service desk → Incident & Problem - Some incident and problem tickets require a change to facilitate resolution of the incident. Examples: Outage necessitating update of an app (emergency change), a user request for new functionality to be added to an existing app
   • Workaround
   • Fix
4. Configuration Management Database (CMDB) ↔ Asset Management - In addition to software and hardware asset dependencies, a configuration management database (CMDB) is used to keep a record of changes and is queried to assess change requests.
   • Hardware
   • Software

Insight summary

“The scope of change management is defined by each organization…the purpose of change management is to maximize the number of successful service and product changes by ensuring that the risk have been properly assessed, authorizing changes to process, and managing the change schedule.” – ALEXOS Limited, ITIL 4

Build a unified change management process balancing risk and change throughput.

Building a unified process that oversees all changes to the technical environment doesn’t have to be burdensome to be effective. However, the process is a necessary starting point to identifying cross dependencies and avoiding change collisions and change-related incidents.

Use an objective framework for estimating risk

Simply asking, “What is the risk?” will result in subjective responses that will likely minimize the perceived risk. The level of due diligence should align to the criticality of the systems or departments potentially impacted by the proposed changes.

Integrate your change process with your IT service management system

Change management in isolation will provide some stability, but maturing the process through service integrations will enable data-driven decisions, decrease bureaucracy, and enable faster and more stable throughput.

Change management and DevOps can work together effectively

Change and DevOps tend to be at odds, but the framework does not have to change. Lower risk changes in DevOps are prime candidates for the pre-approved category. Much of the responsibility traditionally assigned to the CAB can be diffused throughout the software development lifecycle.

Change management and DevOps can coexist

Shift the responsibility and rigor to earlier in the process.

• If you are implementing change management in a DevOps environment, ensure you have a strong DevOps lifecycle. You may wish to refer to Info-Tech’s research Implementing DevOps Practices That Work.
• Consider starting in this blueprint by visiting Appendix II to frame your approach to change management. Follow the blueprint while paying attention to the DevOps Callouts.

DEVOPS CALLOUTS

Look for these DevOps callouts throughout this storyboard to guide you along the implementation.

Successful change management will provide benefits to both the business and IT

Respond to business requests faster while reducing the number of change-related disruptions.

IT Benefits

• Fewer change-related incidents and outages
• Faster change turnaround time
• Higher rate of change success
• Less change rework
• Fewer service desk calls related to poorly communicated changes

Business Benefits

• Fewer service disruptions
• Faster response to requests for new and enhanced functionalities
• Higher rate of benefits realization when changes are implemented
• Lower cost per change
• Fewer “surprise” changes disrupting productivity

IT satisfaction with change management will drive business satisfaction with IT. Once the process is working efficiently, staff will be more motivated to adhere to the process, reducing the number of unauthorized changes. As fewer changes bypass proper evaluation and testing, service disruptions will decrease and business satisfaction will increase.

Change management improves core benefits to the business: the four Cs

Most organizations have at least some form of change control in place, but formalizing change management leads to the four Cs of business benefits:

Control

Change management brings daily control over the IT environment, allowing you to review every relatively new change, eliminate changes that would have likely failed, and review all changes to improve the IT environment.

Collaboration

Change management planning brings increased communication and collaboration across groups by coordinating changes with business activities. The CAB brings a more formalized and centralized communication method for IT.

Consistency

Request for change templates and a structured process result in implementation, test, and backout plans being more consistent. Implementing processes for pre-approved changes also ensures these frequent changes are executed consistently and efficiently.

Confidence

Change management processes will give your organization more confidence through more accurate planning, improved execution of changes, less failure, and more control over the IT environment. This also leads to greater protection against audits.

You likely need to improve change management more than any other infrastructure & operations process

Source: Info-Tech 2020; n=5,108 IT Professionals from 620 organizations

Of the eight infrastructure and operations processes measured in Info-Tech’s IT Management and Governance Diagnostic (MGD) program, change management consistently has the second largest gap between importance and effectiveness of these processes.

Executives and directors recognize the importance of change management but feel theirs is currently ineffective

Info-Tech’s IT Management and Governance Diagnostic (MGD) program assesses the importance and effectiveness of core IT processes. Since its inception, the MGD has consistently identified change management as an area for immediate improvement.

Source: Info-Tech 2020; n=5,108 IT Professionals from 620 organizations

Importance Scores

No importance: 1.0-6.9

Limited importance: 7.0-7.9

Significant importance: 8.0-8.9

Critical importance: 9.0-10.0

Effectiveness Scores

Not in place: n/a

Not effective: 0.0-4.9

Somewhat Ineffective: 5.0-5.9

Somewhat effective: 6.0-6.9

Very effective: 7.0-10.0

There are several common misconceptions about change management

Which of these have you heard in your organization?

Overcome perceived challenges to implementing change management to reap measurable reward

Before: Informal Change Management

Change Approval:

• Changes do not pass through a formal review process before implementation.
• 10% of released changes are approved.
• Implementation challenge: Staff will resist having to submit formal change requests and assessments, frustrated at the prospect of having to wait longer to have changes approved.

Change Prioritization

• Changes are not prioritized according to urgency, risk, and impact.
• 60% of changes are urgent.
• Implementation challenge: Influential stakeholders accustomed to having changes approved and deployed might resist having to submit changes to a standard cost-benefit analysis.

Change Deployment

• Changes often negatively impact user productivity.
• 25% of changes are realized as planned.
• Implementation challenge: Engaging the business so that formal change freeze periods and regular maintenance windows can be established.

After: Right-Sized Change Management

Change Approval

• All changes pass through a formal review process. Once a change is repeatable and well-tested, it can be pre-approved to save time. Almost no unauthorized changes are deployed.
• 95% of changes are approved.
• KPI: Decrease in change-related incidents

Change Prioritization

• The CAB prioritizes changes so that the business is satisfied with the speed of change deployment.
• 35% of changes are urgent.
• KPI: Decrease in change turnaround time.

Change deployment

• Users are always aware of impending changes and changes don’t interrupt critical business activities.
• Over 80% of changes are realized as planned
• KPI: Decrease in the number of failed deployments.

Info-Tech’s methodology for change management optimization focuses on building standardized processes

Blueprint deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Change Management Process Library

Document your normal, pre-approved, and emergency change lifecycles with the core process workflows .

Change Management Risk Assessment Tool

Test Drive your impact and likelihood assessment questionnaires with the Change Management Risk Assessment Tool.

Project Summary Template

Summarize your efforts in the Optimize IT Change Management Improvement Initiative: Project Summary Template.

Change Management Roadmap Tool

Record your action items and roadmap your steps to a mature change management process.

Key Deliverable:

Change Management SOP

Document and formalize your process starting with the change management standard operating procedure (SOP).

These case studies illustrate the value of various phases of this project

Define Change Management

Establish Roles and Workflows

Define RFC and Post-Implementation Activities

Measure, Manage, and Maintain

A major technology company implemented change management to improve productivity by 40%. This case study illustrates the full scope of the project.

A large technology firm experienced a critical outage due to poor change management practices. This case study illustrates the scope of change management definition and strategy.

Ignorance of change management process led to a technology giant experiencing a critical cloud outage. This case study illustrates the scope of the process phase.

A manufacturing company created a makeshift CMDB in the absence of a CMDB to implement change management. This case study illustrates the scope of change intake.

A financial institution tracked and recorded metrics to aid in the success of their change management program. This case study illustrates the scope of the implementation phase.

Working through this project with Info-Tech can save you time and money

Engaging in a Guided Implementation doesn’t just offer valuable project advice, it also results in significant cost savings.

Case Study

Industry: Technology

Source: Daniel Grove, Intel

Intel implemented a robust change management program and experienced a 40% improvement in change efficiency.

Founded in 1968, the world’s largest microchip and semiconductor company employs over 100,000 people. Intel manufactures processors for major players in the PC market including Apple, Lenovo, HP, and Dell.

ITIL Change Management Implementation

With close to 4,000 changes occurring each week, managing Intel’s environment is a formidable task. Before implementing change management within the organization, over 35% of all unscheduled downtime was due to errors resulting from change and release management. Processes were ad hoc or scattered across the organization and no standards were in place.

Results

After a robust implementation of change management, Intel experienced a number of improvements including automated approvals, the implementation of a formal change calendar, and an automated RFC form. As a result, Intel improved change productivity by 40% within the first year of the program’s implementation.

Define Change Management

↓

Establish Roles and Workflows

↓

Define RFC and Post-Implementation Activities

↓

Measure, Manage, and Maintain

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful."

Guided Implementation

"Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track."

Workshop

"We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place."

Consulting

"Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project."

Diagnostics and consistent frameworks are used throughout all four options.

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is between 8 to 12 calls over the course of 4 to 6 months.

Define Change Management

• Call #1: Introduce change concepts.
• Call #2: Assess current maturity.
• Call #3: Identify target-state capabilities.

Establish Roles and Workflows

• Call #4: Review roles and responsibilities.
• Call #5: Review core change processes.

Define RFC and Post- Implementation Activities

• Call #6: Define change intake process.
• Call #7: Create pre-implementation and post-implementation checklists.

Measure, Manage, and Maintain

• Call #8: Review metrics.
• Call #9: Create roadmap.

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Phase 1

Define Change Management

Define Change Management

1.1 Assess Maturity

1.2 Categorize Changes and Build Your Risk Assessment

Establish Roles and Workflows

2.1 Determine Roles and Responsibilities

2.2 Build Core Workflows

Define the RFC and Post-Implementation Activities

3.1 Design the RFC

3.2 Establish Post-Implementation Activities

Measure, Manage, and Maintain

4.1 Identify Metrics and Build the Change Calendar

4.2 Implement the Project

This phase will guide you through the following steps:

• Assess Maturity
• Categorize Changes and Build Your Risk Assessment

This phase involves the following participants:

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

Step 1.1

Assess Maturity

Activities

1.1.1 Outline the Organization’s Strengths and Challenges

1.1.2 Complete a Maturity Assessment

This step involves the following participants:

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

Outcomes of this step

• An understanding of maturity change management processes and frameworks
• Identification of existing change management challenges and potential causes
• A framework for assessing change management maturity and an assessment of your existing change management processes

Define Change Management

Step 1.1: Assess Maturity → Step 1.2: Categorize Changes and Build Your Risk Assessment

Change management is often confused with release management, but they are distinct processes

Change

• Change management looks at software changes as well as hardware, database, integration, and network changes, with the focus on stability of the entire IT ecosystem for business continuity.
• Change management provides a holistic view of the IT environment, including dependencies, to ensure nothing is negatively affected by changes.
• Change documentation is more focused on process, ensuring dependencies are mapped, rollout plans exist, and the business is not at risk.

Release

• Release and deployment are the detailed plans that bundle patches, upgrades, and new features into deployment packages, with the intent to change them flawlessly into a production environment.
• Release management is one of many actions performed under change management’s governance.
• Release documentation includes technical specifications such as change schedule, package details, change checklist, configuration details, test plan, and rollout and rollback plans.

Info-Tech Insight

Ensure the Release Manager is present as part of your CAB. They can explain any change content or dependencies, communicate business approval, and advise the service desk of any defects.

Integrate change management with other IT processes

As seen in the context diagram, change management interacts closely with many other IT processes including release management and configuration management (seen below). Ensure you delineate when these interactions occur (e.g. RFC updates and CMDB queries) and which process owns each task.

Avoid the challenges of poor change management

1. Deployments
   • Too frequent: The need for frequent deployments results in reduced availability of critical business applications.
   • Failed deployments or rework is required: Deployments are not successful and have to be backed out of and then reworked to resolve issues with the installation.
   • High manual effort: A lack of automation results in high resource costs for deployments. Human error is likely, which adds to the risk of a failed deployment.
2. Incidents
   • Too many unauthorized changes: If the process is perceived as cumbersome and ineffective, people will bypass it or abuse the emergency designation to get their changes deployed faster.
   • Changes cause incidents: When new releases are deployed, they create problems with related systems or applications.
3. End Users
   • Low user satisfaction: Poor communication and training result in surprised and unhappy users and support staff.

“With no controls in place, IT gets the blame for embarrassing outages. Too much control, and IT is seen as a roadblock to innovation.” – Anonymous, VP IT of a federal credit union

1.1.1 Outline the Organization’s Strengths and Challenges

Input

• Current change documentation (workflows, SOP, change policy, etc.)
• Organizational chart(s)

Output

• List of strengths and challenges for change management

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Project Summary Template

Participants

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

1. As group, discuss and outline the change management challenges facing the organization. These may be challenges caused by poor change management processes or by a lack of process.
2. Use the pain points found on the previous slide to help guide the discussion.
3. As a group, also outline the strengths of change management and the strengths of the current organization. Use these strengths as a guide to know what practices to continue and what strengths you can leverage to improve the change management process.
4. Record the activity results in the Project Summary Template.

Download the Optimize IT Change Management Improvement Initiative: Project Summary Template

Assess current change management maturity to create a plan for improvement

Info-Tech Insight

Reaching an optimized level is not feasible for every organization. You may be able to run a very good change management process at the Proactive or even Controlled stage. Pay special attention to keeping your goals attainable.

1.1.2 Complete a Maturity Assessment

Input

• Current change documentation (workflows, SOP, change policy, etc.)

Output

• Assessment of current maturity level and goals to improve change management

Materials

• Change Management Maturity Assessment Tool

Participants

• Change Manager
• Service Desk Manager
• Operations (optional)

1. Use Info-Tech’s Change Management Maturity Assessment Tool to assess the maturity and completeness of your change process.
2. Significant gaps revealed in this assessment should be the focal points of your discussion when investigating root causes and brainstorming remediation activities:
   1. For each activity of each process area of change management, determine the degree of completeness of your current process.
   2. Review your maturity assessment results and discuss as a group potential reasons why you arrived at your maturity level. Identify areas where you should focus your initial attention for improvement.
   3. Regularly review the maturity of your change management practices by completing this maturity assessment tool periodically to identify other areas to optimize.

Download the Change Management Maturity Assessment Tool

Case Study

Even Google isn’t immune to change-related outages. Plan ahead and communicate to help avoid change-related incidents

Industry: Technology

Source: The Register

As part of a routine maintenance procedure, Google engineers moved App Engine applications between data centers in the Central US to balance out traffic.

Unfortunately, at the same time that applications were being rerouted, a software update was in progress on the traffic routers, which triggered a restart. This temporarily diminished router capacity, knocking out a sizeable portion of Google Cloud.

The server drain resulted in a huge spike in startup requests, and the routers simply couldn’t handle the traffic.

As a result, 21% of Google App Engine applications hosted in the Central US experienced error rates in excess of 10%, while an additional 16% of applications experienced latency, albeit at a lower rate.

Solution

Thankfully, engineers were actively monitoring the implementation of the change and were able to spring into action to halt the problem.

The change was rolled back after 11 minutes, but the configuration error still needed to be fixed. After about two hours, the change failure was resolved and the Google Cloud was fully functional.

One takeaway for the engineering team was to closely monitor how changes are scheduled. Ultimately, this was the result of miscommunication and a lack of transparency between change teams.

Step 1.2

Categorize Changes and Build Your Risk Assessment

Activities

1.2.1 Define What Constitutes a Change

1.2.2 Build a Change Categorization Scheme

1.2.3 Build a Classification Scheme to Assess Impact

1.2.4 Build a Classification Scheme to Define Likelihood

1.2.5 Evaluate and Adjust Your Risk Assessment Scheme

Define Change Management

Step 1.1: Assess Maturity → Step 1.2: Categorize Changes and Build Your Risk Assessment

This step involves the following participants:

• Infrastructure/Applications Manager
• Change Manager
• Members of the Change Advisory Board

Outcomes of this step

• A clear definition of what constitutes a change in your organization
• A defined categorization scheme to classify types of changes
• A risk assessment matrix and tool for evaluating and prioritizing change requests according to impact and likelihood of risk

Change must be managed to mitigate risk to the infrastructure

Change management is the gatekeeper protecting your live environment.

Successfully managed changes will optimize risk exposure, severity of impact, and disruption. This will result in the bottom-line business benefits of removal of risk, early realization of benefits, and savings of money and time.

• IT change is constant; change requests will be made both proactively and reactively to upgrade systems, acquire new functionality, and to prevent or resolve incidents.
• Every change to the infrastructure must pass through the change management process before being deployed to ensure that it has been properly assessed and tested, and to check that a backout /rollback plan is in place.
• It will be less expensive to invest in a rigorous change management process than to resolve incidents, service disruptions, and outages caused by the deployment of a bad change.
• Change management is what gives you control and visibility regarding what is introduced to the live environment, preventing incidents that threaten business continuity.

80%

In organizations without formal change management processes, about 80% (The Visible Ops Handbook) of IT service outage problems are caused by updates and changes to systems, applications, and infrastructure. It’s crucial to track and systematically manage change to fully understand and predict the risks and potential impact of the change.

Attributes of a change

Differentiate changes from other IT requests

Is this in the production environment of a business process?

The core business of the enterprise or supporting functions may be affected.

Does the task affect an enterprise managed system?

If it’s for a local application, it’s a service request

How many users are impacted?

It should usually impact more than a single user (in most cases).

Is there a configuration, or code, or workflow, or UI/UX change?

Any impact on a business process is a change; adding a user or a recipient to a report or mailing list is not a change.

Does the underlying service currently exist?

If it’s a new service, then it’s better described as a project.

Is this done/requested by IT?

It needs to be within the scope of IT for the change management process to apply.

Will this take longer than one week?

As a general rule, if it takes longer than 40 hours of work to complete, it’s likely a project.

Defining what constitutes a change

Every change request will initiate the change management process; don’t waste time reviewing requests that are out of scope.

Do not treat every IT request as a change!

• Many organizations make the mistake of calling a standard service request or operational task a “change.”
• Every change request will initiate the change management process; don’t waste time reviewing requests that are out of scope.
• While the overuse of RFCs for out-of-scope requests is better than a lack of process, this will slow the process and delay the approval of more critical changes.
• Requiring an RFC for something that should be considered day-to-day work will also discourage people from adhering to the process, because the RFC will be seen as meaningless paperwork.

1.2.1 Define What Constitutes a Change

Input

• List of examples of each category of the chart

Output

• Definitions for each category to be used at change intake

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Service catalog (if applicable)
• Sticky notes
• Markers/pens
• Change Management SOP

Participants

• Infrastructure Manager
• Change Manager
• Members of the Change Advisory Board

1. As a group, brainstorm examples of changes, projects, service requests (user), operational tasks (backend), and releases. You may add additional categories as needed (e.g. incidents).
2. Have each participant write the examples on sticky notes and populate the following chart on the whiteboard/flip chart.
3. Use the examples to draw lines and define what defines each category.
   • What makes a change distinct from a project?
   • What makes a change distinct from a service request?
   • What makes a change distinct from an operational task?
   • When do the category workflows cross over with other categories? (For example, when does a project interact with change management?)
4. Record the definitions of requests and results in section 2.3 of the Change Management Standard Operating Procedure (SOP).

Download the Change Management Standard Operating Procedure (SOP).

Each RFC should define resources needed to effect the change

In addition to assigning a category to each RFC based on risk assessment, each RFC should also be assigned a priority based on the impact of the change on the IT organization, in terms of the resources needed to effect the change.

Categories include

Normal

Emergency

Pre-Approved

The majority of changes will be pre-approved or normal changes. Definitions of each category are provided on the next slide.

Info-Tech uses the term pre-approved rather than the ITIL terminology of standard to more accurately define the type of change represented by this category.

A potential fourth change category of expedited may be employed if you are having issues with process adherence or if you experience changes driven from outside change management’s control (e.g. from the CIO, director, judiciary, etc.) See Appendix I for more details.

Info-Tech Best Practice

Do not rush to designate changes as pre-approved. You may have a good idea of which changes may be considered pre-approved, but make sure they are in fact low-risk and well-documented before moving them over from the normal category.

The category of the change determines the process it follows

Pay close attention to defining your pre-approved changes. They are going to be critical for running a smooth change management practice in a DevOps Environment

1.2.2 Build a Change Categorization Scheme

Input

• List of examples of each change category

Output

• Definitions for each change category

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Service catalog (if applicable)
• Sticky notes
• Markers
• Change Management SOP

Participants

• Infrastructure Manager
• Change Manager
• Members of the Change Advisory Board

1. Discuss the change categories on the previous slide and modify the types of descriptions to suit your organization.
2. Once the change categories or types are defined, identify several examples of change requests that would fall under each category.
3. Types of normal changes will be further defined in the next activity and can be left blank for now.
4. Examples are provided below. Capture your definitions in section 4 of your Change Management SOP.

Assess the risk for each normal change based on impact (severity) and likelihood (probability)

Create a change assessment risk matrix to standardize risk assessment for new changes. Formalizing this assessment should be one of the first priorities of change management.

The following slides guide you through the steps of formalizing a risk assessment according to impact and likelihood:

1. Define a risk matrix: Risk matrices can either be a 3x3 matrix (Minor, Medium, or High Risk as shown on the next slide) or a 4x4 matrix (Minor, Medium, High, or Critical Risk).
2. Build an impact assessment: Enable consistent measurement of impact for each change by incorporating a standardized questionnaire for each RFC.
3. Build a likelihood assessment: Enable the consistent measurement of impact for each change by incorporating a standardized questionnaire for each RFC.
4. Test drive your risk assessment and make necessary adjustments: Measure your newly formed risk assessment questionnaires against historical changes to test its accuracy.

Consider risk

1. Risk should be the primary consideration in classifying a normal change as Low, Medium, High. The extent of governance required, as well as minimum timeline to implement the change, will follow from the risk assessment.
2. The business benefit often matches the impact level of the risk – a change that will provide a significant benefit to a large number of users may likely carry an equally major downside if deviations occur.

Info-Tech Insight

All changes entail an additional level of risk. Risk is a function of impact and likelihood. Risk may be reduced, accepted, or neutralized through following best practices around training, testing, backout planning, redundancy, timing and sequencing of changes, etc.

Create a risk matrix to assign a risk rating to each RFC

Every normal RFC should be assigned a risk rating.

How is risk rating determined?

• Priority should be based on the business consequences of implementing or denying the change.
• Risk rating is assigned using the impact of the risk and likelihood/probability that the event may occur.

Who determines priority?

• Priority should be decided with the change requester and with the CAB, if necessary.
• Don’t let the change requester decide priority alone, as they will usually assign it a higher priority than is justified. Use a repeatable, standardized framework to assess each request.

How is risk rating used?

• Risk rating is used to determine which changes should be discussed and assessed first.
• Time frames and escalation processes should be defined for each risk level.

RFCs need to clearly identify the risk level of the proposed change. This can be done through statement of impact and likelihood (low/medium/high) or through pertinent questions linked with business rules to assess the risk.

Risk always has a negative impact, but the size of the impact can vary considerably in terms of cost, number of people or sites affected, and severity of the impact. Impact questions tend to be more objective and quantifiable than likelihood questions.

Risk Matrix

1.2.3 Build a Classification Scheme to Assess Impact

Input

• Current risk assessment (if available)

Output

• Tailored impact assessment

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Change Management SOP

Participants

• CIO
• Infrastructure Manager
• Change Manager
• Members of the Change Advisory Board

1. Define a set of questions to measure risk impact.
2. For each question, assign a weight that should be placed on that factor.
3. Define criteria for each question that would categorize the risk as high, medium, or low.
4. Capture your results in section 4.3.1 of your Change Management SOP.

1.2.4 Build a Classification Scheme to Define Likelihood

Input

• Current risk assessment (if available)

Output

• Tailored likelihood assessment

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Change Management SOP

Participants

• CIO
• Infrastructure Manager
• Change Manager
• Members of the Change Advisory Board

1. Define a set of questions to measure risk likelihood.
2. For each question, assign a weight that should be placed on that factor.
3. Define criteria for each question that would categorize the risk as high, medium, or low.
4. Capture your results in section 4.3.2 of your Change Management SOP.

1.2.5 Evaluate and Adjust Your Risk Assessment Scheme

Input

• Impact and likelihood assessments from previous two activities

Output

• Vetted risk assessment

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Change Management Risk Assessment Tool

Participants

• CIO
• Infrastructure Manager
• Change Manager
• Members of the Change Advisory Board

1. Draw your risk matrix on a whiteboard or flip chart.
2. As a group, identify up to 10 examples of requests for changes that would apply within your organization. Depending on the number of people participating, each person could identify one or two changes and write them on sticky notes.
3. Take turns bringing your sticky notes up to the risk matrix and placing each where it belongs, according to the assessment criteria you defined.
4. After each participant has taken a turn, discuss each change as a group and adjust the placement of any changes, if needed. Update the risk assessment weightings or questions, if needed.

Download the Change Management Rick Assessment Tool.

Case Study

A CMDB is not a prerequisite of change management. Don’t let the absence of a configuration management database (CMDB) prevent you from implementing change management.

Industry: Manufacturing

Source: Anonymous Info-Tech member

Challenge

The company was planning to implement a CMDB; however, full implementation was still one year away and subject to budget constraints.

Without a CMDB, it would be difficult to understand the interdependencies between systems and therefore be able to provide notifications to potentially affected user groups prior to implementing technical changes.

This could have derailed the change management project.

Solution

An Excel template was set up as a stopgap measure until the full implementation of the CMDB. The template included all identified dependencies between systems, along with a “dependency tier” for each IT service.

Tier 1: The dependent system would not operate if the upstream system change resulted in an outage.

Tier 2: The dependent system would suffer severe degradation of performance and/or features.

Tier 3: The dependent system would see minor performance degradation or minor feature unavailability.

Results

As a stopgap measure, the solution worked well. When changes ran the risk of degrading downstream dependent systems, the impacted business system owner’s authorization was sought and end users were informed in advance.

The primary takeaway was that a system to manage configuration linkages and system dependencies was key.

While a CMDB is ideal for this use case, IT organizations shouldn’t let the lack of such a system stop progress on change management.

Case Study (part 1 of 4)

Intel used a maturity assessment to kick-start its new change management program.

Industry: Technology

Source: Daniel Grove, Intel

Challenge

Founded in 1968, the world’s largest microchip and semiconductor company employs over 100,000 people. Intel manufactures processors for major players in the PC market including Apple, Lenovo, HP, and Dell.

Intel IT supports over 65,000 servers, 3.2 petabytes of data, over 70,000 PCs, and 2.6 million emails per day.

Intel’s change management program is responsible for over 4,000 changes each week.

Solution

Due to the sheer volume of change management activities present at Intel, over 35% of unscheduled outages were the result of changes.

Ineffective change management was identified as the top contributor of incidents with unscheduled downtime.

One of the major issues highlighted was a lack of process ownership. The change management process at Intel was very fragmented, and that needed to change.

Results

Daniel Grove, Senior Release & Change Manager at Intel, identified that clarifying tasks for the Change Manager and the CAB would improve process efficiency by reducing decision lag time. Roles and responsibilities were reworked and clarified.

Intel conducted a maturity assessment of the overall change management process to identify key areas for improvement.

Phase 2

Establish Roles and Workflows

For running change management in DevOps environment, see Appendix II.

Define Change Management

1.1 Assess Maturity

1.2 Categorize Changes and Build Your Risk Assessment

Establish Roles and Workflows

2.1 Determine Roles and Responsibilities

2.2 Build Core Workflows

Define RFC and Post-Implementation Activities

3.1 Design the RFC

3.2 Establish Post-Implementation Activities

Measure, Manage, and Maintain

4.1 Identify Metrics and Build the Change Calendar

4.2 Implement the Project

This phase will guide you through the following steps:

• Determine Roles and Responsibilities
• Build Core Workflows

This phase involves the following participants:

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

Step 2.1

Determine Roles and Responsibilities

Activities

2.1.1 Capture Roles and Responsibilities Using a RACI Chart

2.1.2 Determine Your Change Manager’s Responsibilities

2.1.3 Define the Authority and Responsibilities of Your CAB

2.1.4 Determine an E-CAB Protocol for Your Organization

Establish Roles and Workflows

Step 2.1: Determine Roles and Responsibilities → Step 2.2: Build Core Workflows

This step involves the following participants:

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

Outcomes of this step

• Clearly defined responsibilities to form the job description for a Change Manager
• Clearly defined roles and responsibilities for the change management team, including the business system owner, technical SME, and CAB members
• Defined responsibilities and authority of the CAB
• Protocol for an emergency CAB (E-CAB) meeting

Identify roles and responsibilities for your change management team

Business System Owner

• Provides downtime window(s)
• Advises on need for change (prior to creation of RFC)
• Validates change (through UAT or other validation as necessary)
• Provides approval for expedited changes (needs to be at executive level)

Technical Subject Matter Expert (SME)

• Advises on proposed changes prior to RFC submission
• Reviews draft RFC for technical soundness
• Assesses backout/rollback plan
• Checks if knowledgebase has been consulted for prior lessons learned
• Participates in the PIR, if necessary
• Ensures that the service desk is trained on the change

CAB

• Approves/rejects RFCs for normal changes
• Reviews lessons learned from PIRs
• Decides on the scope of change management
• Reviews metrics and decides on remedial actions
• Considers changes to be added to list of pre-approved changes
• Communicates to organization about upcoming changes

Change Manager

• Reviews RFCs for completeness
• Ensures RFCs brought to the CAB have a high chance of approval
• Chairs CAB meetings, including scheduling, agenda preparation, reporting, and follow-ups
• Manages post-implementation reviews and reporting
• Organizes internal communications (within IT)

2.1.1 Capture Roles and Responsibilities Using a RACI Chart

Input

• Current SOP

Output

• Documented roles and responsibilities in change management in a RACI chart

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Sticky notes
• Markers/pens
• Project Summary Template
• Change Management SOP

Participants

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

1. As a group, work through developing a RACI chart to determine the roles and responsibilities of individuals involved in the change management practice based on the following criteria:
   • Responsible (performs the work)
   • Accountable (ensures the work is done)
   • Consulted (two-way communication)
   • Informed (one-way communication)
2. Record your results in slide 14 of the Project Summary Template and section 3.1 of your Change Management SOP.

Designate a Change Manager to own the process, change templates, and tools

The Change Manager will be the point of contact for all process questions related to change management.

• The Change Manager needs the authority to reject change requests, regardless of the seniority of the requester.
• The Change Manager needs the authority to enforce compliance to a standard process.
• The Change Manager needs enough cross-functional subject-matter expertise to accurately evaluate the impact of change from both an IT and business perspective.

Info-Tech Best Practice

Some organizations will not be able to assign a dedicated Change Manager, but they must still task an individual with change review authority and with ownership of the risk assessment and other key parts of the process.

Responsibilities

1. The Change Manager is your first stop for change approval. Both the change management and release and deployment management processes rely on the Change Manager to function.
2. Every single change that is applied to the live environment, from a single patch to a major change, must originate with a request for change (RFC), which is then approved by the Change Manager to proceed to the CAB for full approval.
3. Change templates and tools, such as the change calendar, list of preapproved changes, and risk assessment template are controlled by the Change Manager.
4. The Change Manager also needs to have ownership over gathering metrics and reports surrounding deployed changes. A skilled Change Manager needs to have an aptitude for applying metrics for continual improvement activities.

2.1.2 Document Your Change Manager’s Responsibilities

Input

• Current Change Manager job description (if available)

Output

• Change Manager job description and list of responsibilities

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Info-Tech’s Change Manager Job Description
• Change Management SOP

Participants

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

1.Using the previous slide, Info-Tech’s Change Manager Job Description, and the examples below, brainstorm responsibilities for the Change Manager.

2.Record the responsibilities in Section 3.2 of your Change Management SOP.

Example:

Change Manager: James Corey

Responsibilities

1. Own the process, tools, and templates.
2. Control the Change Management SOP.
3. Provide standard RFC forms.
4. Distribute RFCs for CAB review.
5. Receive all initial RFCs and check them for completion.
6. Approve initial RFCs.
7. Approve pre-approved changes.
8. Approve the conversion of normal changes to pre-approved changes.
9. Assemble the Emergency CAB (E-CAB) when emergency change requests are received.
10. Approve submission of RFCs for CAB review.
11. Chair the CAB:
    • Set the CAB agenda and distribute it at least 24 hours before the meeting.
    • Ensure the agenda is adhered to.
    • Make the final approval/prioritization decision regarding a change if the CAB is deadlocked and cannot come to an agreement.
    • Distribute CAB meeting minutes to all members and relevant stakeholders.

Download the Change Manager Job Description

Create a Change Advisory Board (CAB) to provide process governance

The primary functions of the CAB are to:

1. Protect the live environment from poorly assessed, tested, and implemented changes.
   • CAB approval is required for all normal and emergency changes.
   • If a change results in an incident or outage, the CAB is effectively responsible; it’s the responsibility of the CAB to assess and accept the potential impact of every change.
2. Prioritize changes in a way that fairly reflects change impact and urgency.
   • Change requests will originate from multiple stakeholders, some of whom have competing interests.
   • It’s up to the CAB to prioritize these requests effectively so that business need is balanced with any potential risk to the infrastructure.
   • The CAB should seek to reduce the number of emergency/expedited changes.
3. Schedule deployments in a way that minimizes conflict and disruption.
   • The CAB uses a change calendar populated with project work, upcoming organizational initiatives, and change freeze periods. They will schedule changes around these blocks to avoid disrupting user productivity.
   • The CAB should work closely with the release and deployment management teams to coordinate change/release scheduling.

See what responsibilities in the CAB’s process are already performed by the DevOps lifecycle (e.g. authorization, deconfliction etc.). Do not duplicate efforts.

Use diverse representation from the business to form an effective CAB

The CAB needs insight into all areas of the business to avoid approving a high-risk change.

Based on the core responsibilities you have defined, the CAB needs to be composed of a diverse set of individuals who provide quality:

• Change need assessments – identifying the value and purpose of a proposed change.
• Change risk assessments – confirmation of the technical impact and likelihood assessments that lead to a risk score, based on the inputs in RFC.
• Change scheduling – offer a variety of perspectives and responsibilities and will be able to identify potential scheduling conflicts.

Info-Tech Best Practice

Form a core CAB (members attend every week) and an optional CAB (members who attend only when a change impacts them or when they can provide value in discussions about a change). This way, members can have their voice heard without spending every week in a meeting where they do not contribute.

2.1.3 Define the Authority and Responsibilities of Your CAB

Input

• Current SOP or CAB charter (if available)

Output

• Documented list of CAB authorities and responsibilities

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Change Management SOP
• Project Summary Template

Participants

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

1.Using the previous slide and the examples below, list the authorities and responsibilities of your CAB.

2.Record the responsibilities in section 3.3.2 of your Change Management SOP and the Project Summary Template.

Example:

Establish an emergency CAB (E-CAB) protocol

• When an emergency change request is received, you will not be able to wait until the regularly scheduled CAB meeting.
• As a group, decide who will sit on the E-CAB and what their protocol will be when assessing and approving emergency changes.

Change owner conferences with E-CAB (best efforts to reach them) through email or messaging.

E-CAB members and business system owners are provided with change details. No decision is made without feedback from at least one E-CAB member.

If business continuity is being affected, the Change Manager has authority to approve change.

Full documentation of the change (a retroactive RFC) is done after the change and is then reviewed by the CAB.

Info-Tech Best Practice

Members of the E-CAB should be a subset of the CAB who are typically quick to respond to their messages, even at odd hours of the night.

2.1.4 Determine an E-CAB Protocol for Your Organization

Input

• Current SOP or CAB charter (if available)

Output

• E-CAB protocol

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Change Management SOP

Participants

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

1. Gather the members of the E-CAB and other necessary representatives from the change management team.
2. Determine the order of operations for the E-CAB in the event that an emergency change is needed.
3. Consult the example emergency protocol below. Determine what roles and responsibilities are involved at each stage of the emergency change’s implementation.
4. Document the E-CAB protocol in section 3.4 of your Change Management SOP.

Example

Assemble E-CAB

Assess Change

Test (if Applicable)

Deploy Change

Create Retroactive RFC

Review With CAB

Step 2.2

Build Core Workflows

Activities

2.2.1 Build a CMDB-lite as a Reference for Requested Changes

2.2.2 Create a Normal Change Process

2.2.3 Create a Pre-Approved Change Process

2.2.4 Create an Emergency Change Process

Establish Roles and Workflows

Step 2.1: Determine Roles and Responsibilities → Step 2.2: Build Core Workflows

This step involves the following participants:

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

Outcomes of this step

• Emergency change workflow
• Normal process workflow
• Pre-approved change workflow

Establishing Workflows: Change Management Lifecycle

Improve

• A post-implementation review assesses the value of the actual change measured against the proposed change in terms of benefits, costs, and impact.
• Results recorded in the change log.
• Accountability: Change Manager Change Implementer

Request

• A change request (RFC) can be submitted via paper form, phone, email, or web portal.
• Accountability: Change requester/Initiator

Assess

• The request is screened to ensure it meets an agreed-upon set of business criteria.
• Changes are assessed on:
  • Impact of change
  • Risks or interdependencies
  • Resourcing and costs
• Accountability: Change Manager

Plan

• Tasks are assigned, planned, and executed.
• Change schedule is consulted and necessary resources are identified.
• Accountability: Change Manager

Approve

• Approved requests are sent to the most efficient channel based on risk, urgency, and complexity.
• Change is sent to CAB members for final review and approval
• Accountability: Change Manager
  • Change Advisory Board

Implement

• Approved changes are deployed.
• A rollback plan is created to mitigate risk.
• Accountability: Change Manager Change Implementer

Establishing workflows: employ a SIPOC model for process definition

A good SIPOC (supplier, input, process, output, customer) model helps establish the boundaries of each process step and provides a concise definition of the expected outcomes and required inputs. It’s a useful and recommended next step for every workflow diagram.

For change management, employ a SIPOC model to outline your CAB process:

Supplier

• Who or what organization provides the inputs to the process? The supplier can be internal or external.

Input

• What goes into the process step? This can be a document, data, information, or a decision.

Process

• Activities that occur in the process step that’s being analyzed.

Output

• What does the process step produce? This can be a document, data, information, or a decision.

Customer

• Who or what organization(s) takes the output of the process? The customer can be internal or external.

Optional Fields

Metrics

• Top-level indicators that usually relate to the input and output, e.g. turnaround time, risk matrix completeness.

Controls

• Checkpoints to ensure process step quality.

Dependencies

• Other process steps that require the output.

RACI

• Those who are Responsible, Accountable, Consulted, or Informed (RACI) about the input, output, and/or process.

Establish change workflows: assess requested changes to identify impact and dependencies

An effective change assessment workflow is a holistic process that leaves no stone unturned in an effort to mitigate risk before any change reaches the approval stage. The four crucial areas of risk in a change workflow are:

Dependencies

Identify all components of the change.

Ask how changes will affect:

• Services on the same infrastructure?
• Applications?
• Infrastructure/app architecture?
• Security?
• Ability to support critical systems?

Business Impact

Frame the change from a business point of view to identify potential disruptions to business activities.

Your assessment should cover:

• Business processes
• User productivity
• Customer service
• BCPs

SLA Impact

Each new change can impact the level of service available.

Examine the impact on:

• Availability of critical systems
• Infrastructure and app performance
• Infrastructure and app capacity
• Existing disaster recovery plans and procedures

Required Resources

Once risk has been assessed, resources need to be identified to ensure the change can be executed.

These include:

• People (SMEs, tech support, work effort/duration)
• System time for scheduled implementation
• Hardware or software (new or existing, as well as tools)

Establishing workflows: pinpoint dependencies to identify the need for additional changes

An assessment of each change and a query of the CMDB needs to be performed as part of the change planning process to mitigate outage risk.

• A version upgrade on one piece of software may require another component to be upgraded as well. For example, an upgrade to the database management system requires that an application that uses the database be upgraded or modified.
• The sequence of the release must also be determined, as certain components may need to be upgraded before others. For example, if you upgrade the Exchange Server, a Windows update must be installed prior to the Exchange upgrade.
• If you do not have a CMDB, consider building a CMDB-lite, which consists of a listing of systems, primary users, SMEs, business owners, and system dependencies (see next slide).

Services Impacted

• Have affected services been identified?
• Have supporting services been identified?
• Has someone checked the CMDB to ensure all dependencies have been accounted for?
• Have we referenced the service catalog so the business approves what they’re authorizing?

Technical Teams Impacted

• Who will support the change throughout testing and implementation?
• Will additional support be needed?
• Do we need outside support from eternal suppliers?
• Has someone checked the contract to ensure any additional costs have been approved?

Build a dependency matrix to avoid change related collisions (optional)

A CMDB-lite does not replace a CMDB but can be a valuable tool to leverage when requesting changes if you do not currently have configuration management. Consider the following inputs when building your own CMDB-lite.

• System
  • To build a CMDB-lite, start with the top 10 systems in your environment that experience changes. This list can always be populated iteratively.
• Primary Users
  • Listing the primary users will give a change requester a first glance at the impact of the change.
  • You can also use this information when looking at the change communication and training after the change is implemented.
• SME/Backup
  • These are the staff that will likely build and implement the change. The backup is listed in case the primary is on holiday.
• Business System Owner
  • The owner of the system is one of the people needed to sign off on the change. Having their support from the beginning of a change is necessary to build and implement it successfully.
• Tier 1 Dependency
  • If the primary system experiences and outage, Tier 1 dependency functionality is also lost. To request a change, include the business system owner signoffs of the Tier 1 dependencies of the primary system.
• Tier 2 Dependency
  • If the primary system experiences an outage, Tier 2 dependency functionality is lost, but there is an available workaround. As with Tier 1, this information can help you build a backout plan in case there is a change-related collision.
• Tier 3 Dependency
  • Tier 3 functionality is not lost if the primary system experiences an outage, but nice-to-haves such as aesthetics are affected.

2.2.1 Build a CMDB-lite as a Reference for Requested Changes

Input

• Current system ownership documentation

Output

• Documented reference for change requests (CMDB-lite)

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Sticky notes
• Markers/pens

Participants

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

1. Start with a list of your top 10-15 systems/services with the highest volume of changes.
2. Using a whiteboard, flip chart, or shared screen, complete the table below by filling the corresponding Primary Users, SMEs, Business System Owner, and Dependencies as shown below. It may help to use sticky notes.
3. Iteratively populate the table as you notice gaps with incoming changes.

Establishing workflows: create standards for change approvals to improve efficiency

• Not all changes are created equal, and not all changes require the same degree of approval. As part of the change management process, it’s important to define who is the authority for each type of change.
• Failure to do so can create bureaucratic bottlenecks if each change is held to an unnecessary high level of scrutiny, or unplanned outages may occur due to changes circumventing the formal approval process.
• A balance must be met and defined to ensure the process is not bypassed or bottlenecked.

Info-Tech Best Practice

Define a list pre-approved changes and automate them (if possible) using your ITSM solution. This will save valuable time for more important changes in the queue.

Example:

Example process: Normal Change – Change Initiation

Change initiation allows for assurance that the request is in scope for change management and acts as a filter for out-of-scope changes to be redirected to the proper workflow. Initiation also assesses who may be assigned to the change and the proper category of the change, and results in an RFC to be populated before the change reaches the build and test phase.

The change trigger assessment is critical in the DevOps lifecycle. This can take a more formal role of a technical review board (TRB) or, with enough maturity, may be automated. Responsibilities such as deconfliction, dependency identification, calendar query, and authorization identification can be done early in the lifecycle to decrease or eliminate the burden on CAB.

For the full process, refer to the Change Management Process Library.

Example process: Normal Change – Technical Build and Test

The technical build and test stage includes all technical prerequisites and testing needed for a change to pass before proceeding to approval and implementation. In addition to a technical review, a solution consisting of the implementation, rollback, communications, and training plan are also built and included in the RFC before passing it to the CAB.

For the full process, refer to the Change Management Process Library.

Example process: Normal Change – Change Approval (CAB)

Change approval can start with the Change Manager reviewing all incoming RFCs to filter them for completeness and check them for red flags before passing them to the CAB. This saves the CAB from discussing incomplete changes and allows the Change Manager to set a CAB agenda before the CAB meeting. If need be, change approval can also set vendor communications necessary for changes, as well as the final implementation date of the change. The CAB and Change Manager may follow up with the appropriate parties notifying them of the approval decision (accepted, rescheduled, or rejected).

For the full process, refer to the Change Management Process Library.

Example process: Normal Change – Change Implementation

Changes should not end at implementation. Ensure you define post-implementation activities (documentation, communication, training etc.) and a post-implementation review in case the change does not go according to plan.

For the full process, refer to the Change Management Process Library.

2.2.2 Create a Normal Change Process

Input

• Current SOP/workflow library

Output

• Normal change process

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Pens/markers
• Sticky notes
• Change Management Process Library
• Change Management SOP

Participants

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

1. Gather representatives from the change management team.
2. Using the examples shown on the previous few slides, work as a group to determine the workflow for a normal change, with particular attention to the following sub-processes:
   1. Request
   2. Assessment
   3. Plan
   4. Approve
   5. Implementation and Post-Implementation Activities
3. Optionally, you may create variations of the workflow for minor, medium, and major changes (e.g. there will be fewer authorizations for minor changes).
4. For further documentation, you may choose to run the SIPOC activity for your CAB as outlined on this slide.
5. Document the resulting workflows in the Change Management Process Library and section 11 of your Change Management SOP.

Download the Change Management Process Library.

Identify and convert low-risk normal changes to pre-approved once the process is established

As your process matures, begin creating a list of normal changes that might qualify for pre-approval. The most potential for value in gains from change management comes from re-engineering and automating of high-volume changes. Pre-approved changes should save you time without threatening the live environment.

IT should flag changes they would like pre-approved:

• Once your change management process is firmly established, hold a meeting with all staff that make change requests and build changes.
• Run a training session detailing the traits of pre-approved changes and ask these individuals to identify changes that might qualify.
• These changes should be submitted to the Change Manager and reviewed, with the help of the CAB, to decide whether or not they qualify for pre-approval.

Pre-approved changes are not exempt from due diligence:

• Once a change is designated as pre-approved, the deployment team should create and compile all relevant documentation:
  • An RFC detailing the change, dependencies, risk, and impact.
  • Detailed procedures and required resources.
  • Implementation and backout plan.
  • Test results.
• When templating the RFC for pre-approved changes, aim to write the documentation as if another SME were to implement it. This reduces confusion, especially if there’s staff turnover.
• The CAB must approve, sign off, and keep a record of all documents.
• Pre-approved changes must still be documented and recorded in the CMDB and change log after each deployment.

Info-Tech Best Practice

At the beginning of a change management process, there should be few active pre-approved changes. However, prior to launch, you may have IT flag changes for conversion.

Example process: Pre-Approved Change Process

For the full process, refer to the Change Management Process Library.

Review the pre-approved change list regularly to ensure the list of changes are still low-risk and repeatable.

IT environments change. Don’t be caught by surprise.

• Changes which were once low-risk and repeatable may cause unforeseen incidents if they are not reviewed regularly.
• Dependencies change as the IT environment changes. Ensure that the changes on the pre-approved change list are still low-risk and repeatable, and that the documentation is up to date.
• If dependencies have changed, then move the change back to the normal category for reassessment. It may be redesignated as a pre-approved change once the documentation is updated.

Info-Tech Best Practice

Other reasons for moving a pre-approved change back to the normal category is if the change led to an incident during implementation or if there was an issue during implementation.

Seek new pre-approved change submissions. → Re-evaluate the pre-approved change list every 4-6 months.

For the full process, refer to the Change Management Process Library.

2.2.3 Create a Pre-Approved Change Process

Input

• Current SOP/workflow library

Output

• Pre-approved change process

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Pens/markers
• Sticky notes
• Change Management Process Library
• Change Management SOP

Participants

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

1. Gather representatives from the change management team.
2. Using the examples shown on the previous few slides, work as a group to determine the workflow for a pre-approved change, with particular attention to the following sub-processes:
   1. Request
   2. Assessment
   3. Plan
   4. Approve
3. Document the process of a converting a normal change to pre-approved. Include the steps from flagging a low-risk change to creating the related RFC template.
4. Document the resulting workflows in the Change Management Process Library and sections 4.2 and 13 of your Change Management SOP.

Reserve the emergency designation for real emergencies

• Emergency changes have one of the following triggers:
  • A critical incident is impacting user productivity.
  • An imminent critical incident will impact user productivity.
• Unless a critical incident is being resolved or prevented, the change should be categorized as normal.
• An emergency change differs from a normal change in the following key aspects:
  • An emergency change is required to recover from a major outage – there must be a validated service desk critical incident ticket.
  • An urgent business requirement is not an “emergency.”
  • An RFC is created after the change is implemented and the outage is over.
  • A review by the full CAB occurs after the change is implemented.
  • The first responder and/or the person implementing the change may not be the subject matter expert for that system.
• In all cases, an RFC must be created and the change must be reviewed by the full CAB. The review should occur within two business days of the event.

Info-Tech Best Practice

Change requesters should be made aware that senior management will be informed if an emergency RFC is submitted inappropriately. Emergency requests trigger urgent CAB meetings, are riskier to deploy, and delay other changes waiting in the queue.

Example process: Emergency Change Process

When building your emergency change process, have your E-CAB protocol from activity 2.1.4 handy.

• Focus on the following requirements for an emergency process:
  • E-CAB protocol and scope: Does the SME need authorization first before working on the change or can the SME proceed if no E-CAB members respond?
  • Documentation and communication to stakeholders and CAB after the emergency change is completed.
  • Input from incident management.

For the full process, refer to the Change Management Process Library.

2.2.4 Create an Emergency Change Process

Input

• Current SOP/workflow library

Output

• Emergency change process

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Pens/markers
• Sticky notes
• Change Management Process Library
• Change Management SOP

Participants

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

1. Gather representatives from the change management team.
2. Using the examples shown on the previous few slides, work as a group to determine the workflow for an emergency change, with particular attention to the following sub-processes:
   1. Request
   2. Assessment
   3. Plan
   4. Approve
3. Ensure that the E-CAB protocol from activity 2.1.4 is considered when building your process.
4. Document the resulting workflows in the Change Management Process Library and section 12 of your Change Management SOP.

Case Study (part 2 of 4)

Intel implemented a robust change management process.

Industry: Technology

Source: Daniel Grove, Intel

Challenge

Founded in 1968, the world’s largest microchip and semiconductor company employs over 100,000 people. Intel manufactures processors for major players in the PC market including Apple, Lenovo, HP, and Dell.

Intel IT supports over 65,000 servers, 3.2 petabytes of data, over 70,000 PCs, and 2.6 million emails per day.

Intel’s change management program is responsible for over 4,000 changes each week.

Solution

Intel identified 37 different change processes and 25 change management systems of record with little integration.

Software and infrastructure groups were also very siloed, and this no doubt contributed to the high number of changes that caused outages.

The task was simple: standards needed to be put in place and communication had to improve.

Results

Once process ownership was assigned and the role of the Change Manager and CAB clarified, it was a simple task to streamline and simplify processes among groups.

Intel designed a new, unified change management workflow that all groups would adopt.

Automation was also brought into play to improve how RFCs were generated and submitted.

Phase 3

Define the RFC and Post-Implementation Activities

Define Change Management

1.1 Assess Maturity

1.2 Categorize Changes and Build Your Risk Assessment

Establish Roles and Workflows

2.1 Determine Roles and Responsibilities

2.2 Build Core Workflows

Define the RFC and Post-Implementation Activities

3.1 Design the RFC

3.2 Establish Post-Implementation Activities

Measure, Manage, and Maintain

4.1 Identify Metrics and Build the Change Calendar

4.2 Implement the Project

This phase will guide you through the following activities:

• Design the RFC
• Establish Post-Implementation Activities

This phase involves the following participants:

• IT Director
• Infrastructure Manager
• Change Manager
• Members of the Change Advisory Board

Step 3.1

Design the RFC

Activities

3.1.1 Evaluate Your Existing RFC Process

3.1.2 Build the RFC Form

Define the RFC and Post-Implementation Activities

Step 3.1: Design the RFC

Step 3.2: Establish Post-Implementation Activities

This step involves the following participants:

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

Outcomes of this step

• A full RFC template and process that compliments the workflows for the three change categories

A request for change (RFC) should be submitted for every non-standard change

An RFC should be submitted through the formal change management practice for every change that is not a standard, pre-approved change (a change which does not require submission to the change management practice).

• The RFC should contain all the information required to approve a change. Some information will be recorded when the change request is first initiated, but not everything will be known at that time.
• Further information can be added as the change progresses through its lifecycle.
• The level of detail that goes into the RFC will vary depending on the type of change, the size, and the likely impact of the change.
• Other details of the change may be recorded in other documents and referenced in the RFC.

Info-Tech Insight

Keep the RFC form simple, especially when first implementing change management, to encourage the adoption of and compliance with the process.

RFCs should contain the following information, at a minimum:

1. Contact information for requester
2. Description of change
3. References to external documentation
4. Items to be changed, reason for the change, and impact of both implementing and not implementing the change
5. Change type and category
6. Priority and risk assessment
7. Predicted time frame, resources, and cost
8. Backout or remediation plan
9. Proposed approvers
10. Scheduled implementation time
11. Communications plan and post-implementation review

3.1.1 Evaluate Your Existing RFC Process

Input

• Current RFC form or stock ITSM RFC
• Current SOP (if available)

Output

• List of changes to the current RFC form and RFC process

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Projector
• Markers/pens
• Laptop with ITSM admin access
• Request for Change Form Template
• Change Management SOP

Participants

• IT Director
• Infrastructure Manager
• Change Manager
• Members of the Change Advisory Board

1. If the organization is already using an RFC form, review it as a group now and discuss its contents:
   • Does this RFC provide adequate information for the Change Manager and/or CAB to review?
   • Should any additional fields be added?
2. Show the participants Info-Tech’s Request for Change Form Template and compare it to the one the organization is currently using.
3. As a group, finalize an RFC table of contents that will be used to formalize a new or improved RFC.
4. Decide which fields should be filled out by the requester before the initial RFC is submitted to the Change Manager:
   • Many sections of the RFC are relevant for change assessment and review. What information does the Change Manager need when they first receive a request?
   • The Change Manager needs enough information to ensure that the change is in scope and has been properly categorized.
5. Decide how the RFC form should be submitted and reviewed; this can be documented in section 5 of your Change Management SOP.

Download the Request for Change Form Template.

Design the RFC to encourage process buy-in

• When building the RFC, split the form up into sections that follow the normal workflow (e.g. Intake, Assessment and Build, Approval, Implementation/PIR). This way the form walks the requester through what needs to be filled and when.
• Revisit the form periodically and solicit feedback to continually improve the user experience. If there’s information missing on the RFC that the CAB would like to know, add the fields. If there are sections that are not used or not needed for documentation, remove them.
• Make sure the user experience surrounding your RFC form is a top priority – make it accessible, otherwise change requesters simply will not use it.
• Take advantage of your ITSM’s dropdown lists, automated notifications, CMDB integrations, and auto-generated fields to ease the process of filling the RFC

Draft:

• Change requester
• Requested date of deployment
• Change risk: low/medium/high
• Risk assessment
• Description of change
• Reason for change
• Change components

Technical Build:

• Assess change:
  • Dependencies
  • Business impact
  • SLA impact
  • Required resources
  • Query the CMS
• Plan and test changes:
  • Test plan
  • Test results
  • Implementation plan
  • Backout plan
  • Backout plan test results

CAB:

• Approve and schedule changes:
  • Final CAB review
  • Communications plan

Complete:

• Deploy changes:
  • Post-implementation review

Designing your RFC: RFC draft

• Change requester – link your change module to the active directory to pull the change requester’s contact information automatically to save time.
• A requested date of deployment gives approvers information on timeline and can be used to query the change calendar for possible conflicts
• Information about risk assessment based on impact and likelihood questionnaires are quick to fill out but provide a lot of information to the CAB. The risk assessment may not be complete at the draft stage but can be updated as the change is built. Ensure this field is up-to- date before it reaches CAB.
• If you have a technical review stage where changes are directed to the proper workflow and resourcing is assessed, the description, reason, and change components are high-level descriptors of the change that will aid in discovery and lining the change up with the business vision (viability from both a technical and business standpoint).

• Change requester
• Requested date of deployment
• Change Risk: low/medium/high
• Risk assessment
• Description of change
• Reason for change
• Change components

Use the RFC to point to documentation already gathered in the DevOps lifecycle to cut down on unnecessary manual work while maintaining compliance.

Designing your RFC: technical build

• Dependencies and CMDB query, along with the proposed implementation date, are included to aid in calendar deconfliction and change scheduling. If there’s a conflict, it’s easier to reschedule the proposed change early in the lifecycle.
• Business, SLA impact, and required resources can be tracked to provide the CAB with information on the business resources required. This can also be used to prioritize the change if conflicts arise.
• Implementation, test, and backout plans must be included and assessed to increase the probability that a change will be implemented without failure. It’s also useful in the case of PIRs to determine root causes of change-related incidents.

• Assess change:
  • Dependencies
  • Business impact
  • SLA impact
  • Required resources
  • Query the CMS
• Plan and test changes:
  • Test plan
  • Test results
  • Implementation plan
  • Backout plan
  • Backout plan test results

Designing your RFC: approval and deployment

• Documenting approval, rejection, and rescheduling gives the change requester the go-ahead to proceed with the change, rationale on why it was prioritized lower than another change (rescheduled), or rationale on rejection.
• Communications plans for appropriate stakeholders can also be modified and forwarded to the communications team (e.g. service desk or business system owners) before deployment.
• Post-implementation activities and reviews can be conducted if need be before a change is closed. The PIR, if filled out, should then be appended to any subsequent changes of the same nature to avoid making the same mistake twice.

• Approve and schedule changes:
  • Final CAB review
  • Communications plan
• Deploy changes:
  • Post-implementation review

Standardize the request for change protocol

1. Submission Standards
   • Electronic submission will make it easier for CAB members to review the documentation.
   • As the change goes through the assessment, plan, and test phase, new documentation (assessments, backout plans, test results, etc.) can be attached to the digital RFC for review by CAB members prior to the CAB meeting.
   • Change management software won’t be necessary to facilitate the RFC submission and review; a content repository system, such as SharePoint, will suffice.
2. Designate the first control point
   • All RFCs should be submitted to a single point of contact.
   • Ideally, the Change Manager or Technical Review Board should fill this role.
   • Whoever is tasked with this role needs the subject matter expertise to ensure that the change has been categorized correctly, to reject out-of-scope requests, or to ask that missing information be provided before the RFC moves through the full change management practice.

Info-Tech Best Practice

Technical and SME contacts should be noted in each RFC so they can be easily consulted during the RFC review.

3.1.2 Build the RFC Form

Input

• Current RFC form or stock ITSM RFC
• Current SOP (if available)

Output

• List of changes to the current RFC and RFC process

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Projector
• Markers/pens
• Laptop with ITSM admin access
• Request for Change Form Template

Participants

• IT Director
• Infrastructure Manager
• Change Manager
• Members of the Change Advisory Board

1. Use Info-Tech’s Request for Change Form Template as a basis for your RFC form.
2. Use this template to standardize your change request process and ensure that the appropriate information is documented effectively each time a request is made. The change requester and Change Manager should consolidate all information associated with a given change request in this form. This form will be submitted by the change requester and reviewed by the Change Manager.

Case Study (part 3 of 4)

Intel implemented automated RFC form generation.

Industry: Technology

Source: Daniel Grove, Intel

Challenge

Founded in 1968, the world’s largest microchip and semiconductor company employs over 100,000 people. Intel manufactures processors for major players in the PC market including Apple, Lenovo, HP, and Dell.

Intel IT supports over 65,000 servers, 3.2 petabytes of data, over 70,000 PCs, and 2.6 million emails per day.

Intel’s change management program is responsible for over 4,000 changes each week.

Solution

One of the crucial factors that was impacting Intel’s change management efficiency was a cumbersome RFC process.

A lack of RFC usage was contributing to increased ad hoc changes being put through the CAB, and rescheduled changes were quite high.

Additionally, ad hoc changes were also contributing heavily to unscheduled downtime within the organization.

Results

Intel designed and implemented an automated RFC form generator to encourage end users to increase RFC usage.

As we’ve seen with RFC form design, the UX/UI of the form needs to be top notch, otherwise end users will simply circumvent the process. This will contribute to the problems you are seeking to correct.

Thanks to increased RFC usage, Intel decreased emergency changes by 50% and reduced change-caused unscheduled downtime by 82%.

Step 3.2

Establish Post-Implementation Activities

Activities

3.2.1 Determine When the CAB Would Reject Tested Changes

3.2.2 Create a Post-Implementation Activity Checklist

Define the RFC and Post-Implementation Activities

Step 3.1: Design RFC

Step 3.2: Establish Post-Implementation Activities

This step involves the following participants:

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

Outcomes of this step

• A formalized post-implementation process for continual improvement

Why would the CAB reject a change that has been properly assessed and tested?

Possible reasons the CAB would reject a change include:

• The product being changed is approaching its end of life.
• The change is too costly.
• The timing of the change conflicts with other changes.
• There could be compliance issues.
• The change is actually a project.
• The risk is too high.
• There could be regulatory issues.
• The peripherals (test, backout, communication, and training plans) are incomplete.

Info-Tech Best Practice

Many reasons for rejection (listed above) can be caught early on in the process during the technical review or change build portion of the change. The earlier you catch these reasons for rejection, the less wasted effort there will be per change.

Determine When the CAB Would Reject Tested Changes

Input

• Current SOP (if available)

Output

• List of reasons to reject tested changes

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Projector
• Markers/pens
• Laptop with ITSM admin access
• Project Summary Template

Participants

• IT Director
• Infrastructure Manager
• Change Manager
• Members of the Change Advisory Board

Avoid hand-offs to ensure a smooth implementation process

The implementation phase is the final checkpoint before releasing the new change into your live environment. Once the final checks have been made to the change, it’s paramount that teams work together to transition the change effectively rather than doing an abrupt hand-off. This could cause a potential outage.

1.

• Deployment resources identified, allocated, and scheduled
• Documentation complete
• Support team trained
• Users trained
• Business sign-off
• Target systems identified and ready to receive changes
• Target systems available for installation maintenance window scheduled
• Technical checks:
  • Disk space available
  • Pre-requisites met
  • Components/Services to be updated are stopped
  • All users disconnected
• Download Info-Tech’sChange Management Pre-Implementation Checklist

Implement change →

2.

1. Verification – once the change has been implemented, verify that all requirements are fulfilled.
2. Review – ensure that all affected systems and applications are operating as predicted. Update change log.
3. Transition – a crucial phase of implementation that’s often overlooked. Once the change implementation is complete from a technical point of view, it’s imperative that the team involved with the change inform and train the group responsible for managing the new change.

Create a backout plan to reduce the risk of a failed change

Every change process needs to plan for the potential for failure and how to address it effectively. Change management’s solution to this problem is a backout plan.

A backout plan needs to contain a record of the steps that need to be taken to restore the live environment back to its previous state and maintain business continuity. A good backout plan asks the following questions:

1. How will failure be determined? Who will make the determination to back out of a change be made and when?
2. Do we fix on fail or do we rollback to the previous configuration?
3. Is the service desk aware of the impending change? Do they have proper training?

Notify the Service Desk

• Notify the Service Desk about backout plan initiation.

Disable Access

• Disable user access to affected system(s).

Conduct Checks

• Conduct checks to all affected components.

Enable User Access

• Enable user access to affected systems.

Notify the Service Desk

• Notify the service desk that the backout plan was successful.

Info-Tech Best Practice

As part of the backout plan, consider the turnback point in the change window. That is, the point within the change window where you still have time to fully back out of the change.

Ensure the following post-implementation review activities are completed

Service Catalog

Update the service catalog with new information as a result of the implemented change.

CMDB

Update new dependencies present as a result of the new change.

Asset DB

Add notes about any assets newly affected by changes.

Architecture Map

Update your map based on the new change.

Technical Documentation

Update your technical documentation to reflect the changes present because of the new change.

Training Documentation

Update your training documentation to reflect any information about how users interact with the change.

Use a post-implementation review process to promote continual improvement

The post-implementation review (PIR) is the most neglected change management activity.

• All changes should be reviewed to understand the reason behind them, appropriateness, and recommendations for next steps.
• The Change Manager manages the completion of information PIRs and invites RFC originators to present their findings and document the lessons learned.

Info-Tech Best Practice

Review PIR reports at CAB meetings to highlight the root causes of issues, action items to close identified gaps, and back-up documentation required. Attach the PIR report to the relevant RFC to prevent similar changes from facing the same issues in the future.

1. Why do a post-implementation review?
   • Changes that don’t fail but don’t perform well are rarely reviewed.
   • Changes may fail subtly and still need review.
   • Changes that cause serious failures (i.e. unplanned downtime) receive analysis that is unnecessarily in-depth.
2. What are the benefits?
   • A proactive, post-implementation review actually uses less resources than reactionary change reviews.
   • Root-cause analysis of failed changes, no matter what the impact.
   • Insight into changes that took longer than projected.
   • Identification of previously unidentified risks affecting changes.

Determine the strategy for your PIR to establish a standardized process

Capture the details of your PIR process in a table similar to the one below.

3.2.2 Create a Post-Implementation Activity Checklist

Input

• Current SOP (if available)

Output

• List of reasons to reject tested changes

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Projector
• Markers/pens
• Laptop with ITSM admin access
• Change Management Post-Implementation Checklist

Participants

• CIO
• IT Managers
• Change Manager
• Members of the Change Advisory Board

1. Gather representatives from the change management team.
2. Brainstorm duties to perform following the deployment of a change. Below is a sample list:
   • Example:
     • Was the deployment successful?
       • If no, was the backout plan executed successfully?
     • List change-related incidents
     • Change assessment
       • Missed dependencies
       • Inaccurate business impact
       • Incorrect SLA impact
       • Inaccurate resources
         • Time
         • Staff
         • Hardware
     • System testing
     • Integration testing
     • User acceptance testing
     • No backout plan
     • Backout plan failure
     • Deployment issues
3. Record your results in the Change Management Post-Implementation Checklist.

Download the Change Management Post-Implementation Checklist

Case Study

Microsoft used post-implementation review activities to mitigate the risk of a critical Azure outage.

Industry: Technology

Source: Jason Zander, Microsoft

Challenge

In November 2014, Microsoft deployed a change intended to improve Azure storage performance by reducing CPU footprint of the Azure Table Front-Ends.

The deployment method was an incremental approach called “flighting,” where software and configuration deployments are deployed incrementally to Azure infrastructure in small batches.

Unfortunately, this software deployment caused a service interruption in multiple regions.

Solution

Before the software was deployed, Microsoft engineers followed proper protocol by testing the proposed update. All test results pointed to a successful implementation.

Unfortunately, engineers pushed the change out to the entire infrastructure instead of adhering to the traditional flighting protocol.

Additionally, the configuration switch was incorrectly enabled for the Azure Blob storage Front-Ends.

A combination of the two mistakes exposed a bug that caused the outage.

Results

Thankfully, Microsoft had a backout plan. Within 30 minutes, the change was rolled back on a global scale.

It was determined that policy enforcement was not integrated across the deployment system. An update to the system shifted the process of policy enforcement from human-based decisions and protocol to automation via the deployment platform.

Defined PIR activities enabled Microsoft to take swift action against the outage and mitigate the risk of a serious outage.

Phase 4

Measure, Manage, and Maintain

Define Change Management

1.1 Assess Maturity

1.2 Categorize Changes and Build Risk Assessment

Establish Roles and Workflows

2.1 Determine Roles and Responsibilities

2.2 Build Core Workflows

Define RFC and Post-Implementation Activities

3.1 Design RFC

3.2 Establish post-implementation activities

Measure, Manage, and Maintain

4.1 Identify Metrics and Build the Change Calendar

4.2 Implement the Project

This phase will guide you through the following activities:

• Identify Metrics and Build the Change Calendar
• Implement the Project

This phase involves the following participants:

• CIO/IT Director
• IT Managers
• Change Manager

Step 4.1

Identify Metrics and Build the Change Calendar

Activities

4.1.1 Create an Outline for Your Change Calendar

4.1.2 Determine Metrics, Key Performance Indicators (KPIs), and Critical Success Factors (CSFs)

4.1.3 Track and Record Metrics Using the Change Management Metrics Tool

Measure, Manage, and Maintain

Step 4.1: Identify Metrics and Build the Change Calendar

Step 4.2: Implement the Project

This step involves the following participants:

• CIO/IT Director
• IT Managers
• Change Manager

Outcomes of this step

• Clear definitions of change calendar content
• Guidelines for change calendar scheduling
• Defined metrics to measure the success of change management with associated reports, KPIs, and CSFs

Enforce a standard method of prioritizing and scheduling changes

The impact of not deploying the change and the benefit of deploying it should determine its priority.

Risk of Not Deploying

• What is the urgency of the change?
• What is the risk to the organization if the change is not deployed right away?
• Will there be any lost productivity, service disruptions, or missed critical business opportunities?
  • Timing
    • Does the proposed timing work with the approved changes already on the change schedule?
    • Has the change been clash checked so there are no potential conflicts over services or resources?
  • Once prioritized, a final deployment date should be set by the CAB. Check the change calendar first to avoid conflicts.

Positive Impact of Deployment

• What benefits will be realized once the change is deployed?
• How significant is the opportunity that triggered the change?
• Will the change lead to a positive business outcome (e.g. increased sales)?

“The one who has more clout or authority is usually the one who gets changes scheduled in the time frame they desire, but you should really be evaluating the impact to the organization. We looked at the risk to the business of not doing the change, and that’s a good way of determining the criticality and urgency of that change.” – Joseph Sgandurra, Director, Service Delivery, Navantis

Info-Tech Insight

Avoid a culture where powerful stakeholders are able to push change deployment on an ad hoc basis. Give the CAB the full authority to make approval decisions based on urgency, impact, cost, and availability of resources.

Develop a change schedule to formalize the planning process

A change calendar will help the CAB schedule changes more effectively and increase visibility into upcoming changes across the organization.

1. Establish change windows in a consistent change schedule:
   • Compile a list of business units that would benefit from a change.
   • Look for conflicts in the change schedule.
   • Avoid scheduling two or more major business units in a day.
   • Consider clients when building your change windows and change schedule.
2. Gain commitments from key participants:
   • These individuals can confirm if there are any unusual or cyclical business requirements that will impact the schedule.
3. Properly control your change calendar to improve change efficiency:
   • Look at the proposed start and end times: Are they sensible? Does the implementation window leave time for anything going wrong or needing to roll back the change?
   • Special considerations: Are there special circumstances that need to be considered? Ask the business if you don’t know.
   • The key principle is to have a sufficient window available for implementing changes so you only need to set up calendar freezes for sound business or technical reasons.

“Our mantra is to put it on the calendar. Even if it’s a preapproved change and doesn’t need a vote, having it on the calendar helps with visibility. The calendar is the one-stop shop for scheduling and identifying change dependencies.“ – Wil Clark, Director of Service and Performance Management, University of North Texas Systems

Provide clear definitions of what goes on the change calendar and who’s responsible

Roles

• The Change Manager will be responsible for creating and maintaining a change calendar.
• Only the Change Manager can physically alter the calendar by adding a new change after the CAB has agreed upon a deployment date.
• All other CAB members, IT support staff, and other impacted stakeholders should have access to the calendar on a read-only basis to prevent people from making unauthorized changes to deployment dates.

Inputs

• Freeze periods for individual business departments/applications (e.g. finance month-end periods, HR payroll cycle, etc. – all to be investigated).
• Maintenance windows and planned outage periods.
• Project schedules, and upcoming major/medium changes.
• Holidays.
• Business hours (some departments work 9-5, others work different hours or in different time zones, and user acceptance testing may require business users to be available).

Guidelines

• Business-defined freeze periods are the top priority.
• No major or medium normal changes should occur during the week between Christmas and New Year’s Day.
• Vendor SLA support hours are the preferred time for implementing changes.
• The vacation calendar for IT will be considered for major changes.
• Change priority: High > Medium > Low.
• Minor changes and preapproved changes have the same priority and will be decided on a case-by-case basis.

The change calendar is a critical pre-requisite to change management in DevOps. Use the calendar to be proactive with proposed implementation dates and deconfliction before the change is finished.

4.1.1 Create Guidelines for Your Change Calendar

Input

• Current change calendar guidelines

Output

• Change calendar inputs and schedule checklist

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Projector
• Markers/pens
• Project Summary Template

Participants

• Change Manager
• Members of the Change Advisory Board
• Service Desk Manager
• Operations (optional)

1. Gather representatives from the change management team.
   • Example:
     • The change calendar/schedule includes:
       • Approved and scheduled normal changes.
       • Scheduled project work.
       • Scheduled maintenance windows.
       • Change freeze periods with affected users noted:
         • Daily/weekly freeze periods.
         • Monthly freeze periods.
         • Annual freeze periods.
         • Other critical business events.
2. Create a checklist to run through before each change is scheduled:
   • Check the schedule and assess resource availability:
     • Will user productivity be impacted?
     • Are there available resources (people and systems) to implement the change?
     • Is the vendor available? Is there a significant cost attached to pushing change deployment before the regularly scheduled refresh?
     • Are there dependencies? Does the deployment of one change depend on the earlier deployment of another?
3. Record your results in your Project Summary Template.

Start measuring the success of your change management project using three key metrics

Number of change-related incidents that occur each month

• Each month, record the number of incidents that can be directly linked to a change. This can be done using an ITSM tool or manually by service desk staff.
• This is a key success metric: if you are not tracking change-related incidents yet, start doing so as soon as possible. This is the metric that the CIO and business stakeholders will be most interested in because it impacts users directly.

Number of unauthorized changes applied each month

• Each month, record the number of changes applied without approval. This is the best way to measure adherence to the process.
• If this number decreases, it demonstrates a reduction in risk, as more changes are formally assessed and approved before being deployed.

Percentage of emergency changes

• Each month, compare the number of emergency change requests to the total number of change requests.
• Change requesters often designate changes as emergencies as a way of bypassing the process.
• A reduction in emergency changes demonstrates that your process is operating smoothly and reduces the risk of deploying changes that have not been properly tested.

Info-Tech Insight

Start simple. Metrics can be difficult to tackle if you’re starting from scratch. While implementing your change management practice, use these three metrics as a starting point, since they correlate well with the success of change management overall. The following few slides provide more insight into creating metrics for your change process.

If you want more insight into your change process, measure the progress of each step in change management with metrics

Improve

• Number of repeat failures (i.e. making the same mistake twice)
• Number of changes converted to pre-approved
• Number of changes converted from pre-approved back to normal

Request

• What percentage of change requests have errors or lack appropriate support?
• What percentage of change requests are actually projects, service requests, or operational tasks?
• What percentage of changes have been requested before (i.e. documented)?

Assess

• What percentage of change requests are out of scope?
• What percentage of changes have been requested before (i.e. documented)?
• What are the percentages of changes by category (normal, pre-approved, emergency)?

Plan

• What percentage of change requests are reviewed by the CAB that should have been pre-approved or emergency (i.e. what percentage of changes are in the wrong category)?

Approve

• Number of changes broken down by department (business unit/IT department to be used in making core/optional CAB membership more efficient)
• Number of workflows that can be automated

Implement

• Number of changes completed on schedule
• Number of changes rolled back
• What percentage of changes caused an incident?

Use metrics to inform project KPIs and CSFs

Leverage the metrics from the last slide and convert them to data communicable to IT, management, and leadership

• To provide value, metrics and measurements must be actionable. What actions can be taken as a result of the data being presented?
• If the metrics are not actionable, there is no value and you should question the use of the metric.
• Data points in isolation are mostly meaningless to inform action. Observe trends in your metrics to inform your decisions.
• Using a framework to develop measurements and metrics provides a defined methodology that enables a mapping of base measurements through CSFs.
• Establishing the relationship increases the value that measurements provide.

Purposely use SDLC and change lifecycle metrics to find bottlenecks and automation candidates.

Metrics:

Metrics are easily measured datapoints that can be pulled from your change management tool. Examples: Number of changes implemented, number of changes without incident.

KPIs:

Key Performance Indicators are metrics presented in a way that is easily digestible by stakeholders in IT. Examples: Change efficiency, quality of changes.

CSFs:

Critical Success Factors are measures of the business success of change management taken by correlating the CSF with multiple KPIs. Examples: consistent and efficient change management process, a change process mapped to business needs

List in-scope metrics and reports and align them to benefits

4.1.2 Determine Metrics, Key Performance Indicators (KPIs), and Critical Success Factors (CSFs)

Input

• Current metrics

Output

• List of trackable metrics, KPIs and CSFs

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Change Management SOP

Participants

• Change Manager
• Members of the Change Advisory Board
• Service Desk Manager
• Operations (optional)

1. Draw three tables for metrics, KPIs, and CSFs.
2. Starting with the CSF table, fill in all relevant CSFs that your group wishes to track and measure.
3. Next, work to determine relevant KPIs correlated with the CSFs and metrics needed to measure the KPIs. Use the tables included below (taken from section 14 of the Change Management SOP) to guide the process.
4. Record the results in the tables in section 14 of your Change Management SOP.
5. Decide on where and when to review the metrics to discuss your change management strategy. Designate and owner and record in the RACI and Communications section of your Change Management SOP.

Measure changes in selected metrics to evaluate success

Once you have implemented a standardized change management practice, your team’s goal should be to improve the process, year over year.

• After a process change has been implemented, it’s important to regularly monitor and evaluate the CSFs, KPIs, and metrics you chose to evaluate. Examine whether the process change you implemented has actually resolved the issue or achieved the goal of the critical success factor.
• Establish a schedule for regularly reviewing the key metrics. Assess changes in those metrics and determine progress toward reaching objectives.
• In addition to reviewing CSFs, KPIs, and metrics, check in with the release management team and end users to measure their perceptions of the change management process once an appropriate amount of time has passed.
• Ensure that metrics are telling the whole story and that reporting is honest in order to be informative.

Outcomes of standardizing change management should include:

1. Improved efficiency, effectiveness, and quality of changes.
2. Changes and processes are more aligned with the business needs and strategy.
3. Improved maturity of change processes.

Info-Tech Best Practice

Make sure you’re measuring the right things and considering all sources of information. It’s very easy to put yourself in a position where you’re congratulating yourselves for improving on a specific metric such as number of releases per month, but satisfaction remains low.

4.1.3 Track and Record Metrics Using the Change Management Metrics Tool

Input

• Current metrics

Output

• List of trackable metrics, KPIs and CSFs to be observed over the length of a year

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Change Management Metrics Tool

Participants

• Change Manager
• Members of the Change Advisory Board
• Service Desk Manager
• Operations (optional)

Tracking the progress of metrics is paramount to the success of any change management process. Use Info-Tech’s Change Management Metrics Tool to record metrics and track your progress. This tool is intended to be a substitute for organizations who do not have the capability to track change-related metrics in their ITSM tool.

1. Input metrics from the previous activity to track over the course of a year.
2. To record your metrics, open the tool and go to tab 2. The tool is currently primed to record and track five metrics. If you need more than that, you can edit the list in the hidden calculations tab.
3. To see the progress of your metrics, move to tab 3 to view a dashboard of all metrics in the tool.

Download the Change Management Metrics Tool

Case Study

A federal credit union was able to track maturity growth through the proper use of metrics.

Industry: Federal Credit Union (anonymous)

Source: Info-Tech Workshop

Challenge

At this federal credit union, the VP of IT wanted a tight set of metrics to engage with the business, communicate within IT, enable performance management of staff, and provide visibility into workload demands, among other requirements.

The organization was suffering from “metrics fatigue,” with multiple reports being generated from all groups within IT, to the point that weekly/monthly reports were being seen as spam.

Solution

Stakeholders were provided with an overview of change management benefits and were asked to identify one key attribute that would be useful to their specific needs.

Metrics were designed around the stakeholder needs, piloted with each stakeholder group, fine-tuned, and rolled out.

Some metrics could not be automated off-the-shelf and were rolled out in a manual fashion. These metrics were subsequently automated and finally made available through a dashboard.

Results

The business received clear guidance regarding estimated times to implement changes across different elements of the environment.

The IT managers were able to plan team workloads with visibility into upstream change activity.

Architects were able to identify vendors and systems that were the leading source of instability.

The VP of IT was able to track the maturity growth of the change management process and proactively engage with the business on identified hot spots.

Step 4.2

Implement the Project

Activities

4.2.1 Use a Communications Plan to Gain End User Buy-In

4.2.2 Create a Project Roadmap to Track Your Implementation Progress

Measure, Manage, and Maintain

Step 4.1: Identify Metrics and Build the Change Calendar

Step 3.2: Implement the Project

This step involves the following participants:

• CIO/IT Director
• IT Managers
• Change Manager

Outcomes of this step

• A communications plan for key messages to communicate to relevant stakeholders and audiences
• A roadmap with assigned action items to implement change management

Success of the new process will depend on introducing change and gaining acceptance

Change management provides value by promptly evaluating and delivering changes required by the business and by minimizing disruption and rework caused by failed changes. Communication of your new change management process is key. If people do not understand the what and why, it will fail to provide the desired value.

Info-Tech Best Practice

Gather feedback from end users about the new process: if the process is too bureaucratic, end users are more likely to circumvent it.

Main Challenges with Communication

• Many people fail before they even start because they are buried in a mess created before they arrived – either because of a failed attempt to get change management implemented or due to a complicated system that has always existed.
• Many systems are maintained because “that’s the way it’s always been done.”
• Organizations don’t know where to start; they think change management is too complex a process.
• Each group needs to follow the same procedure – groups often have their own processes, but if they don’t agree with one another, this could cause an outage.

Educate affected stakeholders to prepare for organizational change

An organizational change management plan should be part of your change management project.

• Educate stakeholders about:
  • The process change (describe it in a way that the user can understand and is clear and concise).
    • IT changes will be handled in a standardized and repeatable fashion to minimize change-related incidents.
  • Who is impacted?
    • All users.
  • How are they impacted?
    • All change requests will be made using a standard form and will not be deployed until formal approval is received.
  • Change messaging.
    • How to communicate the change (benefits).
  • Learning and development – training your users on the change.
    • Develop and deliver training session on the Change Management SOP to familiarize users with this new method of handling IT change.

Host a lunch-and-learn session

• For the initial deployment, host a lunch-and-learn session to educate the business on the change management practice. Relevant stakeholders of affected departments should host it and cover the following topics:
• What is change management (change management/change control)?
• The value of change management.
• What the Change Management SOP looks like.
• Who is involved in the change management process (the CAB, etc.)?
• What constitutes a pre-approved change and an emergency change?
• An overview of the process, including how to avoid unauthorized changes.
• Who should they contact in case of questions?

Communicate the new process to all affected stakeholders

Do not surprise users or support staff with changes. This will result in lost productivity and low satisfaction with IT services.

• User groups and the business need to be given sufficient notice of an impending change.
• This will allow them to make appropriate plans to accept the change, minimizing the impact of the change on productivity.
• A communications plan will be documented in the RFC while the release is being built and tested.
• It’s the responsibility of the change team to execute on the communications plan.

Info-Tech Insight

The success of change communication can be measured by monitoring the number of service desk tickets related to a change that was not communicated to users.

Communication is crucial to the integration and overall implementation of your change management initiative. An effective communications plan will:

• Gain support from management at the project proposal phase.
• Create end-user buy-in once the program is set to launch.
• Maintain the presence of the program throughout the business.
• Instill ownership throughout the business from top-level management to new hires.

Create your communications plan to anticipate challenges, remove obstacles, and ensure buy-in

Management

Technicians

Business Stakeholders

Provide separate communications to key stakeholder groups

Why? What problems are you trying to solve?

What? What processes will it affect (that will affect me)?

Who? Who will be affected? Who do I go to if I have issues with the new process?

When? When will this be happening? When will it affect me?

How? How will these changes manifest themselves?

Goal? What is the final goal? How will it benefit me?

Info-Tech Insight

Pay close attention to the medium of communication. For example, stakeholders on their feet all day would not be as receptive to an email communication compared to those who primarily work in front of a computer. Put yourself into various stakeholders’ shoes to craft a tailored communication of change management.

4.2.1 Use a Communications Plan to Gain End User Buy-In

Input

• List of stakeholder groups for change management

Output

• Tailored communications plans for various stakeholder groups

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Change Management Communications Plan

Participants

• Change Manager
• Members of the Change Advisory Board
• Service Desk Manager
• Operations (optional)

1. Using Info-Tech’s Change Management Communications Plan, identify key audiences or stakeholder groups that will be affected by the new change management practice.
2. For each group requiring a communications plan, identify the following:
   • The benefits for that group of individuals.
   • The impact the change will have on them.
   • The best communication method(s) for them.
   • The time frame of the communication.
3. Complete this information in a table like the one below:

4. Discuss the communications plan:
   • Will this plan ensure that users are given adequate opportunities to accept the changes being deployed?
   • Is the message appropriate for each audience? Is the format appropriate for each audience?
   • Does the communication include training where necessary to help users adopt any new functions/workflows being introduced?

Download the Change Management Communications Plan

Present your SOP to key stakeholders and obtain their approval

Now that you have completed your Change Management SOP, the final step is to get sign-off from senior management to begin the rollout process.

Know your audience:

• Determine the service management stakeholders who will be included in the audience for your presentation.
• You want your presentation to be succinct and hard hitting. Management’s time is tight and they will lose interest if you drag out the delivery.
• Briefly speak about the need for more formal change management and emphasize the benefits of implementing a more formal process with a SOP.
• Present your current state assessment results to provide context before presenting the SOP itself.
• As with any other foundational activity, be prepared with some quick wins to gain executive attention.
• Be prepared to review with both technical and less technical stakeholders.

Info-Tech Insight

The support of senior executive stakeholders is critical to the success of your SOP rollout. Try to wow them with project benefits and make sure they know about the risks/pain points.

Download the Change Management Project Summary Template

4.2.2 Create a Project Roadmap to Track Your Implementation Progress

Input

• List of implementation tasks

Output

• Roadmap and timeline for change management implementation

Materials

• Whiteboard/flip charts (or shared screen if working remotely)
• Markers/pens
• Change Management Roadmap Tool

Participants

• Change Manager
• Members of the Change Advisory Board
• Service Desk Manager
• Operations (optional)

1. Info-Tech’s Change Management Roadmap Tool helps you identify and prioritize tasks that need to be completed for the change management implementation project.
2. Use this tool to identify each action item that will need to be completed as part of the change management initiative. Chart each action item, assign an owner, define the duration, and set a completion date.
3. Use the resulting rocket diagram as a guide to task completion as you work toward your future state.

Download the Change Management Roadmap Tool

Case Study (part 4 of 4)

Intel implemented a robust change management process.

Industry: Technology

Source: Daniel Grove, Intel

Challenge

Founded in 1968, the world’s largest microchip and semiconductor company employs over 100,000 people. Intel manufactures processors for major players in the PC market including Apple, Lenovo, HP, and Dell.

Intel IT supports over 65,000 servers, 3.2 petabytes of data, over 70,000 PCs, and 2.6 million emails per day.

Intel’s change management program is responsible for over 4,000 changes each week.

Solution

Intel had its new change management program in place and the early milestones planned, but one key challenge with any new project is communication.

The company also needed to navigate the simplification of a previously complex process; end users could be familiar with any of the 37 different change processes or 25 different change management systems of record.

Top-level buy-in was another concern.

Results

Intel first communicated the process changes by publishing the vision and strategy for the project with top management sponsorship.

The CIO published all of the new change policies, which were supported by the Change Governance Council.

Intel cited the reason for success as the designation of a Policy and Guidance Council – a group designed to own communication and enforcement of the new policies and processes put in place.

Summary of Accomplishment

Problem Solved

You now have an outline of your new change management process. The hard work starts now for an effective implementation. Make use of the communications plan to socialize the new process with stakeholders and the roadmap to stay on track.

Remember as you are starting your implementation to keep your documents flexible and treat them as “living documents.” You will likely need to tweak and refine the processware and templates several times to continually improve the process. Furthermore, don’t shy away from seeking feedback from your stakeholders to gain buy-in.

Lastly, keep an eye on your progress with objective, data-driven metrics. Leverage the trends in your data to drive your decisions. Be sure to revisit the maturity assessment not only to measure and visualize your progress, but to gain insight into your next steps.

If you would like additional support, have our analysts guide you through other phases as part of an Info-Tech workshop.

Contact your account representative for more information.

workshops@infotech.com

1-888-670-8889

Additional Support

If you would like additional support, have our analysts guide you through other phases as part of an Info-Tech workshop.

To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team.

Info-Tech analysts will join you and your team at your location or welcome you to Info-Tech’s historic office in Toronto, Ontario, Canada to participate in an innovative onsite workshop.

Contact your account representative for more information.

workshops@infotech.com 1-888-670-8889

The following are sample activities that will be conducted by Info-Tech analysts with your team:

1.1.2 Complete a Change Management Maturity Assessment

Run through the change management maturity assessment with tailored commentary for each action item outlining context and best practices.

2.2.1 Plot the Process for a Normal Change

Build a normal change process using Info-Tech’s Change Management Process Library template with an analyst helping you to right size the process for your organization.

Related Info-Tech Research

Standardize the Service Desk

Improve customer service by driving consistency in your support approach and meeting SLAs.

Stabilize Release and Deployment Management

Maintain both speed and control while improving the quality of deployments and releases within the infrastructure team.

Incident and Problem Management

Don’t let persistent problems govern your department.

Select Bibliography

AXELOS Limited. ITIL Foundation: ITIL 4th edition. TSO, 2019, pp. 118–120.

Behr, Kevin and George Spafford. The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps. IT Revolution Press. 2013.

BMC. “ITIL Change Management.” BMC Software Canada, 22 December 2016.

Brown, Vance. “Change Management: The Greatest ROI of ITIL.” Cherwell Service Management.

Cisco. “Change Management: Best Practices.” Cisco, 10 March 2008.

Grove, Daniel. “Case Study ITIL Change Management Intel Corporation.” PowerShow, 2005.

ISACA. “COBIT 5: Enabling Processes.” ISACA, 2012.

Jantti, M. and M. Kainulainen. “Exploring an IT Service Change Management Process: A Case Study.” ICDS 2011: The Fifth International Conference on Digital Society, 23 Feb. 2011.

Murphy, Vawns. “How to Assess Changes.” The ITSM Review, 29 Jan. 2016.

Nyo, Isabel. “Best Practices for Change Management in the Age of DevOps.” Atlassian Engineering, 12 May 2021.

Phillips, Katherine W., Katie A. Liljenquist, and Margaret A. Neale. “Better Decisions Through Diversity.” Kellogg Insight, 1 Oct. 2010.

Pink Elephant. “Best Practices for Change Management.” Pink Elephant, 2005.

Sharwood, Simon. “Google broke its own cloud by doing two updates at once.” The Register, 24 Aug. 2016.

SolarWinds. “How to Eliminate the No: 1 Cause of Network Downtime.” SolarWinds Tech Tips, 25 Apr. 2014.

The Stationery Office. “ITIL Service Transition: 2011.” The Stationary Office, 29 July 2011.

UCISA. “ITIL – A Guide to Change Management.” UCISA.

Zander, Jason. “Final Root Cause Analysis and Improvement Areas: Nov 18 Azure Storage Service Interruption.” Microsoft Azure: Blog and Updates, 17 Dec. 2014.

Appendix I: Expedited Changes

Employ the expedited change to promote process adherence

In many organizations, there are changes which may not fit into the three prescribed categories. The reason behind why the expedited category may be needed generally falls between two possibilities:

1. External drivers dictate changes via mandates which may not fall within the normal change cycle. A CIO, judge, state/provincial mandate, or request from shared services pushes a change that does not fall within a normal change cycle. However, there is no imminent outage (therefore it is not an emergency). In this case, an expedited change can proceed. Communicate to the change requester that IT and the change build team will still do their best to implement the change without issue, but any extra risk of implementing this expedited change (compared to an normal change) will be absorbed by the change requester.
2. The change requester did not prepare for the change adequately. This is common if a new change process is being established (and stakeholders are still adapting to the process). Change requesters or the change build team may request the change to be done by a certain date that does not fall within the normal change cycle, or they simply did not give the CAB enough time to vet the change. In this case, you may use the expedited category as a metric (or a “Hall of Shame” example). If you identify a department or individual that frequently request expedited changes, use the expedited category as a means to educate them about the normal change to discourage the behavior moving forward.

Two possible ways to build an expedited change category”

1. Build the category similar to an emergency change. In this case, one difference would be the time allotted to fully obtain authorization of the change from the E-CAB and business owner before implementing the change (as opposed to the emergency change workflow).
2. Have the expedited change reflect the normal change workflow. In this case, all the same steps of the normal change workflow are followed except for expedited timelines between processes. This may include holding an impromptu CAB meeting to authorize the change.

Example process: Expedited Change Process

For the full process, refer to the Change Management Process Library.

Appendix II: Optimize IT Change Management in a DevOps Environment

Change Management cannot be ignored because you are DevOps or Agile

But it can be right-sized.

The core tenets of change management still apply no matter the type of development environment an organization has. Changes in any environment carry risk of degrading functionality, and must therefore be vetted. However, the amount of work and rigor put into different stages of the change life cycle can be altered depending on the maturity of the development workflows. The following are several stage gates for change management that MUST be considered if you are a DevOps or Agile shop:

• Intake assessment (separation of changes from projects, service requests, operational tasks)
  • Within a DevOps or Agile environment, many of the application changes will come directly from the SDLC and projects going live. It does not mean a change must go through CAB, but leveraging the pre-approved category allows for an organization to stick to development lifecycles without being heavily bogged down by change bureaucracy.
• Technical review
  • Leveraging automation, release contingencies, and the current SDLC documentation to decrease change risk allows for various changes to be designated as pre-approved.
• Authorization
  • Define the authorization and dependencies of a change early in the lifecycle to gain authorization and necessary signoffs.
• Documentation/communication
  • Documentation and communication are post-implementation activities that cannot be ignored. If documentation is required throughout the SDLC, then design the RFC to point to the correct documentation instead of duplicating information.

"Understand that process is hard and finding a solution that fits every need can be tricky. With this change management process we do not try to solve every corner case so much as create a framework by which best judgement can be used to ensure maximum availability of our platforms and services while still complying with our regulatory requirements and making positive changes that will delight our customers.“ -IT Director, Information Cybersecurity Organization

Five principals for implementing change in DevOps

Follow these best practices to make sure your requirements are solid:

People

The core differences between an Agile or DevOps transition and a traditional approach are the restructuring and the team behind it. As a result, the stakeholders of change management must be onboard for the process to work. This is the most difficult problem to solve if it’s an issue, but open avenues of feedback for a process build is a start.

DevOps Lifecycles

• Plan the dev lifecycle so people can’t skirt it. Ensure the process has automated checks so that it’s more work to skirt the system than it is to follow it. Make the right process the process of least resistance.
• Plan changes from the start to ensure that cross-dependencies are identified early and that the proposed implementation date is deconflicted and visible to other change requesters and change stakeholders.

Automation

Automation comes in many forms and is well documented in many development workflows. Having automated signoffs for QA/security checks and stakeholders/cross dependency owner sign offs may not fully replace the CAB but can ease the burden on discussions before implementation.

Contingencies

Canary releases, phased releases, dark releases, and toggles are all options you can employ to reduce risk during a release. Furthermore, building in contingencies to the test/rollback plan decreases the risk of the change by decreasing the factor of likelihood.

Continually Improve

Building change from the ground up doesn’t meant the process has to be fully fledged before launch. Iterative improvements are possible before achieving an optimal state. Having the proper metrics on the pain points and bottlenecks in the process can identify areas for automation and improvement.

Increasing the proportion of pre-approved changes

Leverage the traditional change infrastructure to deploy changes quickly while keeping your risk low.

• To designate a change as a pre-approved change it must have a low risk rating (based on impact and likelihood). Fortunately, many of the changes within the Agile framework are designed to be small and lower risk (at least within application development). Putting in the work ahead of time to document these changes, template RFCs, and document the dependencies for various changes allows for a shift in the proportion of pre-approved changes.
• The designation of pre-approved changes is an ongoing process. This is not an overnight initiative. Measure the proportion of changes by category as a metric, setting goals and interim goals to shift the change proportion to a desired ratio.

Turn your CAB into a virtual one

• The CAB does not have to fully disappear in a DevOps environment. If the SDLC is built in a way that authorizes changes through peer reviews and automated checks, by the time it’s deployed, the job of the CAB should have already been completed. Then the authorization stage-gate (traditionally, the CAB) shifts to earlier in the process, reducing the need for an actual CAB meeting. However, the change must still be communicated and documented, even if it’s a pre-approved change.
• As the proportion of changes shifts from a high degree of normal changes to a high degree of pre-approved changes, the need for CAB meetings should decrease even further. As an end-state, you may reserve actual CAB meetings for high-profile changes (as defined by risk).
• Lastly, change management does not disappear as a process. Periodic reviews of change management metrics and the pre-approved change list must still be completed.