It Optimize IT Change Management Phases 1 4 R4

Optimize IT Change
Management
Right-size IT change management to protect
the live environment.
Info-Tech Research Group Inc. is a global leader in providing IT research and

advice. Info-Tech’s products and services combine actionable insight and
relevant advice with ready-to-use tools and templates that cover the full
spectrum of IT concerns.
© 1997-2021 Info-Tech Research Group Inc.
3 Executive Brief 103 Phase 4: Measure, Manage, and
Maintain
Table of 4 Analyst Perspective
104 Step 4.1: Identify Metrics and Build
Contents 5
26
Executive Summary
Phase 1: Define Change Management

the Change Calendar
117 Step 4.2: Implement the Project
27 Step 1.1: Assess Maturity 126 Summary of Accomplishment
35 Step 1.2: Categorize Changes and 127 Additional Support

Your Build Risk Assessment
129 Select Bibliography
50 Phase 2: Establish Roles and
Workflows 130 Appendix I: Expedited Changes
51 Step 2.1: Determine Roles and 131 Appendix II: Optimize IT Change
Responsibilities Management in a DevOps Environment
61 Step 2.2: Build Core Workflows
82 Phase 3: Define the RFC and Post-

Implementation Activities
83 Step 3.1: Design the RFC
93 Step 3.2: Establish Post-

Info-Tech Research Group | 2
Optimize IT Change
Management
Right-size IT change management practice
to protect the live environment.
EXECUTIVE BRIEF
Analyst
Perspective
Balance risk and efficiency to 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
optimize IT change management. 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 Common Obstacles Info-Tech’s Approach
Infrastructure and application change occurs IT system owners often resist change management Info-Tech’s approach will help you:
constantly and is driven by changing business because they see it as slow and bureaucratic.
• Create a unified change management practice
needs, requests for new functionality, operational
At the same time, an increasingly interlinked that balances risk and throughput of innovation.
releases and patches, and resolution of incidents or
technical environment may cause issues to appear
problems detected by the service desk. • Categorize changes based on an industry-
in unexpected places. Configuration management
standard risk model with objective measures of
IT managers need to follow a standard change systems are often not kept up-to-date and do not
impact and likelihood.
management process to ensure that rogue changes catch the potential linkages.
are never deployed while the organization remains • Establish and empower a Change Manager and
Infrastructure changes are often seen as “different”
responsive to demand. Change Advisory Board (CAB) with the
from application changes and two (or more)
authority to manage, approve, and prioritize
processes may exist.
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 Increase the Effectiveness of Change
Management in Your Organization
10
This research is designed to help organizations
9 8.6
who need to:
8
7
6.2
• Build a right-sized change management practice that encourages 6
adherence and balances efficiency and risk. 5
• Integrate the change management practice with project 4
management, service desk processes, configuration management, 3
and other areas of IT and the business. 2
1
• Communicate the benefits and impact of change management to
0
all the stakeholders affected by the process. 1 2
Of the eight infrastructure & operations processes measured in

Change management is heavily reliant on organizational culture Info-Tech’s IT Management and Governance Diagnostic (MGD)
program, change management has the second largest gap
Having a right-sized process is not enough. You need to build and communicate the process between importance and effectiveness of these processes. See
this slide for more details.
to gather adherence. The process is useless if stakeholders are not aware of it or do not
follow it. Source: Info-Tech 2020; n=5,108 IT professionals from
620 organizations
Common obstacles “Why should I fill out an RFC
when it only takes five
minutes to push through
These barriers make this challenge difficult to address for many my change?”
organizations:
“We’ve been
doing this for
years. Why do
• Gaining buy-in can be a challenge no matter how well the process “We don’t need
we need more
bureaucracy?”
is built. change
management if
we’re Agile.”
• The complexity of the IT environment and culture of tacit
knowledge for configuration makes it difficult to assess cross- “We don’t have the right
dependencies of changes. tools to even start change
management.”
• Each silo or department may have their own change management

workflows that they follow internally. This can make it difficult to
“Why do I have to attend
create a unified process that works well for everyone. 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 The Info-Tech difference:
around appropriate levels of the change lifecycle.
1. Create a unified change
management process that balances
Improve risk and throughput of innovation.
2. Categorize changes based on an
industry-standard risk model with
Request objective measures of impact and
likelihood.
Implement
3. Establish and empower a Change
Manager and Change Advisory
Assess Board (CAB) with the authority to
manage, approve, and prioritize
Approve changes.
Plan

IT change is constant and is driven by:
1 2
Major Release New Application
Operational releases, Business

Maintenance
maintenance, vendor- Operations
Release
driven updates, and New Version
security updates can
all be key drivers of Security Patch Business-driven changes may include
change.
requests from other business
Example: ITSM
departments that require IT’s support.
version update
Examples: New ERP or HRIS
implementation
CHANGE
MANAGEMENT
3
In addition to software and hardware
Some incident and asset dependencies, a configuration
problem tickets Workaround Fix
management database (CMDB) is used to
require a change to keep a record of changes and is queried to
facilitate resolution of assess change requests.
the incident.
Examples: Outage
necessitating update of Hardware
an app (emergency Service Incident & Configuration
Asset
change), a user request Desk Problem Management
Management
for new functionality Database (CMDB)
Software
to be added to an
existing app
Insight Build a unified change management process balancing risk and change
throughput.
summary 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.
“The scope of change Use an objective framework Integrate your change Change management and
management is defined by each for estimating risk process with your IT DevOps can work together
service management effectively
organization…the purpose of system
change management is to
Simply asking, “What is the
maximize the number of risk?” will result in subjective Change management in Change and DevOps tend to be at
successful service and product responses that will likely isolation will provide some odds, but the framework does not
changes by ensuring that the risk minimize the perceived risk. stability, but maturing the have to change. Lower risk changes
The level of due diligence process through service in DevOps are prime candidates for
have been properly assessed, the pre-approved category. Much of
should align to the criticality integrations will enable
authorizing changes to process, the responsibility traditionally
of the systems or departments data-driven decisions,
and managing the change assigned to the CAB can be diffused
potentially impacted by the decrease bureaucracy, and
throughout the software
schedule.” proposed changes. enable faster and more development lifecycle.
stable throughput.
– ALEXOS Limited, ITIL 4

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 Business Benefits

• Fewer change-related incidents and outages • Fewer service disruptions
• Faster change turnaround time • Faster response to requests for new and enhanced functionalities
• Higher rate of change success • Higher rate of benefits realization when changes are implemented
• Less change rework • Lower cost per change
• Fewer service desk calls related to poorly communicated • Fewer “surprise” changes disrupting productivity
changes
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 Collaboration Consistency Confidence

Change management brings daily Change management planning brings Request for change templates and a Change management processes will
control over the IT environment, increased communication and structured process result in give your organization more
allowing you to review every collaboration across groups by implementation, test, and backout confidence through more accurate
relatively new change, eliminate coordinating changes with business plans being more consistent. planning, improved execution of
changes that would have likely activities. The CAB brings a more Implementing processes for pre- changes, less failure, and more
failed, and review all changes to formalized and centralized approved changes also ensures these control over the IT environment. This
improve the IT environment. communication method for IT. frequent changes are executed also leads to greater protection against
consistently and efficiently. audits.

You likely need to improve change management more
than any other infrastructure & operations process
Of the eight infrastructure and
operations processes measured
8.6
7.9
8.3
8.7 8.4 8.4 8.2
8.9
in Info-Tech’s IT Management
6.2 6.3 6.2
7 and Governance Diagnostic
5.9 6 6
5.3 (MGD) program, change
management consistently has
the second largest gap
between importance and
en
t
en
t
en
t
en
t
en
t
en
t
en
t
es
k effectiveness of these
m m m m m m m D
an
age
an
age
an
a ge
an
age
an
a ge
an
a ge
an
age
rv
ice processes.
e M
n
M e M M
y
M s M t M Se
e
ang atio le as blem acit tion ss
ur ra A
Ch ig Re Pr
o
Ca
p
pe
nf & O
&
Co ent ity
cid il
In ilab
va
A
Effectiveness Importance
Source: Info-Tech 2020; n=5,108 IT Professionals from 620 organizations
Executives and directors recognize the importance of • Info-Tech’s IT Management and
Governance Diagnostic (MGD) program
change management but feel theirs is currently assesses the importance and effectiveness
of core IT processes. Since its inception,
ineffective the MGD has consistently identified change
management as an area for immediate
improvement.
8.9 8.8 8.8
8.6
Importance Scores
No importance: 1.0-6.9
6.5 6.6 6.4 Limited importance: 7.0-7.9
6.1
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
Frontline Manager Director Executive
Effectiveness Importance
Source: Info-Tech 2020; n=5,108 IT Professionals from 620 organizations
There are several “It’s just a small
REALITY
common change; this will

Even a small change can cause a
business outage. That small fix
only take five
misconceptions about minutes to do.”
could impact a large system
connected to the one being fixed.
change management REALITY
“Ad hoc is faster; Ad hoc might be faster in some

cases, but it carries far greater risk.
too many processes Following defined processes keeps
Which of these have you heard in slow things down.” systems stable and risk-averse.
your organization?
REALITY
Change management is about

“Change managing risk. It gives the illusion
management is all of speed by reducing downtime
about speed.” and unplanned work.
REALITY
“Change Change management allows for a

management will better alignment of process
limit our capacity to (release management) with
governance (change management).
change.”
Overcome perceived challenges to implementing change management
to reap measurable reward
Before: Informal Change Management After: Right-Sized Change Management
• Change approval: Changes do not pass through a formal review process before • Change approval: All changes pass through a formal review process. Once a
implementation. change is repeatable and well-tested, it can be pre-approved to save time.
Almost no unauthorized changes are deployed.
• 10% of released changes are approved.
• 95% of 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 • KPI: Decrease in change-related incidents.
approved.
• Change prioritization: The CAB prioritizes changes so that the business is

• Change prioritization: Changes are not prioritized according to urgency, risk, and
satisfied with the speed of change deployment.
impact.
• 35% of changes are urgent.
• 60% of changes are urgent.
• KPI: Decrease in change turnaround time.
• 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: Users are always aware of impending changes and
• Change deployment: Changes often negatively impact user productivity. changes don’t interrupt critical business activities.
• 25% of changes are realized as planned. • Over 80% of changes are realized as planned
• Implementation challenge: Engaging the business so that formal change freeze • KPI: Decrease in the number of failed deployments.
periods and regular maintenance windows can be established.

Info-Tech’s methodology for change management optimization focuses on
building standardized processes
1. Define Change 2. Establish Roles and 3. Define the RFC and Post- 4. Measure, Manage, and
Management Workflows Implementation Activities Maintain
1.1 Assess Maturity 2.1 Determine Roles and 3.1 Design the RFC 4.1 Identify Metrics and Build
Phase Steps 1.2 Categorize Changes and Build Responsibilities 3.2 Establish Post-Implementation the Change Calendar
Your Risk Assessment 2.2 Build Core Workflows Activities 4.2 Implement the Project
Change Management Standard Operating Procedure (SOP)

Change Management Project Summary Template
• Request for Change

Phase (RFC) Form Template • Change Management
Deliverables • Change Management • Change Manager Job • Change Management Metrics Tool
Maturity Assessment Tool Description Pre-Implementation • Change Management
• Change Management Risk • Change Management Process Checklist Communications Plan
Assessment Tool Library • Change Management • Change Management
Post-Implementation Roadmap Tool
Checklist

Key deliverable: Blueprint deliverables
Each step of this blueprint is accompanied by supporting deliverables to help
you accomplish your goals:
Change Management
SOP
Document and formalize your process
starting with the change management Change Management Process Change Management Risk
standard operating procedure (SOP). Library Assessment Tool
Document your normal, pre- Test Drive your impact and
approved, and emergency likelihood assessment
change lifecycles with the core questionnaires with the Change
process workflows . Management Risk Assessment
Tool.
Project Summary Template Change Management Roadmap Tool
Summarize your efforts in the

Record your action items and
Optimize IT Change Management
roadmap your steps to a mature
Improvement Initiative: Project
change management process.
Summary Template.
These case studies illustrate the value of various phases of this project
A major technology company implemented change management to

improve productivity by 40%. This case study illustrates the full scope
of the project.
Define Change
Management
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. Establish Roles and
Workflows
Ignorance of change management process led to a technology giant
experiencing a critical cloud outage. This case study illustrates the
Define RFC and Post-
scope of the process phase. Implementation
Activities
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. Measure, Manage,
and Maintain
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.
Guided Implementation Measured Value
Phase 1: • We estimate Phase 1 activities will take 2 FTEs 10 days to complete on their own, but the time saved
by using Info-Tech’s methodology will cut that time in half, thereby saving $3,100 (2 FTEs * 5 days *
Define Change Management $80,000/year).
Phase 2: • We estimate Phase 2 will take 2 FTEs 10 days to complete on their own, but the time saved by using
Establish Roles and Info-Tech’s methodology will cut that time in half, thereby saving $3,100 (2 FTEs * 5 days *
Workflows $80,000/year).
Define the RFC and Post- Info-Tech’s methodology will cut that time in half, thereby saving $3,100 (2 FTEs * 5 days *
Implementation Activities $80,000/year).
Measure, Manage, and Info-Tech’s methodology will cut that time in half, thereby saving $1,500 (2 FTEs * 2.5 days *
Maintain $80,000/year).
Total savings $10,800
Case Study INDUSTRY SOURCE
Technology 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.
Define Change
ITIL Change Management Implementation Management
With close to 4,000 changes occurring each week, managing Intel’s Establish Roles and
environment is a formidable task. Before implementing change management Workflows
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. Define RFC and Post-
Implementation
Results Activities
After a robust implementation of change management, Intel experienced a

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

Info-Tech offers various levels of
support to best suit your needs
Guided Implementation
DIY Toolkit Workshop Consulting
“Our team has already made this “Our team knows that we need to “We need to hit the ground “Our team does not have the time
critical project a priority, and we fix a process, but we need running and get this project or the knowledge to take this
have the time and capability, but assistance to determine where to kicked off immediately. Our project on. We need assistance
some guidance along the way focus. Some check-ins along the team has the ability to take this through the entirety of this
would be helpful.” way would help keep us on over once we get a framework project.”
track.” and strategy in place.
Diagnostics and consistent frameworks are used throughout all four options.

Guided Implementation A Guided
What does a typical GI on this topic look like? Implementation (GI) is
series of calls with an
Info-Tech analyst to
Define RFC and Post- help implement our
Establish Roles and Measure, Manage, and
Define Change Management
Workflows
Implementation
Activities
Maintain best practices in your
organization.
Call #4: Call #8:
Call #1: Call #6:
Introduce Review roles Define change
Review A typical GI is
metrics.
change and intake process. between 8 to 12 calls
concepts. responsibilities.
Call #5: over the course of 4 to
Call #2: Review core 6 months.
Assess change Call #9: Create
Call #7: Create
current processes. roadmap.
pre-
maturity. implementatio
n and post-
Call #3: implementatio
Identify n checklists.
target-state
capabilities.
Info-Tech
Info-Tech Research
Research Group| 24
Group | 24
Workshop Overview
Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889
Day 1 Day 2 Day 3 Day 4 Day 5

Define Change Management Establish Roles and Define the RFC and Post- Measure, Manage, and Next Steps and
Workflows Implementation Activities Maintain Wrap-Up (offsite)
1.1 Outline Strengths and 2.1 Define the Change 3.1 Create an RFC Template 4.1 Identify Metrics and 5.1 Complete in-progress
Challenges Manager Role Reports deliverables from previous
3.2 Determine Post-
1.2 Conduct a Maturity 2.2 Outline CAB Protocol and Implementation Activities 4.2 Create Communications four days
Activities
Assessment membership Plan 5.2 Set up review time for

3.3 Build a Change Calendar
workshop deliverables and
1.3 Build a Change 2.3 Build Normal Change Protocol 4.3 Build an Implementation
Categorization Scheme Process Roadmap to discuss next steps
1.4 Build Your Risk 2.4 Build Emergency Change

Assessment Process
2.5 Build Pre-Approved
Change Process
1. Maturity Assessment 1. Change Manager Job 1. Request for Change (RFC) 1. Metrics Tool 1. Change Management
Description Form Template Standard Operating
2. Risk Assessment 2. Communications Plan
Deliverables
Procedure (SOP)
2. Change Management 2. Pre-Implementation 3. Project Roadmap
Process Library Checklist 2. Workshop Summary Deck
3. Post-Implementation
Checklist

Phase 1 This phase will guide you through the
following steps:
• Assess Maturity
Define Change Management
• Categorize Changes and Build Your
Risk Assessment
This phase involves the following

participants:
Define Change
Establish Roles and • CIO
Management
Workflows
1.1 Assess Maturity 2.1 Determine Roles and • IT Managers
1.2 Categorize Changes and Responsibilities
Build Your Risk Assessment • Change Manager
2.2 Build Core Workflows
• Members of the Change Advisory
Board
Define the RFC and Measure, Manage, and

Post-Implementation Maintain
Activities
4.1 Identify Metrics and
3.1 Design the RFC Build the Change Calendar
3.2 Establish Post- 4.2 Implement the Project
Optimize IT Change
Management
Step 1.1 This step involves the following
participants:
Assess Maturity • CIO
• IT Managers
• Change Manager
Activities • Members of the Change Advisory
Board
1.1.1 Outline the Organization’s Strengths and Challenges
1.1.2 Complete a Maturity Assessment
Outcomes of this step

• An understanding of maturity change
management processes and
frameworks
Define Change Management • Identification of existing change
management challenges and potential
causes
Step 1.2: Categorize Changes and Build
Step 1.1: Assess Maturity • A framework for assessing change
Your Risk Assessment
management maturity and an
assessment of your existing change
management processes
Change management is often confused with release management, but
they are distinct processes
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 Release and deployment are the detailed plans that
ensure nothing is negatively affected by changes. Change bundle patches, upgrades, and new features into
deployment packages, with the intent to change
Change documentation is more focused on them flawlessly into a production environment.
process, ensuring dependencies are mapped,
rollout plans exist, and the business is not at Release management is one of many actions
risk. Release performed under change management’s
Info-Tech Insight governance.
Ensure the Release Manager is present as part of
your CAB. They can explain any change content or Release documentation includes technical
dependencies, communicate business approval, and specifications such as change schedule, package
advise the service desk of any defects. details, change checklist, configuration details,
test plan, and rollout and rollback plans.
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.
Change Management
RF
RF
RF
RF
C
C
C
C
Release and Build and Post-
Release Release Deploy to Verify
Deployment Configure Test Implementation
Policy Planning Production Deployment
Design Release Activities/Review
Deploy to Communicat
Backout or
Test e and Train
Remediate
Environment Test users
Request for
Release
User
Acceptance
Testing
CM
CM
CM
DB
DB
DB
Configuration Management (CMDB)
Avoid the challenges of poor change
management
1 2 3
Deployments Incidents End Users
• Too frequent: The need for frequent • Too many unauthorized changes: If • Low user satisfaction: Poor
deployments results in reduced availability of the process is perceived as communication and training result in
critical business applications. cumbersome and ineffective, people surprised and unhappy users and
will bypass it or abuse the emergency support staff.
• Failed deployments or rework is required:
designation to get their changes
Deployments are not successful and have to be
deployed faster.
backed out of and then reworked to resolve
issues with the installation. • Changes cause incidents: When new “With no controls in place, IT gets the blame for
releases are deployed, they create embarrassing outages. Too much control, and IT is
• High manual effort: A lack of automation
problems with related systems or seen as a roadblock to innovation.”
results in high resource costs for deployments.
applications. – Anonymous, VP IT of a federal credit union
Human error is likely, which adds to the risk of
a failed deployment.

Input Output
1.1.1 Outline the Organization’s
Strengths and Challenges • Current change
documentation (workflows,
• List of strengths and
challenges for change
SOP, change policy, etc.) management
• Organizational chart(s)
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 Materials Participants
process.
4. Record the activity results in the Project Summary Template. • Whiteboard/flip charts (or • CIO
shared screen if working
• IT Managers
remotely)
• Change Manager
• Markers/pens
• Members of the Change
• Project Summary Template
Advisory Board
Download the Optimize IT Change Management
Improvement Initiative: Project Summary Template

Assess current change management maturity to
create a plan for improvement
Chaos Reactive Controlled Proactive Optimized
RFC form is RFCs are reviewed RFCs trend analysis

Change No defined
processes for
Low process
adherence and no centralized and a for scope and and proactive Info-Tech Insight
Requests submitting changes RFC form point of contact for completion change exists
changes exists
Reaching an
optimized level is not
RFC form is System and
Change Little to no change Risk assessment centralized and a
Change calendar
component
feasible for every
exists and is
Review risk assessment exists for each RFC point of contact for
maintained
dependencies exist organization. You
changes exists (CMDB)
may be able to run a
very good change
Change advisory
Change No formal approval Approval process Unauthorized board (CAB) is Trend analysis exists management process
exists but is not changes are minimal increasing pre-
Approval process exists
or nonexistent
established and at the Proactive or
widely followed formalized approved changes
even Controlled
stage. Pay special
Stakeholder
Post- No post-deployment
Reduction of
satisfaction is Lessons learned are attention to keeping
Process exists but is change-related
Deployment change review exists not widely followed incidents gathered and propagated and your goals attainable.
reviewed actioned
Roles, policies & Policies &

Roles & KPIs are tracked,
Process responsibilities are ad
procedures are procedures are reported on, and
KPIs are proactively
defined & managed for
Governance hoc
documented
enforced and reviewed improvement
complied with
Input Output
1.1.2 Complete a Maturity Assessment • Current change • Assessment of current

documentation (workflows, maturity level and goals to
SOP, change policy, etc.) improve change
management
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:
a. For each activity of each process area of change management, determine
the degree of completeness of your current process. Materials Participants
b. 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. • Change Management Matur • Change Manager
ity Assessment Tool
c. Regularly review the maturity of your change management practices by • Service Desk Manager
completing this maturity assessment tool periodically to identify other • Operations (optional)
areas to optimize.
Download the Change Management Maturity
Assessment Tool

Case Study
INDUSTRY SOURCE
Technology The Register

Even Google isn’t immune to change-related outages. Plan
ahead and communicate to help avoid change-related
incidents
Solution
Thankfully, engineers were actively monitoring As part of a routine maintenance procedure, Google engineers moved App Engine
the implementation of the change and were able
applications between data centers in the Central US to balance out traffic.
to spring into action to halt the problem.
The change was rolled back after 11 minutes,

Unfortunately, at the same time that applications were being rerouted, a software
but the configuration error still needed to be update was in progress on the traffic routers, which triggered a restart. This
fixed. After about two hours, the change failure temporarily diminished router capacity, knocking out a sizeable portion of Google
was resolved and the Google Cloud was fully Cloud.
functional.
The server drain resulted in a huge spike in startup requests, and the routers
One takeaway for the engineering team was to simply couldn’t handle the traffic.
closely monitor how changes are scheduled.
Ultimately, this was the result of As a result, 21% of Google App Engine applications hosted in the Central US
miscommunication and a lack of experienced error rates in excess of 10%, while an additional 16% of applications
transparency between change teams.
experienced latency, albeit at a lower rate.

This step involves the following
Step 1.2 participants:
• Infrastructure/Applications Manager
Categorize Changes and Build Your Risk Assessment • Change Manager

Board
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 Outcomes of this step
• A clear definition of what constitutes a
change in your organization
Define Change Management • A defined categorization scheme to

classify types of changes
• A risk assessment matrix and tool for

evaluating and prioritizing change
Step 1.2: Categorize Changes and Build Your Risk
Step 1.1: Assess Maturity requests according to impact and
Assessment likelihood of risk

Change must be managed to mitigate risk to the
infrastructure
Change management is the gatekeeper protecting your live environment. 80%
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.
In organizations without formal
• IT change is constant; change requests will be made both proactively and
change management processes,
reactively to upgrade systems, acquire new functionality, and to prevent or resolve about 80%* of IT service
incidents. outage problems are caused
by updates and changes to
• Every change to the infrastructure must pass through the change management
process before being deployed to ensure that it has been properly assessed and
systems, applications, and
tested, and to check that a backout /rollback plan is in place. infrastructure. It’s crucial to
track and systematically
• It will be less expensive to invest in a rigorous change management process than to
manage change to fully
resolve incidents, service disruptions, and outages caused by the deployment of a
bad change.
understand and predict the risks
and potential impact of the
• Change management is what gives you control and visibility regarding what is change. Info-Tech Research Group | 36
introduced to the live environment, preventing incidents that threaten business
*Source: The Visible Ops Handbook
Attributes of a change Is this in the production environment of a business
Differentiate changes from other IT requests process?
The core business of the enterprise or supporting functions may be affected.
Does the task affect an enterprise

managed system?
Will this take longer than one If it’s for a local application, it’s a service request
week?
As a general rule, if it takes longer than 40
hours of work to complete, it’s likely a
project.
How many users are impacted?

It should usually impact more than a single user
Is this done/requested by IT?
(in most cases).
It needs to be within the scope of IT for
the change management process to apply.
Does the underlying service currently Is there a configuration, or code, or

exist? workflow, or UI/UX change?
If it’s a new service, then it’s better described as a Any impact on a business process is a change;
project. adding a user or a recipient to a report or
mailing list is not a change. Info-Tech Research Group | 37
Defining what constitutes
a change Do not treat every IT request as a
change!
Every change request will initiate the change management • Many organizations make the mistake of calling a
process; don’t waste time reviewing requests that are out of standard service request or operational task a
scope. “change.”
• Every change request will initiate the change

Change Service Request Operational Task management process; don’t waste time reviewing
(User) (Backend) requests that are out of scope.
• Fixing defects in code • Standardized request • Change the backup tape • While the overuse of RFCs for out-of-scope requests
• Changing configuration • New PC • Delete temporary files
of an enterprise system • Permissions request • Maintain database (one is better than a lack of process, this will slow the
• Adding new software or • Change password that is well defined, process and delay the approval of more critical
hardware components • Add user repeatable, and changes.
• Switching an • Purchases predictable)
application to another • Run utilities to repair a • Requiring an RFC for something that should be
VM database
considered day-to-day work will also discourage
people from adhering to the process, because the RFC
will be seen as meaningless paperwork.

Input Output
1.2.1 Define What Constitutes a Change
• List of examples of each • Definitions for each
category of the chart category to be used at
1. As a group, brainstorm examples of changes, projects, service requests (user), operational tasks change intake
(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?)
Materials Participants
• Record the definitions of requests and results in section 2.3 of the
Change Management Standard Operating Procedure (SOP).
• Whiteboard/flip charts (or • Infrastructure Manager
Change Project Service Operational Release • Change Manager
remotely)
Request Task • Members of the Change
(User) (Backend) • Service catalog (if
Advisory Board
applicable)
Changing ERP upgrade Add new user Delete temp files Software release
Configuration • Sticky notes
• Markers/pens
Download the Change Management Standard
• Change Management SOP
Operating Procedure (SOP).
Each RFC should define resources
needed to effect the change Categories include
Normal
In addition to assigning a category to each RFC
Emergency Pre-Approved
based on risk assessment, each RFC should also be
assigned a priority based on the impact of the The majority of changes will be pre-approved or normal
changes. Definitions of each category are provided on the
change on the IT organization, in terms of the next slide.
resources needed to effect the change.
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.
Info-Tech Best Practice
Do not rush to designate changes as pre-approved. You may have a A potential fourth change category of expedited may
good idea of which changes may be considered pre-approved, but be employed if you are having issues with process
make sure they are in fact low-risk and well-documented before adherence or if you experience changes driven from
moving them over from the normal category. outside change management’s control (e.g. from the
CIO, director, judiciary, etc.) See Appendix I for
more details.
The category of the change determines the process it follows

Pre-Approved Normal Emergency
• Tasks are well-known, • All changes that are not • The change is being requested to
documented, and proven pre-approved or resolve a current or imminent
• Budgetary approval is emergency will be critical/severity-1 incident that
Definitio preordained or within control of classified as normal threatens business continuity
n change requester • Further categorized by • Associated with a critical incident or
Pay close
• Risk is low and understood priority/risk problem ticket
• There’s a low probability of attention to
failure defining your
• The same change is built and • Upgrade or new • A current or imminent critical pre-approved
changed repeatedly using the functionality that will incident that will impact business changes. They
same install procedures and capture a business continuity are going to be
Trigger resulting in the same low-risk benefit • Urgency to implement the change critical for
outcome • A fix to a current must be established, as well as lack
running a
problem of any alternative or workaround
smooth change
• Pre-established • Dependent on the • Dependent on the change management
Workflo • Repeatable with same sequence change
practice in a
of actions, with minimal • Different workflows
w judgment or decision points depending on DevOps
prioritization Environment
• Change Manager (does not need • CAB • Approval from the Emergency
to be reviewed by CAB) Change Advisory Board (E-CAB) is
Approval sufficient to proceed with the change
• A retroactive RFC must be created Info-Tech Research Group | 41
and approved by the CAB

Input Output
1.2.2 Build a Change Categorization

Scheme • List of examples of each
change category
• Definitions for each change
category
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. Materials Participants
Pre-Approved (AKA Standard) Normal Emergency
• Microsoft patch management/deployment Major • Any change other than a pre-
• Active directory server upgrade approved change • Whiteboard/flip charts (or • Infrastructure Manager
• Windows update
• New ERP shared screen if working
• Minor form changes • Needed to resolve a major • Change Manager
outage in a Tier 1 system remotely)
• Service pack updates on non-critical Medium • Members of the Change
systems • Network upgrade • Service catalog (if
Advisory Board
• High availability implementation applicable)
• Advance label status on orders
• Change log retention period/storage Minor • Sticky notes
• Ticket system go-live
• Change backup frequency • Markers
• UPS replacement
• Cognos update
Assess the risk for each normal change based
on impact (severity) and likelihood (probability) Consider risk
1. Risk should be the primary consideration in

Create a change assessment risk matrix to standardize risk assessment for new classifying a normal change as Low, Medium, High.
changes. Formalizing this assessment should be one of the first priorities of
The extent of governance required, as well as
change management.
minimum timeline to implement the change, will
follow from the risk assessment.
The following slides guide you through the steps of formalizing a risk assessment
2. The business benefit often matches the impact level of
according to impact and likelihood:
the risk – a change that will provide a significant
1. Define a risk matrix: benefit to a large number of users may likely carry an
Risk matrices can either be a 3x3 matrix (Minor, Medium, or High Risk as equally major downside if deviations occur.
shown on the next slide) or a 4x4 matrix (Minor, Medium, High, or Critical
Risk).
2. Build an impact assessment: Info-Tech Insight
Enable consistent measurement of impact for each change by incorporating
All changes entail an additional level of risk. Risk is a
a standardized questionnaire for each RFC.
function of impact and likelihood. Risk may be reduced,
3. Build a likelihood assessment: accepted, or neutralized through following best
Enable the consistent measurement of impact for each change by practices around training, testing, backout planning,
incorporating a standardized questionnaire for each RFC. redundancy, timing and sequencing of changes, etc.
4. Test drive your risk assessment and make necessary adjustments:

Measure your newly formed risk assessment questionnaires against
Create a risk matrix to assign a risk rating to each
RFC
Every normal RFC should be assigned a risk rating. Risk Matrix
• How is risk rating determined?

Mediu
• Priority should be based on the business consequences of implementing or denying the change. High Major Major
m
• Risk rating is assigned using the impact of the risk and likelihood/probability that the event may
occur.
Mediu
Medium Minor Major
• Who determines priority? m
IMPACT
• 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 Mediu
Low Minor Minor
than is justified. Use a repeatable, standardized framework to assess each request. m
• How is risk rating used?

• Risk rating is used to determine which changes should be discussed and assessed first. Low Medium High
• 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 LIKELIHOOD
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, Info-Tech Research Group | 44
number of people or sites affected, and severity of the impact. Impact questions tend to be more objective
Input Output
1.2.3 Build a Classification Scheme to Assess
Impact • Current risk assessment (if • Tailored impact assessment
available)
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.

Impact
Weight Question High Medium Low Materials Participants

15% # of people affected 36+ 11-35 <10
20% # of sites affected 4+ 2-3 1 • Whiteboard/flip charts (or • CIO

• Infrastructure Manager
15% Duration of recovery 180+ 30-180 < 30 remotely)
(minutes of business • Change Manager
time) • Markers/pens
Advisory Board
20% Systems affected Mission critical Important Informational
30% External customer Loss of Service None

impact customer interruption
Input Output
1.2.4 Build a Classification Scheme to Define
Likelihood • Current risk assessment (if • Tailored likelihood
available) assessment
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.

LIKELIHOOD
Weight Question High Medium Low Materials Participants
25% Has this change been tested? No Yes
10% Have all the relevant groups (companies, No Partial Yes
departments, executives) vetted the change?
• Whiteboard/flip charts (or • CIO
5% Has this change been documented? No Yes shared screen if working
15% How long is the change window? When can we Specified Per IT remotely)
implement? day/time choice • Change Manager
• Markers/pens
20% Do we have trained and experienced staff No Partial Yes
available to implement this change? If only • Change Management SOP
external consultants are available, the rating will Advisory Board
be “medium” at best.
25% Has an implementation plan been developed? No Yes

Input Output
1.2.5 Evaluate and Adjust Your Risk
Assessment Scheme • Impact and likelihood
assessments from previous
• Vetted risk assessment
two activities
1. Draw your risk matrix on a whiteboard Mediu 1
High Major Major
or flip chart. m
2. As a group, identify up to 10 examples 2 4

Medium Minor Medium Major
of requests for changes that would apply 5 3
IMPACT
within your organization. Depending on 6 Mediu 7
the number of people participating, each Low Minor Minor
8 9 m
person could identify one or two changes
and write them on sticky notes. Mediu
Low High
m
3. Take turns bringing your sticky notes up Materials Participants
to the risk matrix and placing each where # Change Example
LIKELIHOOD
it belongs, according to the assessment 1 ERP change
criteria you defined. 2 Ticket system go-live • Whiteboard/flip charts (or • CIO
3 UPS replacement shared screen if working
4. After each participant has taken a turn, • Infrastructure Manager
4 Network upgrade remotely)
discuss each change as a group and • Change Manager
5 AD upgrade • Markers/pens
adjust the placement of any changes, if
6 High availability implementation • Members of the Change
needed. Update the risk assessment • Change Management Risk A
Advisory Board
7 Key-card implementation ssessment Tool
weightings or questions, if needed.
8 Anti-virus update
Download the Change Management 9 Website
Rick Assessment Tool
Case Study
A CMDB is not a prerequisite of change management. Don’t let the INDUSTRY SOURCE
absence of a configuration management database (CMDB) prevent Manufacturing Anonymous Info-Tech member
you from implementing change management.
Challenge Solution Results

The company was planning to implement a An Excel template was set up as a stopgap As a stopgap measure, the solution worked
CMDB; however, full implementation was measure until the full implementation of the well. When changes ran the risk of
still one year away and subject to budget CMDB. The template included all identified degrading downstream dependent systems,
constraints. dependencies between systems, along with a the impacted business system owner’s
“dependency tier” for each IT service. authorization was sought and end users
Without a CMDB, it would be difficult to
were informed in advance.
understand the interdependencies between Tier 1: The dependent system would not operate
systems and therefore be able to provide if the upstream system change resulted in an The primary takeaway was that a system to
notifications to potentially affected user outage. manage configuration linkages and system
groups prior to implementing technical dependencies was key.
changes. Tier 2: The dependent system would suffer
severe degradation of performance and/or While a CMDB is ideal for this use case, IT
This could have derailed the change features. organizations shouldn’t let the lack of such
management project. a system stop progress on change
Tier 3: The dependent system would see minor management.
performance degradation or minor feature
unavailability.
Case Study (part 1 of 4)
Intel used a maturity assessment to kick-start its new INDUSTRY SOURCE
change management program. Technology Daniel Grove, Intel

Founded in 1968, the world’s largest Due to the sheer volume of change Daniel Grove, Senior Release & Change
microchip and semiconductor company management activities present at Intel, Manager at Intel, identified that
employs over 100,000 people. Intel over 35% of unscheduled outages were clarifying tasks for the Change Manager
manufactures processors for major the result of changes. and the CAB would improve process
players in the PC market including
efficiency by reducing decision lag time.
Apple, Lenovo, HP, and Dell. Ineffective change management was Roles and responsibilities were
Intel IT supports over 65,000 servers, identified as the top contributor of reworked and clarified.
3.2 petabytes of data, over 70,000 PCs, incidents with unscheduled downtime.
and 2.6 million emails per day. Intel conducted a maturity assessment of
One of the major issues highlighted was the overall change management process
Intel’s change management program is a lack of process ownership. The change to identify key areas for improvement.
responsible for over 4,000 changes each management process at Intel was very
week. fragmented, and that needed to change.

Phase 2 For running change management in
DevOps environment, see Appendix II.
This phase will guide you through the
following steps:
• Determine Roles and Responsibilities

Establish Roles and Workflows
• Build Core Workflows

Define Change Establish Roles and participants:
Management Workflows
2.1 Determine Roles and • CIO
1.1 Assess Maturity Responsibilities • IT Managers
1.2 Categorize Changes and 2.2 Build Core Workflows
Build Your Risk Assessment • Change Manager
Board
Define RFC and Post- Measure, Manage, and

Implementation Activities Maintain
3.1 Design the RFC Build the Change Calendar
3.2 Establish Post- 4.2 Implement the Project
Optimize IT Change
Management
participants:
Determine Roles and Responsibilities • CIO
• IT Managers
• Change Manager
Board
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 Outcomes of this step
• Clearly defined responsibilities to
2.1.4 Determine an E-CAB Protocol for Your Organization form the job description for a Change
Manager
• Clearly defined roles and

responsibilities for the change
management team, including the
Establish Roles and Workflows business system owner, technical
SME, and CAB members
• Defined responsibilities and authority

of the CAB
Step 2.1: Determine Roles and Responsibilities Step 2.2: Build Core Workflows
• Protocol for an emergency CAB (E-
CAB) meeting
Identify roles and responsibilities for your change
management team
Business System Owner Technical Subject Matter CAB Change Manager
Expert (SME)
• Provides downtime • Advises on proposed changes • Approves/rejects RFCs for • Reviews RFCs for
window(s) prior to RFC submission normal changes completeness
• Advises on need for change • Reviews draft RFC for • Reviews lessons learned from • Ensures RFCs brought to the
(prior to creation of RFC) technical soundness PIRs CAB have a high chance of
approval
• Validates change (through • Assesses backout/rollback • Decides on the scope of
UAT or other validation as plan change management • Chairs CAB meetings,
necessary) including scheduling, agenda
• Checks if knowledgebase has • Reviews metrics and decides
preparation, reporting, and
• Provides approval for been consulted for prior on remedial actions
follow-ups
expedited changes (needs to lessons learned
• Considers changes to be
be at executive level) • Manages post-
• Participates in the PIR, if added to list of pre-approved
implementation reviews and
necessary changes
reporting
• Ensures that the service desk • Communicates to
• Organizes internal
is trained on the change organization about upcoming
communications
Info-Tech(within IT)
Research Group | 52
changes
Input Output
2.1.1 Capture Roles and Responsibilities Using a
RACI Chart • Current SOP • Documented roles and
1. As a group, work through developing a RACI chart to determine the roles and responsibilities in change
responsibilities of individuals involved in the change management practice based management in a RACI
on the following criteria: chart
• 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.
CAB Member
Service Desk
CIO/ VP IT
Originator
Technical
Change Management Tasks
Manager
Member
Change
E-CAB
System
Owner
SME
Review the RFC C C A C R C I R • IT Managers
remotely)
Validate changes C C A C R C I R
• Change Manager
Assess test plan A C R R C I I • Sticky notes
Approve the RFC I C A R C I I • Members of the Change
• Markers/pens
Create communications plan R I A I I I Advisory Board
Deploy communications plan I I A I R • Project Summary Template
Review metrics C A R C C I
Perform a post implementation review C R A I I • Change Management SOP
Review lessons learned from PIR activities R A C I
Designate a Change Manager to own the process,
change templates, and tools
Responsibilities
The Change Manager will be the point of contact for all 1. The Change Manager is your first stop for change
process questions related to change management. approval. Both the change management and release and
deployment management processes rely on the Change
Manager to function.
• The Change Manager needs the authority to reject change requests, regardless
of the seniority of the requester. 2. Every single change that is applied to the live
environment, from a single patch to a major change,
• The Change Manager needs the authority to enforce compliance to a standard
must originate with a request for change (RFC),
process.
which is then approved by the Change Manager to
• The Change Manager needs enough cross-functional subject-matter expertise proceed to the CAB for full approval.
to accurately evaluate the impact of change from both an IT and business
perspective. 3. Change templates and tools, such as the change
calendar, list of preapproved changes, and risk
assessment template are controlled by the Change
Manager.
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 4. The Change Manager also needs to have ownership
ownership of the risk assessment and other key parts of the process. over gathering metrics and reports surrounding
deployed changes. A skilled Change Manager needs to
have an aptitude for applying metrics for continual
improvement activities. Info-Tech Research Group | 54
Input Output
2.1.2 Document Your Change
Manager’s Responsibilities • Current Change Manager
job description (if available)
• Change Manager job
description and list of
responsibilities
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 9. Assemble the Emergency CAB (E-CAB) when
emergency change requests are received.
Responsibilities
10.Approve submission of RFCs for CAB review.
1. Own the process, tools, and templates.
11.Chair the CAB: Materials Participants
2. Control the Change Management SOP.
• Set the CAB agenda and distribute it
3. Provide standard RFC forms. at least 24 hours before the meeting.
4. Distribute RFCs for CAB review. • Ensure the agenda is adhered to. • Whiteboard/flip charts (or • CIO
5. Receive all initial RFCs and check them for • Make the final approval/prioritization shared screen if working
completion. • IT Managers
decision regarding a change if the remotely)
6. Approve initial RFCs. CAB is deadlocked and cannot come • Change Manager
to an agreement. • Markers/pens
7. Approve pre-approved changes. • Members of the Change
• Distribute CAB meeting minutes to all • Info-Tech’s Change
8. Approve the conversion of normal changes to members and relevant stakeholders. Advisory Board
Manager Job Description
pre-approved changes.
Download the Change Manager Job Description
Create a Change Advisory Board (CAB) See what responsibilities in the CAB’s
process are already performed by the
to provide process governance DevOps lifecycle (e.g. authorization,
deconfliction etc.). Do not duplicate
efforts.
The primary functions of the CAB are to:
1 2 3
Protect the live environment from Prioritize changes in a way that Schedule deployments in a way that
poorly assessed, tested, and fairly reflects change impact and minimizes conflict and disruption.
implemented changes. urgency.
• CAB approval is required for all normal and • Change requests will originate from multiple • The CAB uses a change calendar populated
emergency changes. stakeholders, some of whom have competing with project work, upcoming organizational
interests. initiatives, and change freeze periods. They
• If a change results in an incident or outage,
will schedule changes around these blocks to
the CAB is effectively responsible; it’s the • It’s up to the CAB to prioritize these requests
avoid disrupting user productivity.
responsibility of the CAB to assess and effectively so that business need is balanced
accept the potential impact of every change. with any potential risk to the infrastructure. • The CAB should work closely with the
release and deployment management teams
• The CAB should seek to reduce the number
to coordinate change/release scheduling.
of emergency/expedited changes.
Use diverse representation CAB Representation Value Added
from the business to form Business

Members
•
•
•
CIO
Business Relationship Manager
Service Level Manager
•
•
Identify change blackout periods,
change impact, and business urgency.
Assess impact on fiduciary, legal,
an effective CAB • Business Analyst
•
and/or audit requirements.
Determine acceptable business risk.
The CAB needs insight into all areas of the IT Operations • Managers representing all IT • Identify dependencies and downstream
functions impacts.
business to avoid approving a high-risk Members • IT Directors • Identify possible conflicts with pre-
• Subject Matter Experts (SMEs) existing OLAs and SLAs.
change.
Based on the core responsibilities you have defined, CAB Attendees • Specific SMEs, tech specialists, • Provide detailed information and
and business and vendor reps expertise related to their particular
the CAB needs to be composed of a diverse set of relevant to a particular change subject areas.
individuals who provide quality: • Only attend meetings when • Speak to requirements, change impact,
invited by the Change Manager and cost.
• Change need assessments – identifying the value
and purpose of a proposed change.
• Change risk assessments – confirmation of the
technical impact and likelihood assessments that Info-Tech Best Practice
lead to a risk score, based on the inputs in RFC. Form a core CAB (members attend every week) and an optional CAB (members who
• Change scheduling – offer a variety of perspectives attend only when a change impacts them or when they can provide value in
and responsibilities and will be able to identify discussions about a change). This way, members can have their voice heard without
potential scheduling conflicts. spending every week in a meeting where they do not contribute.

Input Output
2.1.3 Define the Authority and Responsibilities of
Your CAB • Current SOP or CAB charter • Documented list of CAB
(if available) authorities and
1. Using the previous slide and the examples below, list the authorities and responsibilities
responsibilities of your CAB.
2. Record the responsibilities in section 3.3.2 of your Change Management SOP and
the Project Summary Template.
Example:
• CAB Authority • CAB Responsibilities
• Final authority over the deployment • Evaluate all normal and emergency
of all normal and emergency changes. Materials Participants
changes. • Verify all normal change test, backout,
• Authority to absorb the risk of a and implementation plans.
change. • Verify all normal change test results.
• Authority to set the change calendar: • Whiteboard/flip charts (or • CIO
o Maintenance windows. • Approve all normal and emergency shared screen if working
changes. • IT Managers
o Change freeze periods. remotely)
o Project work. • Prioritize all normal changes. • Change Manager
• Markers/pens
o Authority to delay changes. • Schedule all normal and emergency
changes. • Change Management SOP
Advisory Board
• Review failed change deployments. • Project Summary Template

Establish an emergency CAB (E-CAB) protocol
E-CAB members and business system owners Full documentation of the change
• When an emergency change request is received,
are provided with change details. No decision is (a retroactive RFC) is done after
you will not be able to wait until the regularly made without feedback from at least one E-CAB the change and is then reviewed by
scheduled CAB meeting. member. the CAB.
• As a group, decide who will sit on the E-CAB and

what their protocol will be when assessing and
approving emergency changes.

Members of the E-CAB should be a subset of Change owner conferences
If business continuity is being affected, the
the CAB who are typically quick to respond to with E-CAB (best efforts to
Change Manager has authority to approve
reach them) through email or
their messages, even at odd hours of the night. change.
messaging.

Input Output
2.1.4 Determine an E-CAB Protocol for Your
Organization • Current SOP or CAB charter • E-CAB protocol
(if available)
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:
Create • Whiteboard/flip charts (or • CIO
Assemble E- Assess Test (if Deploy Review With
Retroactive shared screen if working
CAB Change Applicable) Change CAB
RFC • IT Managers
remotely)
• Change Manager
• Markers/pens
Advisory Board

participants:
Build Core Workflows • CIO
• IT Managers
• Change Manager
Board
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 • Emergency change workflow
• Normal process workflow
• Pre-approved change workflow

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

Establishing Workflows: Change Management Lifecycle
• A post-implementation review assesses the

value of the actual change measured against the • A change request (RFC) can be submitted
proposed change in terms of benefits, costs, and via paper form, phone, email, or web portal.
impact.
• Results recorded in the change log. • Accountability:
Improve • Change requester/Initiator
• Accountability:
o Change Manager
o Change Implementer • The request is screened to ensure it meets
Request an agreed-upon set of business criteria.
• Approved changes are deployed. A Changes are assessed on:
rollback plan is created to mitigate risk. Implement o Impact of change
o Risks or interdependencies
• Accountability: o Resourcing and costs
o Change Manager
o Change Implementer • Accountability:
Assess o Change Manager
• Approved requests are sent to the most

efficient channel based on risk, urgency, Approve • Tasks are assigned, planned, and executed.
and complexity. • Change schedule is consulted and necessary
resources are identified.
• Change is sent to CAB members for final
review and approval
Plan
• Accountability:
• Accountability: o Change Manager
o Change Manager
o Change Advisory Board
Establishing workflows: employ a SIPOC
model for process definition Optional Fields
A good SIPOC (supplier, input, process, output, customer) model helps establish the
Metrics
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 • Top-level indicators that usually relate to
workflow diagram. the input and output, e.g. turnaround time,
For change management, employ a SIPOC model to outline your CAB process: risk matrix completeness.
• Who or what organization provides the inputs to the Controls

Supplier process? The supplier can be internal or external.
• Checkpoints to ensure process step quality.
• What goes into the process step? This can be a
Input document, data, information, or a decision. Dependencies
• Activities that occur in the process step that’s being • Other process steps that require the output.
Process analyzed.
RACI
• What does the process step produce? This can be a
Output document, data, information, or a decision. • Those who are Responsible, Accountable,
Consulted, or Informed (RACI) about the
Custome • Who or what organization(s) takes the output of the input, output, and/or process.
r process? The customer can be internal or external.
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:
Identify all Frame the change from Each new change can Once risk has been
Business Impact
SLA Impact
Required Resources
Dependencies
components of the a business point of impact the level of assessed, resources

change. view to identify service available. need to be identified to
Ask how changes will potential disruptions to Examine the impact ensure the change can
affect: business activities. on: be executed.
• Services on the same Your assessment • Availability of critical These include:
infrastructure? should cover: systems • People (SMEs, tech
• Applications? • Business processes • Infrastructure and app support, work
• Infrastructure/app • User productivity performance effort/duration)
architecture? • Customer service • Infrastructure and app • System time for
• Security? capacity scheduled implementation
• BCPs
• Ability to support critical • Existing disaster recovery • Hardware or software
systems? plans and procedures (new or existing, as well
as tools)

Establishing workflows: pinpoint Services Impacted
dependencies to identify the need for • Have affected services been identified?
additional changes • Have supporting services been identified?
An assessment of each change and a query of the CMDB • Has someone checked the CMDB to ensure all
needs to be performed as part of the change planning process dependencies have been accounted for?
to mitigate outage risk. • Have we referenced the service catalog so the
business approves what they’re authorizing?
• 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 Technical Teams Impacted
the database be upgraded or modified. • Who will support the change throughout testing and
implementation?
• The sequence of the release must also be determined, as certain
components may need to be upgraded before others. For example, • Will additional support be needed?
if you upgrade the Exchange Server, a Windows update must be • Do we need outside support from eternal suppliers?
installed prior to the Exchange upgrade.
• Has someone checked the contract to ensure any
• If you do not have a CMDB, consider building a CMDB-lite, additional costs have been approved?
which consists of a listing of systems, primary users, SMEs,
business owners, and system dependencies (see next slide).
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 necessary to build and implement it successfully.
o To build a CMDB-lite, start with the top 10 systems in your • Tier 1 Dependency
environment that experience changes. This list can always be
o If the primary system experiences and outage, Tier 1 dependency
populated iteratively.
functionality is also lost. To request a change, include the business
• Primary Users system owner signoffs of the Tier 1 dependencies of the primary
o Listing the primary users will give a change requester a first glance at system.
the impact of the change. • Tier 2 Dependency
o You can also use this information when looking at the change o If the primary system experiences an outage, Tier 2 dependency
communication and training after the change is implemented. functionality is lost, but there is an available workaround.
• SME/Backup o As with Tier 1, this information can help you build a backout plan in
o These are the staff that will likely build and implement the change. case there is a change-related collision.
The backup is listed in case the primary is on holiday. • Tier 3 Dependency
• Business System Owner o Tier 3 functionality is not lost if the primary system experiences an
o The owner of the system is one of the people needed to sign off on the outage, but nice-to-haves such as aesthetics are affected.
change. Having their support from the beginning of a change is
Input Output
2.2.1 Build a CMDB-lite as a Reference for
Requested Changes • Current system ownership • Documented reference for
documentation change requests (CMDB-
1. Start with a list of your top 10-15 systems/services with the highest volume of changes. lite)
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.
System Primary SME Backup Business Tier 1 Tier 2 Tier 3
Users SME(s) System Dependency (impaired Dependenc
Owner (system functionality/ y (nice to
functionalit workaround have)
y is down) available)
Email Enterprise Naomi Amos James • ITSMs -Lots

• Scan-to-
email
• Reporting
Conferencin Enterprise Alex Shed James • Videoconf • Conference -IM • Whiteboard/flip charts (or • CIO
g Tool erencing rooms (can shared screen if working
use • IT Managers
Facebook remotely)
messenger • Change Manager
instead in • Sticky notes
worst case • Members of the Change
scenario) • Markers/pens
Advisory Board
ITSM Enterprise Anderson TBD Mike • Work • Dashboards
(Service (Intl.) orders • Purchasing
Now)
ITSM North Bobbie Joseph Mike • Work • Dashboards
(Manage America orders • Purchasing
Engine)
Establishing workflows: create standards for change
approvals to improve efficiency
Example:
• Not all changes are created equal, and not all
changes require the same degree of approval. As Change Category Change Authority
part of the change management process, it’s
important to define who is the authority for each Pre-approved change Department head/manager
type of change.
• Failure to do so can create bureaucratic Emergency change E-CAB
bottlenecks if each change is held to an
unnecessary high level of scrutiny, or unplanned
outages may occur due to changes circumventing Normal change – low and CAB
medium risk
the formal approval process.
• A balance must be met and defined to ensure the
process
Info-TechisBest
not Practice
bypassed or bottlenecked. Normal change – high risk CAB and CIO (for visibility)
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 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 For the full process, refer to the Change
automated. Responsibilities such as deconfliction, dependency identification, calendar Management Process Library.
query, and authorization identification can be done early in the lifecycle to decrease or
eliminate the burden on CAB.
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. Info-Tech Research Group | 70
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).

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.

Management Process Library.
Input Output
2.2.2 Create a Normal Change Process
• Current SOP/workflow • Normal change process
library
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:
a) Request
b) Assessment
c) Plan
d) Approve Materials Participants
e) Implementation and Post-Implementation Activities
3. Optionally, you may create variations of the workflow for minor, • Whiteboard/flip charts (or • CIO
medium, and major changes (e.g. there will be fewer authorizations for shared screen if working
• IT Managers
minor changes). remotely)
• Change Manager
• Pens/markers
4. For further documentation, you may choose to run the
SIPOC activity for your CAB as outlined on this slide. • Sticky notes
Advisory Board
• Change Management Proce
5. Document the resulting workflows in the ss Library
Change Management Process Library and section 11 of your
Download the Change Management Process • Change Management SOP
Change Management SOP. Library. Info-Tech Research Group | 73
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: Pre-approved changes are not exempt from due diligence:
• Once your change management process is firmly established, hold a • Once a change is designated as pre-approved, the deployment team should
meeting with all staff that make change requests and build changes. create and compile all relevant documentation:
• An RFC detailing the change, dependencies, risk, and impact.
• Run a training session detailing the traits of pre-approved changes and
ask these individuals to identify changes that might qualify. • Detailed procedures and required resources.
• Implementation and backout plan.
• These changes should be submitted to the Change Manager and
reviewed, with the help of the CAB, to decide whether or not they • Test results.
qualify for pre-approval. • 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.
At the beginning of a change management process, there should be
few active pre-approved changes. However, prior to launch, you • Pre-approved changes must still be documented and recorded in the
may have IT flag changes for conversion. CMDB and change log after each deployment.
Example process: Pre-Approved Change Process


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. Seek new pre-
approved change
submissions.
• 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 Re-evaluate the
repeatable, and that the documentation is up to date. pre-approved
change list
• If dependencies have changed, then move the change back to the
every 4-6
normal category for reassessment. It may be redesignated as a pre-
months.
approved change once the documentation is updated.

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.
Input Output
2.2.3 Create a Pre-Approved Change Process
• Current SOP/workflow • Pre-approved change
library process

to determine the workflow for a pre-approved change, with particular
attention to the following sub-processes:
a) Request
b) Assessment
c) Plan
d) 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 shared screen if working
RFC template. • IT Managers
remotely)
• Change Manager
• Pens/markers
4. Document the resulting workflows in the
Change Management Process Library and sections 4.2 and 13 of your • Sticky notes
Advisory Board
Change Management SOP. • Change Management Proce
ss Library

Reserve the emergency designation for real emergencies
• Emergency changes have one of the following triggers: Sample Change Quick Check Emergency?
o A critical incident is impacting user productivity.
Are the patches
o An imminent critical incident will impact user productivity. Install the latest critical
required to resolve or
patches from the No
prevent an imminent
• Unless a critical incident is being resolved or prevented, the change should be vendor.
critical incident?
categorized as normal.
• An emergency change differs from a normal change in the following key aspects: A virus or worm Is the patch required to
o An emergency change is required to recover from a major outage – there invades the network resolve or prevent an
Yes
and a patch is needed imminent critical
must be a validated service desk critical incident ticket. An urgent business to eliminate the threat. incident?
requirement is not an “emergency.”
o An RFC is created after the change is implemented and the outage is over.
o A review by the full CAB occurs after the change is implemented.
o The first responder and/or the person implementing the change may not be Info-Tech Best Practice
the subject matter expert for that system. Change requesters should be made aware that senior
management will be informed if an emergency RFC
• In all cases, an RFC must be created and the change must be reviewed by the full
is submitted inappropriately. Emergency requests
CAB. The review should occur within two business days of the event. 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:
o 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?
o Documentation and
communication to stakeholders
and CAB after the emergency
change is completed.
o Input from incident
management.
For all processes, refer to the Change
Input Output
2.2.4 Create an Emergency Change Process
• Current SOP/workflow • Emergency change process
library

to determine the workflow for an emergency change, with particular
attention to the following sub-processes:
a) Request
b) Assessment
c) Plan
d) Approve
3. Ensure that the E-CAB protocol from activity 2.1.4 is considered when
building your process. • Whiteboard/flip charts (or • CIO
• IT Managers
remotely)
4. Document the resulting workflows in the
• Change Manager
Change Management Process Library and section 12 of your • Pens/markers
Change Management SOP. • Sticky notes
Advisory Board
• Change Management Proce
ss Library

Intel implemented a robust change management process. INDUSTRY SOURCE

Founded in 1968, the world’s largest Intel identified 37 different change Once process ownership was assigned
microchip and semiconductor company processes and 25 change management and the role of the Change Manager and
employs over 100,000 people. Intel systems of record with little integration. CAB clarified, it was a simple task to
manufactures processors for major streamline and simplify processes
players in the PC market including Software and infrastructure groups were among groups.
Apple, Lenovo, HP, and Dell. also very siloed, and this no doubt
Intel IT supports over 65,000 servers, contributed to the high number of Intel designed a new, unified change
3.2 petabytes of data, over 70,000 PCs, changes that caused outages. management workflow that all groups
and 2.6 million emails per day. would adopt.
The task was simple: standards needed
Intel’s change management program is to be put in place and communication Automation was also brought into play
responsible for over 4,000 changes each had to improve. to improve how RFCs were generated
week. and submitted.

Phase 3 This phase will guide you through the
following activities:
• Design the RFC

Define the RFC and Post-Implementation Activities
• Establish Post-Implementation
Activities

Define Change participants:
Establish Roles and
Management • IT Director
Workflows
2.1 Determine Roles and
1.1 Assess Maturity • Infrastructure Manager
Responsibilities
1.2 Categorize Changes and
2.2 Build Core Workflows • Change Manager
Build Your Risk Assessment
Board
Measure, Manage, and

Define the RFC and Post-
Maintain
3.1 Design the RFC Build the Change Calendar Optimize IT Change
3.2 Establish Post- 4.2 Implement the Project Management

participants:
Design the RFC • CIO
• IT Managers
• Change Manager
Board
3.1.1 Evaluate Your Existing RFC Process
3.1.2 Build the RFC Form

Define the RFC and Post-Implementation Activities • A full RFC template and process that
compliments the workflows for the
three change categories
Step 3.2: Establish Post-Implementation
Step 3.1: Design the RFC
Activities

A request for change (RFC) should be submitted for
every non-standard change
RFCs should contain the following information,
An RFC should be submitted through the formal change management practice for every
at a minimum:
change that is not a standard, pre-approved change (a change which does not require
1. Contact information for requester
submission to the change management practice).
2. Description of change
• The RFC should contain all the information required to approve a change. Some 3. References to external documentation
information will be recorded when the change request is first initiated, but not
4. Items to be changed, reason for the change, and impact of both
everything will be known at that time.
implementing and not implementing the change
• Further information can be added as the change progresses through its lifecycle.
5. Change type and category
• 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. 6. Priority and risk assessment
• Other details of the change may be recorded in other documents and referenced in the 7. Predicted time frame, resources, and cost
RFC.
8. Backout or remediation plan
Info-Tech Insight
9. Proposed approvers
Keep the RFC form simple, especially when first implementing change
management, to encourage the adoption of and compliance with the 10. Scheduled implementation time
process.
11.Communications plan and post-implementation review

Input Output
3.1.1 Evaluate Your Existing RFC

Process
• Current RFC form or stock • List of changes to the
ITSM RFC current RFC form and RFC
process
• Current SOP (if available)
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. Materials Participants
3. As a group, finalize an RFC table of contents that will be used to formalize a new or improved
RFC.
• Whiteboard/flip charts (or • IT Director
4. Decide which fields should be filled out by the requester before the initial RFC is submitted to shared screen if working
the Change Manager: remotely)
• • Change Manager
Many sections of the RFC are relevant for change assessment and review. What • Projector
information does the Change Manager need when they first receive a request? • Members of the Change
• Markers/pens
• The Change Manager needs enough information to ensure that the change is in scope Advisory Board
• Laptop with ITSM admin
and has been properly categorized.
access
5. Decide how the RFC form should be submitted and reviewed; this can be documented in • Request for Change Form T
section 5 of your Change Management SOP. emplate
Download the Request for Change Form Template • Change Management SOP
Design the RFC to encourage
 Change requester
process buy-in 

Requested date of deployment
Change risk: low/medium/high
• When building the RFC, split the form up into sections that follow the  Risk assessment
normal workflow (e.g. Intake, Assessment and Build, Approval,  Description of change
Implementation/PIR). This way the form walks the requester through  Reason for change
what needs to be filled and when.  Change components
• Revisit the form periodically and solicit feedback to continually improve  Assess change:
• Dependencies
the user experience. If there’s information missing on the RFC that the • Business impact
CAB would like to know, add the fields. If there are sections that are not • SLA impact
used or not needed for documentation, remove them. • Required resources
• Query the CMS
• Make sure the user experience surrounding your RFC form is a top  Plan and test changes:
priority – make it accessible, otherwise change requesters simply will not • Test plan
• Test results
use it. • Implementation plan
• Backout plan
• Take advantage of your ITSM’s dropdown lists, automated notifications,
• Backout plan test results
CMDB integrations, and auto-generated fields to ease the process of
filling the RFC  Approve and schedule changes:
Legend • Final CAB review
• Communications plan
Draft CAB
 Deploy changes:
• Post-implementation review
Technical Build Complete

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.
 Change requester
• A requested date of deployment gives approvers information  Requested date of deployment
 Change Risk: low/medium/high
on timeline and can be used to query the change calendar for
 Risk assessment
possible conflicts  Description of change
 Reason for change
• Information about risk assessment based on impact and
 Change components
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 Use the RFC to point to documentation
already gathered in the DevOps lifecycle to
to the proper workflow and resourcing is assessed, the
cut down on unnecessary manual work
description, reason, and change components are high-level while maintaining compliance.
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). Info-Tech Research Group | 87
Designing your RFC: technical
build
• Dependencies and CMDB query, along with the proposed

 Assess change:
implementation date, are included to aid in calendar • Dependencies
deconfliction and change scheduling. If there’s a conflict, it’s • Business impact
• SLA impact
easier to reschedule the proposed change early in the lifecycle. • Required resources
• Query the CMS
• Business, SLA impact, and required resources can be tracked  Plan and test changes:
to provide the CAB with information on the business resources • Test plan
• Test results
required. This can also be used to prioritize the change if • Implementation plan
conflicts arise. • Backout plan
• Backout plan test results
• 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.

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.
 Approve and schedule changes:
• Communications plans for appropriate stakeholders can also be • Final CAB review
modified and forwarded to the communications team (e.g. • Communications plan
service desk or business system owners) before deployment.  Deploy changes:
• Post-implementation review
• 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.

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

Input Output
3.1.2 Build the RFC Form • Current RFC form or stock • List of changes to the
ITSM RFC current RFC and RFC
process
1. Use Info-Tech’s Request for Change Form Template as a basis for your RFC form. • Current SOP (if available)
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.

remotely)
• Change Manager
• Projector
• Markers/pens
Advisory Board
access
• Request for Change Form T

emplate
Intel implemented automated RFC form generation. INDUSTRY SOURCE

Founded in 1968, the world’s largest One of the crucial factors that was Intel designed and implemented an
microchip and semiconductor company impacting Intel’s change management automated RFC form generator to
employs over 100,000 people. Intel efficiency was a cumbersome RFC encourage end users to increase RFC
manufactures processors for major process. usage.
Apple, Lenovo, HP, and Dell. A lack of RFC usage was contributing to As we’ve seen with RFC form design, the
Intel IT supports over 65,000 servers, increased ad hoc changes being put UX/UI of the form needs to be top notch,
3.2 petabytes of data, over 70,000 PCs, through the CAB, and rescheduled otherwise end users will simply
and 2.6 million emails per day. changes were quite high. circumvent the process. This will
contribute to the problems you are seeking
Intel’s change management program is Additionally, ad hoc changes were also to correct.
responsible for over 4,000 changes each contributing heavily to unscheduled
week. downtime within the organization. Thanks to increased RFC usage, Intel
decreased emergency changes by 50% and
reduced change-caused unscheduled
downtime by 82%.
participants:
Establish Post-Implementation Activities • CIO
• IT Managers
• Change Manager
Board
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 • A formalized post-implementation
process for continual improvement
Step 3.2: Establish Post-Implementation

Step 3.1: Design RFC
Activities

Why would the CAB reject a change that
has been properly assessed and tested?
Sample RFC Reason for CAB
rejection
Possible reasons the CAB would reject a change include: There was a request for an The CAB rejects it due to the
• The product being changed is approaching its end of life. update to a system that a downstream impact.
legacy application depends on
• The change is too costly. and only a specific area of the
• The timing of the change conflicts with other changes. business was aware of the
dependency.
• There could be compliance issues.
• The change is actually a project. There was a request for an It’s too expensive to
update to a non-supported implement, despite the need
• The risk is too high. application, and the vendor for it. The CAB will wait for
• There could be regulatory issues. was asking for a premium an upgrade to a new
support contract that is very application.
• The peripherals (test, backout, communication, and training plans) costly.
are incomplete.
There was a request to update The risk outweighs the
application functionality to a business benefits.
Info-Tech Best Practice beta release.
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. Info-Tech Research Group | 94
Input Output
Determine When the CAB Would Reject
Tested Changes • Current SOP (if available) • List of reasons to reject
tested changes
1. Understand that once a change reaches the CAB, it has already been
assessed, planned for, and tested (where possible).
2. The change manager should not be submitting RFCs with inadequate
assessments to the CAB, so we can assume that these RFCs are complete.
However, the CAB might still reject the request.
3. As a group, discuss possible reasons why the CAB would reject a change Materials Participants
request and document these on the whiteboard.
4. Document several sample RFCs on the whiteboard that the group feels
should be rejected and note the reasons for rejection. shared screen if working
remotely)
5. Document the next steps after a rejection, e.g. consult with SME to • Change Manager
• Projector
rebuild or rework the change. • Members of the Change
• Markers/pens
Advisory Board
6. Capture the results of the discussion in your Project Summary Template.
access
• Project Summary Template

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.
 Deployment resources identified, allocated, and
scheduled
1 2
 Documentation complete 1. Verification – once the change has been
 Support team trained implemented, verify that all requirements
are fulfilled.
 Users trained
 Business sign-off
2. Review – ensure that all affected systems
and applications are operating as predicted.
 Target systems identified and ready to receive
changes 3. Update change log.
Implement
 Target systems available for installation  Change 4. Transition – a crucial phase of
maintenance window scheduled implementation that’s often overlooked.
 Technical Checks: Once the change implementation is
complete from a technical point of view, it’s
 Disk space available
imperative that the team involved with the
 Pre-requisites met change inform and train the group
 Components/Services to be updated are responsible for managing the new change.
stopped
 All users disconnected
Download Info-Tech’s Change Management Pre-

Implementation Checklist
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

Notify the Disable Conduct Enable User Notify the
that need to be taken to restore the live environment Service Access Checks Access Service
back to its previous state and maintain business Desk • Disable • Conduct • Enable user Desk
continuity. A good backout plan asks the following • Notify the user access checks to access to • Notify the
Service to affected all affected affected service
questions: Desk about system(s). component systems. desk that
backout s. the backout
plan plan was
1. How will failure be determined? Who will make initiation. successful.
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? Info-Tech Best Practice
3. Is the service desk aware of the impending
As part of the backout plan, consider the turnback point in the change window.
change? Do they have proper training? That is, the point within the change window where you still have time to fully
back out of the change.

Ensure the following Update the service catalog with new information as a result
Service Catalog
post-implementation of the implemented change.
review activities are

completed 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 Update your technical documentation to reflect the changes

Documentation present because of the new change.
Training Update your training documentation to reflect any

Documentation 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 1. Why do a post-implementation review?
change management activity. • Changes that don’t fail but don’t perform well are
rarely reviewed.
• All changes should be reviewed to understand the reason behind them, • Changes may fail subtly and still need review.
appropriateness, and recommendations for next steps. • Changes that cause serious failures (i.e. unplanned
• The Change Manager manages the completion of information PIRs and downtime) receive analysis that is unnecessarily in-
invites RFC originators to present their findings and document the lessons depth.
learned.
2. What are the benefits?
• A proactive, post-implementation review actually uses
less resources than reactionary change reviews.
Info-Tech Best Practice • Root-cause analysis of failed changes, no matter what
the impact.
Review PIR reports at CAB meetings to highlight the root causes of issues, action
• Insight into changes that took longer than projected.
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 • Identification of previously unidentified risks affecting
issues in the future. 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.
Frequency Part of weekly review (IT team meeting)
Participants •
•
Change Manager
Originator
• SME/supervisor/impacted team(s)
Categories under Current deviations and action items from previous PIR:
• Complete
review • Partially complete
• Complete, late
• Change failed, rollback succeeded
• Change failed, rollback failed
• Major deviation from implementation plan
Output •
•
Root cause or failure or deviation
External factors
• Remediation focus areas
• Remediation timeline (follow-up at appropriate time)
Controls •
•
Reviewed at next CAB meeting
RFC close is dependent on completion of PIR
• Share with the rest of the technical team
• Lessons learned stored in the knowledgebase and attached to RFC for easy search of past issues.

Input Output
3.2.2 Create a Post-Implementation Activity
Checklist • Current SOP (if available) • List of reasons to reject
tested changes
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 Materials Participants
 Incorrect SLA impact
 Inaccurate resources
 Time
 Staff • Whiteboard/flip charts (or • CIO
 Hardware shared screen if working
 System testing • IT Managers
remotely)
 Integration testing
• Change Manager
 User acceptance testing • Projector
 No backout plan • Members of the Change
 Backout plan failure • Markers/pens
Advisory Board
 Deployment issues
access
3. Record your results in the Change Management Post-Implementation Checklist.
• Change Management Post-I
Download the Change Management Post- mplementation Checklist Info-Tech Research Group | 101
Implementation Checklist
Case Study
Microsoft used post-implementation review INDUSTRY
Technology
SOURCE
Jason Zander, Microsoft
activities to mitigate the risk of a critical Azure
outage.

In November 2014, Microsoft deployed Before the software was deployed, Thankfully, Microsoft had a backout plan.
a change intended to improve Azure Microsoft engineers followed proper Within 30 minutes, the change was rolled
storage performance by reducing CPU protocol by testing the proposed update. back on a global scale.
footprint of the Azure Table Front-Ends. All test results pointed to a successful
implementation. It was determined that policy enforcement
The deployment method was an was not integrated across the deployment
incremental approach called “flighting,” Unfortunately, engineers pushed the system. An update to the system shifted
where software and configuration change out to the entire infrastructure the process of policy enforcement from
deployments are deployed incrementally instead of adhering to the traditional human-based decisions and protocol to
to Azure infrastructure in small batches. flighting protocol. automation via the deployment platform.
Unfortunately, this software deployment Additionally, the configuration switch was Defined PIR activities enabled Microsoft
caused a service interruption in multiple incorrectly enabled for the Azure Blob to take swift action against the outage and
regions. storage Front-Ends. mitigate the risk of a serious outage.
A combination of the two mistakes

exposed a bug that caused the outage. Info-Tech Research Group | 102
Phase 4
This phase will guide you through the
following activities:
• Identify Metrics and Build the Change

Measure, Manage, and Maintain Calendar
• Implement the Project

participants:
Define Change Establish Roles and • CIO/IT Director
Management Workflows • IT Managers
1.1 Assess Maturity 2.1 Determine Roles and
• Change Manager
1.2 Categorize Changes and Responsibilities
Build Risk Assessment 2.2 Build Core Workflows
Define RFC and Post- Measure, Manage, and

Implementation Activities Maintain
3.1 Design RFC 4.1 Identify Metrics and

3.2 Establish post- Build the Change Calendar
implementation activities 4.2 Implement the Project
Optimize IT Change
Management
participants:
• CIO/IT Director
Identify Metrics and Build the Change Calendar
• IT Managers
• Change Manager
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

• Clear definitions of change calendar
content
Measure, Manage, and Maintain • Guidelines for change calendar
scheduling
• Defined metrics to measure the

Step 4.1: Identify Metrics and Build the Change
Step 4.2: Implement the Project success of change management with
Calendar associated reports, KPIs, and CSFs

“The one who has more clout or
Enforce a standard method of prioritizing and authority is usually the one who gets
scheduling changes changes scheduled in the time frame
they desire, but you should really be
The impact of not deploying the change and the benefit of deploying evaluating the impact to the
it should determine its priority. 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
Positive Impact of change.”
Risk of Not Deploying Deployment
– Joseph Sgandurra, Director, Service Delivery,
• What is the urgency of the change? • What benefits will be realized once the change Navantis
• What is the risk to the organization if the is deployed?
change is not deployed right away? • How significant is the opportunity that triggered
Info-Tech Insight
• Will there be any lost productivity, service the change?
disruptions, or missed critical business • Will the change lead to a positive business Avoid a culture where powerful
opportunities? outcome (e.g. increased sales)? stakeholders are able to push change
deployment on an ad hoc basis. Give
the CAB the full authority to make
Timing
Once prioritized, a final deployment
approval decisions based on
• Does the proposed timing work urgency, impact, cost, and
date should be set by the CAB. Check
with the approved changes already
the change calendar first to avoid availability of resources.
on the change schedule?
conflicts.
• Has the change been clash
checked so there are no potential
conflicts over services or
resources?
Develop a change schedule to formalize the
planning process
A change calendar will help the CAB schedule changes more effectively and increase “Our mantra is to put it on
visibility into upcoming changes across the organization.
the calendar. Even if it’s a
preapproved change and doesn’t
1. Establish change windows in a consistent change schedule: need a vote, having it on the
• Compile a list of business units that would benefit from a change.
• Look for conflicts in the change schedule. calendar helps with visibility.
• Avoid scheduling two or more major business units in a day. The calendar is the one-stop
• Consider clients when building your change windows and change
schedule. shop for scheduling and
identifying change
2. Gain commitments from key participants:
• These individuals can confirm if there are any unusual or cyclical dependencies.“
business requirements that will impact the schedule.
– Wil Clark, Director of Service and
3. Properly control your change calendar to improve change Performance Management, University of
efficiency: North Texas Systems
• 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 Info-Tech Research Group | 106
implementing changes so you only need to set up calendar freezes for

Provide clear definitions of what goes on the change
calendar and who’s responsible
Roles Inputs
• The Change Manager will be • Freeze periods for individual business departments/applications
responsible for creating and (e.g. finance month-end periods, HR payroll cycle, etc. – all to be
maintaining a change calendar. investigated).
• Only the Change Manager can • Maintenance windows and planned outage periods.
physically alter the calendar by • Project schedules, and upcoming major/medium changes.
adding a new change after the • Holidays.
CAB has agreed upon a • Business hours (some departments work 9-5, others work different
deployment date. hours or in different time zones, and user acceptance testing may
• All other CAB members, IT require business users to be available).
support staff, and other impacted
stakeholders should have access to Guidelines
the calendar on a read-only basis to
prevent people from making • Business-defined freeze periods are the top priority.
unauthorized changes to • No major or medium normal changes should occur during the week
deployment dates. 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.
The change calendar is a critical pre-requisite to change management in • Minor changes and preapproved changes have the same priority and
DevOps. Use the calendar to be proactive with proposed implementation dates will be decided on a case-by-case basis.
and deconfliction before the change is finished.
Input Output
4.1.1 Create Guidelines for Your Change
Calendar • Current change calendar
guidelines
• Change calendar inputs and
schedule checklist
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. Materials Participants
2. Create a checklist to run through before each change is scheduled:
Check the schedule and assess resource availability: • Whiteboard/flip charts (or • Change Manager
 Will user productivity be impacted? shared screen if working
 Are there available resources (people and systems) to • Members of the Change
remotely)
implement the change? Advisory Board
 Is the vendor available? Is there a significant cost attached to • Projector
• Service Desk Manager
pushing change deployment before the regularly scheduled
• Markers/pens
refresh? • Operations (optional)
 Are there dependencies? Does the deployment of one change • Project Summary Template
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 Percentage of emergency changes

• Each month, compare the number of emergency change requests to the total
month number of change requests.
• Each month, record the number of incidents that can be • Change requesters often designate changes as emergencies as a way of
directly linked to a change. This can be done using an bypassing the process.
ITSM tool or manually by service desk staff. • A reduction in emergency changes demonstrates that your process is
operating smoothly and reduces the risk of deploying changes that have not
• This is a key success metric: if you are not tracking
been properly tested.
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 Info-Tech Insight
impacts users directly.
Start simple. Metrics can be difficult to
Number of unauthorized changes tackle if you’re starting from scratch. While
applied each month implementing your change management
• Each month, record the number of practice, use these three metrics as a starting
changes applied without approval. point, since they correlate well with the
This is the best way to measure
adherence to the process. success of change management overall. The
• If this number decreases, it following few slides provide more insight
demonstrates a reduction in risk, as into creating metrics for your change
more changes are formally assessed process.
and approved before being deployed.

If you want more insight into your change process, measure the progress of each
step in change management with metrics
• What percentage of change requests have errors
• Number of repeat failures (i.e. making the or lack appropriate support?
same mistake twice) • What percentage of change requests are actually
• Number of changes converted to pre-approved projects, service requests, or operational tasks?
• Number of changes converted from pre-
approved back to normal
Improve • What percentage of changes have been requested
before (i.e. documented)?
Request
• Number of changes completed on schedule

Implement • What percentage of change requests are out of
scope?
• Number of changes rolled back • What percentage of changes have been requested
• What percentage of changes caused an before (i.e. documented)?
incident? • What are the percentages of changes by category
Assess (normal, pre-approved, emergency)?
Approve
• Number of changes broken down by department What percentage of change requests are reviewed
(business unit/IT department to be used in by the CAB that should have been pre-approved or
making core/optional CAB membership more Plan emergency (i.e. what percentage of changes are in
efficient) the wrong category)?
• Number of workflows that can be automated

Use metrics to inform project
KPIs and CSFs
Metrics are easily measured
Leverage the metrics from the last slide and convert datapoints that can be pulled
from your change
them to data communicable to IT, management, and management tool.
Examples: Number of
leadership changes implemented,
Metrics number of changes without
incident.
• To provide value, metrics and measurements must be actionable. What
actions can be taken as a result of the data being presented?
Key Performance Indicators are
• If the metrics are not actionable, there is no value and you should question metrics presented in a way that is
the use of the metric. KPIs easily digestible by stakeholders in IT.
Examples: Change efficiency, quality
• Data points in isolation are mostly meaningless to inform action. Observe of changes.
trends in your metrics to inform your decisions.
Critical Success Factors are measures of
• Using a framework to develop measurements and metrics provides a the business success of change management
defined methodology that enables a mapping of base measurements CSFs taken by correlating the CSF with multiple
through CSFs. KPIs.
Examples: consistent and efficient change
• Establishing the relationship increases the value that measurements management process, a change process
mapped to business needs
provide.
Purposely use SDLC and change lifecycle metrics to find
bottlenecks and automation candidates.
List in-scope metrics and reports and align them to benefits
Metric/Report (by team) Benefit

Total number of RFCs and percentages by category (pre-approved, normal, • Understand change management activity
emergency, escalated support, expedited) • Tracking maturity growth
• Identifying “hot spots”
Pre-approved change list (and additions/removals from the list) Workload and process streamlining (i.e. reduce “red tape” wherever possible)
Average time between RFC lifecycle stages (by service/application) Advance planning for proposed changes
Number of changes by service/application/hardware class • Identifying weaknesses in the architecture

• Vendor-specific TCO calculations
Change triggers Business- vs. IT-initiated change
Number of RFCs by lifecycle stage Workload planning
List of incidents related to changes Visible failures of the CM process
Percentage of RFCs with a tested backout/validation plan Completeness of change planning
List of expedited changes Spotlighting poor planning and reducing the need for this category going
forward (“The Hall of Shame”)
CAB approval rate Change coordinator alignment with CAB priorities – low approval rate
indicates need to tighten gatekeeping by the change coordinator
Calendar of changes Planning

4.1.2 Determine Metrics, Key Performance Indicators Input Output
(KPIs), and Critical Success Factors (CSFs)
• Current metrics • List of trackable metrics,
1. Draw three tables for metrics, KPIs, and CSFs. 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
Ref#and owner and record in the RACI and Communications
Metric Ref# section of your
KPIChange Management SOP.
Product
Successful changes for a period of time
K1 M2 / M1 x 100%
(approach 100%)
M1
Number of changes implemented for a K2 Changes causing incidents (approach 0%) M3 / M1 x 100% Materials Participants
time period
K3 Average days to implement a change ΣM5 / M1
Number of changes successfully [1 - (M6 / M1)] x
M2 K4 Change efficiency (approach 100%)
implemented for a time period 100%
Quality of changes being implemented [1 - (M4 / M1)] x • Whiteboard/flip charts (or • Change Manager
K5
Number of changes implemented (approach 100%) 100% shared screen if working
M3
causing incidents [1 - (M7 / M1)] x • Members of the Change
K6 Change training efficiency (approach 100%) remotely)
100% Advisory Board
Number of accepted known errors • Markers/pens
M4
when change is implemented
Ref# CSF Indicator • Service Desk Manager
Successful change management process • Change Management SOP
C1 K1, K5
Total days for a change build (specific producing quality changes • Operations (optional)
M5 C2 Consistent efficient change process K4, K6
to each change)
M6 Number of changes rescheduled C3 Change process maps to business needs K5, K6
Number of training questions received

M7 Info-Tech Research Group | 113
following a change
Measure changes in selected metrics to
evaluate success Outcomes of standardizing change
management should include:
Once you have implemented a standardized change
management practice, your team’s goal should be to improve
the process, year over year. 1. Improved efficiency, effectiveness, and
quality of changes.
• After a process change has been implemented, it’s important to regularly
monitor and evaluate the CSFs, KPIs, and metrics you chose to evaluate.
2. Changes and processes are more aligned
Examine whether the process change you implemented has actually resolved the with the business needs and strategy.
issue or achieved the goal of the critical success factor. 3. Improved maturity of change processes.
• 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 Info-Tech Best Practice
management process once an appropriate amount of time has passed.
Make sure you’re measuring the right things and considering all
• Ensure that metrics are telling the whole story and that reporting is honest in order to sources of information. It’s very easy to put yourself in a
be informative. position where you’re congratulating yourselves for improving
on a specific metric such as number of releases per month, but
satisfaction remains low.

Input Output
4.1.3 Track and Record Metrics Using the Change
Management Metrics Tool • Current metrics • List of trackable metrics,
KPIs and CSFs to be
Tracking the progress of metrics is paramount to the success of any change management process. Use observed over the length of
Info-Tech’s Change Management Metrics Tool to record metrics and track your progress. This tool is a year
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.
• Whiteboard/flip charts (or • Change Manager

remotely)
Advisory Board
• Markers/pens
• Change Management Metric
s Tool • Operations (optional)
Download the Change Management

Metrics Tool Info-Tech Research Group | 115
Case Study
A federal credit union was able to track maturity growth
through the proper use of metrics. INDUSTRY
Federal Credit Union

SOURCE
Info-Tech Workshop
(anonymous)

At this federal credit union, the VP of IT wanted Stakeholders were provided with an The business received clear guidance regarding
a tight set of metrics to engage with the overview of change management benefits estimated times to implement changes across
business, communicate within IT, enable and were asked to identify one key attribute different elements of the environment.
performance management of staff, and provide that would be useful to their specific needs.
visibility into workload demands, among other The IT managers were able to plan team
requirements. Metrics were designed around the workloads with visibility into upstream change
stakeholder needs, piloted with each activity.
The organization was suffering from “metrics stakeholder group, fine-tuned, and rolled out.
fatigue,” with multiple reports being generated Architects were able to identify vendors and
from all groups within IT, to the point that Some metrics could not be automated off- systems that were the leading source of
weekly/monthly reports were being seen as the-shelf and were rolled out in a manual instability.
spam. fashion. These metrics were subsequently
automated and finally made available The VP of IT was able to track the maturity
through a dashboard. growth of the change management process and
proactively engage with the business on identified
hot spots.
participants:
Implement the Project • CIO/IT Director
• IT Managers
• Change Manager
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 • A communications plan for key
messages to communicate to relevant
stakeholders and audiences
Step 4.1: Identify Metrics and Build the
Step 3.2: Implement the Project • A roadmap with assigned action items
Change Calendar to implement change management

Success of the new process will depend on
introducing change and gaining acceptance Main Challenges with Communication
• Many people fail before they even start because they are
Change management provides value by promptly buried in a mess created before they arrived – either
evaluating and delivering changes required by the because of a failed attempt to get change management
business and by minimizing disruption and rework implemented or due to a complicated system that has
always existed.
caused by failed changes. Communication of your new
change management process is key. If people do not • Many systems are maintained because “that’s the way
it’s always been done.”
understand the what and why, it will fail to provide
the desired value. • Organizations don’t know where to start; they think
change management is too complex a process.
• Each group needs to follow the same procedure –

Info-Tech Best Practice groups often have their own processes, but if they don’t
agree with one another, this could cause an outage.
Gather feedback from end users about the new process:
if the process is too bureaucratic, end users are more
likely to circumvent it.

Educate affected stakeholders to prepare for
organizational change
Host a lunch-and-learn session
An organizational change management plan should be
• For the initial deployment, host a lunch-and-learn session
part of your change management project.
to educate the business on the change management practice.
Relevant stakeholders of affected departments should host it
• Educate stakeholders about: and cover the following topics:
• The process change (describe it in a way that the user can • What is change management (change management/change
understand and is clear and concise).
control)?
o IT changes will be handled in a standardized and repeatable
fashion to minimize change-related incidents. • The value of change management.
• Who is impacted?
• What the Change Management SOP looks like.
• All users.
• How are they impacted? • Who is involved in the change management process (the
CAB, etc.)?
• All change requests will be made using a standard form and will
not be deployed until formal approval is received. • What constitutes a pre-approved change and an emergency
• Change messaging. change?
• How to communicate the change (benefits).
• An overview of the process, including how to avoid
• Learning and development – training your users on the change.
unauthorized changes.
• Develop and deliver training session on the Change
Management SOP to familiarize users with this new method of • Who should they contact in case of questions?
handling IT change. Info-Tech Research Group | 119
Communicate the new process to all
affected stakeholders
Communication is crucial to the integration and
Do not surprise users or support staff with changes.
overall implementation of your change management
This will result in lost productivity and low initiative. An effective communications plan will:
satisfaction with IT services.
• User groups and the business need to be given sufficient notice of • Gain support from management at the project
an impending change. proposal phase.
• This will allow them to make appropriate plans to accept the • Create end-user buy-in once the program is set to
change, minimizing the impact of the change on productivity. launch.
• A communications plan will be documented in the RFC while the • Maintain the presence of the program throughout the
release is being built and tested. business.
• It’s the responsibility of the change team to execute on the • Instill ownership throughout the business from top-
communications plan. level management to new hires.
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.

Create your communications plan to anticipate challenges, remove
obstacles, and ensure buy-in
Provide separate communications to key stakeholder groups
Management Why? What problems are you trying When? When will this be
to solve? happening? When will it affect me?
What? What processes will it affect How? How will these changes
Technicians (that will affect me)? manifest themselves?
Who? Who will be affected? Who do I Goal? What is the final goal? How
go to if I have issues with the new will it benefit me?
process?
Info-Tech Insight
Pay close attention to the medium of communication. For example,
Business stakeholders on their feet all day would not be as receptive to an email
Stakeholders 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.

Input Output
4.2.1 Use a Communications Plan to Gain End User
Buy-In • List of stakeholder groups • Tailored communications
for change management plans for various
1. Using Info-Tech’s Change Management Communications Plan, identify key audiences or stakeholder groups
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:

Group Benefits Impact Method Timeline Materials Participants
Standardized change All changes must be Poster
IT 6 months
process reviewed and approved campaign
Decreased wait time Lunch-and-

End Users
for changes
Formal process for RFCs
learn sessions
3 months • Whiteboard/flip charts (or • Change Manager
Increased involvement in Monthly • Members of the Change
Business Reduced outages 1 year remotely)
planning and approvals reports Advisory Board
• Markers/pens
4. Discuss the communications plan: • Service Desk Manager
• Will this plan ensure that users are given adequate opportunities to accept the changes being deployed? • Change Management Comm
• Is the message appropriate for each audience? Is the format appropriate for each audience? unications Plan • Operations (optional)
• Does the communication include training where necessary to help users adopt any new
functions/workflows being introduced?
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. Info-Tech Insight
• You want your presentation to be succinct and hard hitting. Management’s time is tight The support of senior executive
and they will lose interest if you drag out the delivery. stakeholders is critical to the success of
• Briefly speak about the need for more formal change management and emphasize the your SOP rollout. Try to wow them with
benefits of implementing a more formal process with a SOP. project benefits and make sure they know
about the risks/pain points.
• 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. Download the Change Management
Project Summary Template
• Be prepared to review with both technical and less technical stakeholders.

Input Output
4.2.2 Create a Project Roadmap to Track Your
Implementation Progress • List of implementation tasks • Roadmap and timeline for
change management
1. Info-Tech’s Change Management Roadmap Tool helps you identify and prioritize tasks that need implementation
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.
• Whiteboard/flip charts (or • Change Manager

remotely)
Advisory Board
• Markers/pens
• Change Management Road
map Tool • Operations (optional)

Roadmap Tool Info-Tech Research Group | 124
Intel implemented a robust change management process.
INDUSTRY SOURCE

Founded in 1968, the world’s largest Intel had its new change management Intel first communicated the process
microchip and semiconductor company program in place and the early changes by publishing the vision and
employs over 100,000 people. Intel milestones planned, but one key strategy for the project with top
manufactures processors for major challenge with any new project is management sponsorship.
communication.
Apple, Lenovo, HP, and Dell. The CIO published all of the new
Intel IT supports over 65,000 servers, The company also needed to navigate change policies, which were supported
3.2 petabytes of data, over 70,000 PCs, the simplification of a previously by the Change Governance Council.
and 2.6 million emails per day. complex process; end users could be
familiar with any of the 37 different Intel cited the reason for success as the
Intel’s change management program is change processes or 25 different change designation of a Policy and Guidance
responsible for over 4,000 changes each management systems of record. Council – a group designed to own
week. communication and enforcement of the
Top-level buy-in was another concern. new policies and processes put in place.

Summary of If you would like additional
Accomplishment support, have our analysts
guide you through other
Problem Solved phases as part of an Info-
Tech workshop.
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.
Contact your account representative for
Remember as you are starting your implementation to keep your documents more information.
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 workshops@infotech.com
process. Furthermore, don’t shy away from seeking feedback from your 1-888-670-8889
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.

Additional Support Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889
If you would like additional support, have our
analysts guide you through other phases as
part of an Info-Tech Workshop.
The following are sample activities that will be conducted by Info-Tech

analysts with your team:
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.
1.1.2 Complete a Change 2.2.1 Plot the Process for a
Management Maturity Normal Change
Assessment Build a normal change process using
Run through the change management Info-Tech’s Change Management
maturity assessment with tailored Process Library template with an
commentary for each action item analyst helping you to right size the
outlining context and best practices. process for your organization.
Related Standardize the Service Desk
Info-Tech Improve customer service by driving consistency in your

support approach and meeting SLAs.
Research
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. Phillips, Katherine W., Katie A. Liljenquist, and Margaret A. Neale. “Better Decisions
Through Diversity.” Kellogg Insight, 1 Oct. 2010.
Behr, Kevin and George Spafford. The Visible Ops Handbook: Implementing ITIL in 4
Practical and Auditable Steps. IT Revolution Press. 2013. Pink Elephant. “Best Practices for Change Management.” Pink Elephant, 2005.
BMC. “ITIL Change Management.” BMC Software Canada, 22 December 2016. Sharwood, Simon. “Google broke its own cloud by doing two updates at once.” The
Register, 24 Aug. 2016.
Brown, Vance. “Change Management: The Greatest ROI of ITIL.” Cherwell Service
Management. SolarWinds. “How to Eliminate the No: 1 Cause of Network Downtime.” SolarWinds Tech
Tips, 25 Apr. 2014.
Cisco. “Change Management: Best Practices.” Cisco, 10 March 2008.
The Stationery Office. “ITIL Service Transition: 2011.” The Stationary Office, 29 July 2011.
Grove, Daniel. “Case Study ITIL Change Management Intel Corporation.” PowerShow,
2005. UCISA. “ITIL – A Guide to Change Management.” UCISA.
ISACA. “COBIT 5: Enabling Processes.” ISACA, 2012. Zander, Jason. “Final Root Cause Analysis and Improvement Areas: Nov 18 Azure Storage
Service Interruption.” Microsoft Azure: Blog and Updates, 17 Dec. 2014.
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.

Appendix I: Expedited Changes

Employ the expedited change to promote
process adherence Two possible ways to build an expedited
In many organizations, there are changes which may not fit into the three prescribed change category”
categories. The reason behind why the expedited category may be needed generally falls
1. Build the category similar to an emergency
between two possibilities:
change.
1. External drivers dictate changes via mandates which may not fall within the In this case, one difference would be the time
normal change cycle. allotted to fully obtain authorization of the
A CIO, judge, state/provincial mandate, or request from shared services pushes a
change from the E-CAB and business owner
change that does not fall within a normal change cycle. However, there is no
before implementing the change (as opposed
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 to the emergency change workflow).
will still do their best to implement the change without issue, but any extra risk of 2. Have the expedited change reflect the
implementing this expedited change (compared to an normal change) will be
normal change workflow.
absorbed by the change requester.
In this case, all the same steps of the normal
2. The change requester did not prepare for the change adequately. change workflow are followed except for
This is common if a new change process is being established (and stakeholders are expedited timelines between processes. This
still adapting to the process). Change requesters or the change build team may request may include holding an impromptu CAB
the change to be done by a certain date that does not fall within the normal change
meeting to authorize the 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. Info-Tech Research Group | 131
Example process: Expedited Change Process

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 "Understand that process is hard and
The core tenets of change management still apply no matter the type of development environment an organization has. finding a solution that fits every
Changes in any environment carry risk of degrading functionality, and must therefore be vetted. However, the amount of
need can be tricky. With this change
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 management process we do not try
are a DevOps or Agile shop: to solve every corner case so much
• Intake assessment (separation of changes from projects, service requests, operational tasks) as create a framework by which best
• Within a DevOps or Agile environment, many of the application changes will come directly from the SDLC judgement can be used to ensure
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 maximum availability of our
change bureaucracy. platforms and services while still
• Technical review complying with our regulatory
• Leveraging automation, release contingencies, and the current SDLC documentation to decrease change risk requirements and making positive
allows for various changes to be designated as pre-approved.
changes that will delight our
• Authorization
customers.“
• Define the authorization and dependencies of a change early in the lifecycle to gain authorization and necessary -IT Director, Information Cybersecurity
signoffs. Organization
• 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.
The core differences between an Agile or DevOps transition and a
Five principals for People
traditional approach are the restructuring and the team behind it. As a
result, the stakeholders of change management must be onboard for
implementing change 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.
in DevOps • 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.
DevOps Lifecycles • 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.
Follow these best practices to make
Automation comes in many forms and is well documented in many
sure your requirements are solid: development workflows. Having automated signoffs for QA/security
Automation checks and stakeholders/cross dependency owner sign offs may not
fully replace the CAB but can ease the burden on discussions before
implementation.
Canary releases, phased releases, dark releases, and toggles are all
options you can employ to reduce risk during a release. Furthermore,
Contingencies building in contingencies to the test/rollback plan decreases the risk of
the change by decreasing the factor of likelihood.
Building change from the ground up doesn’t meant the process has to
Continually be fully fledged before launch. Iterative improvements are possible
before achieving an optimal state. Having the proper metrics on the
Improve pain points and bottlenecks in the process can identify areas for
automation and improvement. Info-Tech Research Group | 135
Increasing the proportion of pre- Relative Change Proportions of Change Categories
approved changes
100
Leverage the traditional change infrastructure to deploy 90
changes quickly while keeping your risk low. 80
70
60
• 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 50
changes within the Agile framework are designed to be small and lower
risk (at least within application development). Putting in the work ahead 40
of time to document these changes, template RFCs, and document the
dependencies for various changes allows for a shift in the proportion of 30
pre-approved changes.
20
• The designation of pre-approved changes is an ongoing process. This is
not an overnight initiative. Measure the proportion of changes by 10
category as a metric, setting goals and interim goals to shift the change
0
proportion to a desired ratio. Before After
Emergency Normal Pre-Approved

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.

It Optimize IT Change Management Phases 1 4 R4

Uploaded by

Copyright:

Available Formats

You might also like

It Optimize IT Change Management Phases 1 4 R4

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

It Optimize IT Change Management Phases 1 4 R4

Uploaded by

Copyright:

Available Formats

Optimize IT Change

Info-Tech Research Group Inc. is a global leader in providing IT research and

Phase 1: Define Change Management

117 Step 4.2: Implement the Project

27 Step 1.1: Assess Maturity 126 Summary of Accomplishment

35 Step 1.2: Categorize Changes and 127 Additional Support

61 Step 2.2: Build Core Workflows

82 Phase 3: Define the RFC and Post-

83 Step 3.1: Design the RFC

93 Step 3.2: Establish Post-

Info-Tech Research Group | 4

Balance Risk and Efficiency to Optimize IT Change Management

Info-Tech Research Group | 5

• Integrate the change management practice with project 4

management, service desk processes, configuration management, 3

and other areas of IT and the business. 2

Of the eight infrastructure & operations processes measured in

• Each silo or department may have their own change management

Info-Tech Research Group | 7

Info-Tech Research Group | 8

Operational releases, Business

Info-Tech Research Group | 10

• If you are implementing change management in a

Info-Tech Research Group | 11

IT Benefits Business Benefits

Info-Tech Research Group | 12

Control Collaboration Consistency Confidence

Info-Tech Research Group | 13

Not in place: n/a

common change; this will

change management REALITY

“Ad hoc is faster; Ad hoc might be faster in some

Change management is about

“Change Change management allows for a

• Change prioritization: The CAB prioritizes changes so that the business is

Info-Tech Research Group | 17

Change Management Standard Operating Procedure (SOP)

• Request for Change

Info-Tech Research Group | 18

Project Summary Template Change Management Roadmap Tool

Summarize your efforts in the

A major technology company implemented change management to

Info-Tech Research Group | 20

Guided Implementation Measured Value

Founded in 1968, the world’s largest microchip and semiconductor company

After a robust implementation of change management, Intel experienced a

Info-Tech Research Group | 22

Info-Tech Research Group | 23

Day 1 Day 2 Day 3 Day 4 Day 5

Assessment membership Plan 5.2 Set up review time for

1.4 Build Your Risk 2.4 Build Emergency Change

Info-Tech Research Group | 25

This phase involves the following

Define the RFC and Measure, Manage, and

Assess Maturity • CIO

Outcomes of this step

Change management provides a holistic view of