Build a Platform-Based Organization

Use a platform structure to overcome bureaucracy.

Analyst Perspective

Build a platform-based organization.

Bureaucracy saps innovation out of large corporations. Some even believe that bureaucracy is inevitable and is an outcome of a complex business operating in a complex market and regulatory environment.

So, what is the antidote to bureaucracy? Some look to startups like Uber, Airbnb, Netflix, and Spotify, but they are digital native and don’t compare well to a large monolithic corporation.

However, all is not lost for large corporations. Inspiration can be drawn from a company in China – Haier, which is not a typical poster child of the digital age like Spotify. In fact, three decades ago, it was a state-owned company with a shoddy product quality.

Haier uses an intriguing organization structure based on microenterprises and platforms that has proven to be an antidote to bureaucracy.

Vivek Mehta
Research Director, Digital & Innovation
Info-Tech Research Group

Executive Summary

The Challenge

Large corporations are prone to bureaucracies, which sap their organizations of creativity and make them blind to new opportunities. Though many executives express the desire to get rid of it, bureaucracy is thriving in their organizations.

Why It Happens

As organizations grow and become more complex over time, they yearn for efficiency and control. Some believe bureaucracy is the natural outcome of running a complex organization in a complex business and regulatory environment.

Info-Tech’s Approach

A new organizational form – the platform structure – is challenging the bureaucratic model. The platform structure makes employees directly accountable to customers and organizes them in an ecosystem of autonomous units.

As a starting point, sketch out a platform structure that works for your organization. Then, establish a governance model and identify and nurture key capabilities for the platform structure.

Info-Tech Insight

The antidote to bureaucracy is a platform structure: small, autonomous teams operating as startups within the organization.

Executive Brief Case Study

Small pieces, loosely joined

Haier

Industry: Manufacturing
Source: Harvard Business Review November-December 2018

Haier, based in China, is currently the world’s largest appliance maker. Zhang Ruimin, Haier’s CEO, has built an intriguing organizing structure where every employee is directly accountable to customers – internal and/or external. A large corporation often consists of a few operating units, each with its own idiosyncrasies, which makes it slow to innovate. To avoid that, Haier has divided itself into 4,000 microenterprises (MEs), most of which have ten to 15 employees. There are three types of microenterprises in Haier:

1. Approximately 200 “transforming” MEs: market-facing units like Zhisheng, which manufactures refrigerators, a legacy Haier product, for today’s young urbanites.
2. Approximately 50 “incubating” MEs: entirely new businesses like Xinchu that wrap existing products into entirely new business models.
3. Approximately 3,800 “node” MEs: units that sell component products and services such as design, manufacturing, and human resources support to Haier’s market-facing MEs.

Each ME operates as an autonomous unit with its own targets – an organizing structure that enables innovation at Haier.

(Harvard Business Review, 2018)

Markets disproportionately reward platform structure

Tech companies like Facebook, Netflix, and Spotify are organized around a set of modular platforms run by accountable platform teams. This modular org structure enables them to experiment, learn, and scale quickly – a key attribute of innovative organizations.

Facebook ~2,603 million monthly active users

India ~1,353 million population

Netflix ~183 million monthly paid subscribers

Spotify ~130 million premium subscribers

Canada ~37 million population

(“Facebook Users Worldwide 2020,” “Number of Netflix Subscribers 2019,” “Spotify Users - Subscribers in 2020,” Statista.)

1. Sketch Out the Platform Structure

What is a platform anyway?

A modular component of an org structure

“Platforms consist of a logical cluster of activities and associated technology that delivers on a specific business goal and can therefore be run as a business, or ‘as a service’ … Platforms focus on business solutions to serve clients (internal or external) and to supply other platforms.” – McKinsey, 2019

Platforms operate as independent units with their own business, technology, governance, processes, and people management. As an instance, a bank could have payments platform under a joint business and IT leadership. This payments-as-a-service platform could provide know-how, processes, and technology to the bank’s internal customers such as retail and commercial business units.

Many leading IT organizations are set up in a platform-based structure that allows them to rapidly innovate. It’s an imperative for organizations in other industries that they must pilot and then scale with a platform play.

What a platform-based org looks like

It looks like a multicellular organism, where each cell is akin to a platform

An organism consists of multiple cells of different types, sizes, and shapes. Each cell is independent in its working. Regardless of the type, a cell would have three features –the nucleus, the cell membrane, and, between the two, the cytoplasm.

Similarly, an organization could be imagined as one consisting of several platforms of different types and sizes. Each platform must be autonomous, but they all share a few common features – have a platform leader, set up and monitor targets, and enable interoperability amongst platforms. Platforms could be of three types (McKinsey, 2019):

1. Customer-journey platforms enable customer proposition and experience built on reusable code. They provide “journey as a service”; for example, Account Opening in a bank.
2. Business-solution platforms are modular and run as a business or as a service. They provide “company as a service”; for example, Payments or Fraud Detection in a bank.
3. Core IT provisioning platforms provide core IT services for the organization, for example, cloud, data, automation.

Case study: Payments platform in a bank

Payments as a service to internal business units

The payments platform is led by an SVP – the platform leader. Business and IT teams are colocated and have joint leadership. The platform team works with a mindset of a startup, serving internal customers of the bank – retail and commercial lines of business.

Advisory Council: An Advisory Council is responsible for strategy, business, and IT architecture and for overseeing the work within the team. The Advisory Council prioritizes the work, earmarks project budgets, sets standards such as for APIs and ISO 20022, and leads vendor evaluation.

International payments (VISA, WU, etc.): Project execution teams are structured around payment modes. Teams collaborate with each other whenever a common functionality is to be developed, like fraud check on a payment or account posting for debits and credits.

Payments innovation: A think tank keeping track of trends in payments and conducting proof of concepts (POCs) with prospective fintech partners and with new technologies.

Use a capability map to sketch out a platform-based structure

Corral your organization’s activities and associated tech into a set of 20 to 40 platforms that cover customer journeys, business capabilities, and core IT. Business and IT teams must jointly work on this activity and could use a capability map as an aid to facilitate the discussion.

An example of sketching a platform-based org structure for an insurance provider (partial)

2. Establish Governance and Nurture Key Capabilities

Two ingredients of the platform structure

Establish a governance

Advisory Council (AC) operates like a conductor at an orchestra, looking across all the activities to understand and manage the individual components.

Nurture key capabilities

Team structure, processes and technologies must be thoughtfully orchestrated and nurtured.

Establish strong governance

Empowerment does not mean anarchy

While platforms are distinct units, they must be in sync with each other, like individual musicians in an orchestra. The Advisory Council (AC) must act like a conductor of the orchestra and lead and manage across platforms in three ways.

1. Prioritize spend and effort. The AC team makes allocation decisions and prioritizes spend and effort on those platforms that can best support organizational goals and/or are in most urgent technical need. The best AC teams have enterprise architects who can understand business and dive deep enough into IT to manage critical interdependencies.
2. Set and enforce standards. The AC team establishes both business and technology standards for interoperability. For example, the AC team can set the platform and application interfaces standards and the industry standards like ISO 20022 for payments. The AC team can also provide guidance on common apps and tools to use, for example, a reconciliation system for payments.
3. Facilitate cross-platform work. The AC team has a unique vantage point where it can view and manage interdependencies among programs. As these complexities emerge, the AC team can step in and facilitate the interaction among the involved platform teams. In cases when a common capability is required by multiple platforms, the AC team can facilitate the dialogue to have it built out.

Nurture the following capabilities:

Design thinking

“Zero distance from the customer” is the focus of platform structure. Each platform must operate with a mindset of a startup serving internal and/or external users.

Agile delivery model

Platform teams iteratively develop their offerings. With guidance from Advisory Council, they can avoid bottlenecks of formal alignment and approvals.

Enterprise architecture

The raison d'être of enterprise architecture discipline is to enable modularity in the architecture, encourage reusability of assets, and simplify design.

Microservices

Microservices allow systems to grow with strong cohesion and weak coupling and enable teams to scale components independently.

APIs

With their ability to link systems and data, APIs play a crucial role in making IT systems more responsive and adaptable.

Machine learning

With the drop in its cost, predictability is becoming the new electricity for business. Platforms use machine learning capability for better predictions.

Related Info-Tech Research

Drive Digital Transformation With Platform Strategies
Innovate and transform your business models with digital platforms.

Implement Agile Practices That Work
Guide your organization through its Agile transformation journey.

Design a Customer-Centric Digital Operating Model
Putting the customer at the center of digital transformation.

Bibliography

Bossert, Oliver, and Jürgen Laartz. “Perpetual Evolution—the Management Approach Required for Digital Transformation.” McKinsey, 5 June 2017. Accessed 21 May 2020.

Bossert, Oliver, and Driek Desmet. “The Platform Play: How to Operate like a Tech Company.” McKinsey, 28 Feb. 2019. Accessed 21 May 2020.

“Facebook Users Worldwide 2020.” Statista. Accessed 21 May 2020.

Hamel, Gary, and Michele Zanini. “The End of Bureaucracy.” Harvard Business Review. Nov.-Dec. 2018. Accessed 21 May 2020.

“Number of Netflix Subscribers 2019.” Statista. Accessed 21 May 2020.

“Spotify Users - Subscribers in 2020.” Statista. Accessed 21 May 2020.

Build a Security Metrics Program to Drive Maturity

Good metrics come from good goals.

ANALYST PERSPECTIVE

Metrics are a maturity driver.

"Metrics programs tend to fall into two groups: non-existent and unhelpful.

The reason so many security professionals struggle to develop a meaningful metrics program is because they are unsure of what to measure or why.

The truth is, for metrics to be useful, they need to be tied to something you care about – a state you are trying to achieve. In other words, some kind of goal. Used this way, metrics act as the scoreboard, letting you know if you’re making progress towards your goals, and thus, boosting your overall maturity."

– Logan Rohde, Research Analyst, Security Practice Info-Tech Research Group

Executive summary

Situation

• Many security leaders put off adding metrics to their program because they don't know where to start or how to assess what is worth measuring.

Complication

• Sometimes, this uncertainty causes the belief that their security programs are not mature enough for metrics to be worthwhile.
• Because metrics can become very technical and precise, it's easy to think they're inherently complicated (not true).

Resolution

• A metric, really, is just a measure of success against a given goal. Gradually, programs will achieve their goals and set new, more specific goals, and with them comes more specific metrics.
• It is not necessary to jump into highly technical metrics right away. A lot can be gained from metrics that track behaviors.
• A metrics program can be very simple and still effectively demonstrate the value of security to the organization. The key is to link your metrics to the goals or objectives the security team is pursuing, even if they are simple implementation plans (e.g. percentage of departments that have received security training).

Info-Tech Insight

1. Metrics lead to maturity, not vice versa
   • Tracking metrics helps you assess progress and regress in your security program. This helps you quantify the maturity gains you’ve made and continue to make informed strategic decisions.
2. The best metrics are tied to goals
   • Tying your metrics to goals ensures that you are collecting metrics for a specific purpose rather than just to watch the numbers change.

Our understanding of the problem

This Research is Designed For:

• CISO

This Research Will Help You:

• Understand the value of metrics.
• Right-size a metrics program based on your organization’s maturity and risk profile.
• Tie metrics to goals to create meaningful KPIs.
• Develop strategies to effectively communicate the right metrics to stakeholders.

This Research Will Also Assist:

• CIO
• Security Manager
• Business Professionals

This Research Will Help Them:

• Become informed on the metrics that matter to them.
• Understand that investment in security is an investment in the business.
• Feel confident in the progress of the organization’s security strategy.

Info-Tech’s framework integrates several best practices to create a best-of-breed security framework

Information Security Framework

Governance

• Context and Leadership
  • Information Security Charter
  • Information Security Organizational Structure
  • Culture and Awareness
• Evaluation and Direction
  • Security Risk Management
  • Security Policies
  • Security Strategy and Communication
• Compliance, Audit, and Review
  • Security Compliance Management
  • External Security Audit
  • Internal Security Audit
  • Management Review of Security

Management

• Prevention
  • Identity Security
    • Identity and Access Management
  • Data Security
    • Hardware Asset Management
    • Data Security & Privacy
  • Infrastructure Security
    • Network Security
    • Endpoint Security
    • Malicious Code
    • Application Security
    • Vulnerability Management
    • Cryptography Management
    • Physical Security
    • Cloud Security
  • HR Security
    • HR Security
  • Change and Support
    • Configuration and Change Management
    • Vendor Management
• Detection
  • Security Threat Detection
  • Log and Event Management
• Response and Recovery
  • Security Incident Management
  • Information Security in BCM
  • Security eDiscovery and Forensics
  • Backup and Recovery
• Measurement
  • Metrics Program
  • Continuous Improvement

Metrics help to improve security-business alignment

While business leaders are now taking a greater interest in cybersecurity, alignment between the two groups still has room for improvement.

Key statistics show that just...

5% of public companies feel very confident that they are properly secured against a cyberattack.

41% of boards take on cybersecurity directly rather than allocating it to another body (e.g. audit committee).

19% of private companies do not discuss cybersecurity with the board.

(ISACA, 2018)

Info-Tech Insight

Metrics help to level the playing field

Poor alignment between security and the business often stems from difficulties with explaining how security objectives support business goals, which is ultimately a communication problem.

However, metrics help to facilitate these conversations, as long as the metrics are expressed in practical, relatable terms.

Security metrics benefit the business

Executives get just as much out of management metrics as the people running them.

1. Metrics assuage executives’ fears
   • Metrics help executives (and security leaders) feel more at ease with where the company is security-wise. Metrics help identify areas for improvement and gaps in the organization’s security posture that can be filled. A good metrics program will help identify deficiencies in most areas, even outside the security program, helping to identify what work needs to be done to reduce risk and increase the security posture of the organization.
2. Metrics answer executives’ questions
   • Numbers either help ease confusion or signify other areas for improvement. Offering quantifiable evidence, in a language that the business can understand, offers better understanding and insight into the information security program. Metrics also help educate on types of threats, staff needed for security, and budget needs to decrease risk based on management’s threat tolerance. Metrics help make an organization more transparent, prepared, and knowledgeable.
3. Metrics help to continually prove security’s worth
   • Traditionally, the security team has had to fight for a seat at the executive table, with little to no way to communicate with the business. However, the new trend is that the security team is now being invited before they have even asked to join. This trend allows the security team to better communicate on the organization’s security posture, describe threats and vulnerabilities, present a “plan of action,” and get a pulse on the organization’s risk tolerance.

Common myths make security metrics seem challenging

Security professionals have the perception that metrics programs are difficult to create. However, this attitude usually stems from one of the following myths. In reality, security metrics are much simpler than they seem at first, and they usually help resolve existing challenges rather than create new ones.

Tie your metrics to goals to make them worthwhile

SMART metrics are really SMART goals.

Specific

Measurable

Achievable

Realistic

Timebound

Achievable: What is an achievable metric?

When we say that a metric is “achievable,” we imply that it is tied to a goal of some kind – the thing we want to achieve.

How do we set a goal?

1. Determine what outcome you are trying to achieve.
   • This can be small or large (e.g. I want to determine what existing systems can provide metrics, or I want a 90% pass rate on our monthly phishing tests).
2. Decide what indicates that you’ve achieved your goal.
   • At what point would you be satisfied with the progress made on the initiative(s) you’re working on? What conditions would indicate victory for you and allow you to move on to another goal?
3. Develop a key performance indicator (KPI) to measure progress towards that goal.
   • Now that you’ve defined what you’re trying to achieve, find a way to indicate progress in relative or relational terms (e.g. percentage change from last quarter, percentage of implementation completed, ratio of programs in place to those still needing implementation).

Info-Tech’s security metrics methodology is repeatable and iterative to help boost maturity

Security Metric Lifecycle

Start:

Review current state and decide on priorities.

Set a SMART goal for improvement.

Develop an appropriate KPI.

Use KPI to monitor program improvement.

Present metrics to the board.

Revise metrics if necessary.

Metrics go hand in hand with your security strategy

A security strategy is ultimately a large goal-setting exercise. You begin by determining your current maturity and how mature you need to be across all areas of information security, i.e. completing a gap analysis.

As such, linking your metrics program to your security strategy is a great way to get your metrics program up and running – but it’s not the only way.

Check out the following Info-Tech resource to get started today:

Build an Information Security Strategy

The value of security metrics goes beyond simply increasing security

This blueprint applies to you whether you need to develop a metrics program from scratch or optimize and update your current strategy.

Value of engaging in security metrics:

• Increased visibility into your operations.
• Improved accountability.
• Better communication with executives as a result of having hard evidence of security performance.
• Improved security posture through better understanding of what is working and what isn’t within the security program.

Value of Info-Tech’s security metrics blueprint:

• Doesn’t overwhelm you and allows you to focus on determining the metrics you need to worry about now without pressuring you to do it all at once.
• Helps you develop a growth plan as your organization and metrics program mature, so you continue to optimize.
• Creates effective communication. Prepares you to present the metrics that truly matter to executives rather than confusing them with unnecessary data. Pay attention to metric accuracy and reproducibility. No management wants inconsistent reporting.

Impact

Short term: Streamline your program. Based on your organization’s specific requirements and risk profile, figure out which metrics are best for now while also planning for future metrics as your organization matures.

Long term: Once the program is in place, improvements will come with increased visibility into operations. Investments in security will be encouraged when more evidence is available to executives, contributing to overall improved security posture. Potential opportunities for eventual cost savings also exist as there is more informed security spending and fewer incidents.

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

DIY Toolkit

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

Guided Implementation

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

Workshop

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

Consulting

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

Diagnostics and consistent frameworks used throughout all four options

Link Security Metrics to Goals to Boost Maturity – Project Overview

Workshop overview

Contact your account representative or email Workshops@InfoTech.com for more information.

Phase 1

Link Security Metrics to Goals to Boost Maturity

Phase 1

1.1 Review current state and set your goals

1.2 Develop KPIs and prioritize your goals

1.3 Implement and monitor KPIs

This phase will walk you through the following activities:

• Current state assessment
• Setting SMART goals
• KPI development
• Goals prioritization
• KPI implementation

This phase involves the following participants:

• Security Team

Outcomes of this phase

• Goals-based KPIs
• Security Metrics Determination and Tracking Tool

Phase 1 outline

Complete these steps on your own or call us to complete a guided implementation. A guided implementation is a series of two to three advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Guided Implementation 1: Link Security Metrics to Goals to Boost Maturity

Proposed Time to Completion: 2-4 weeks

Step 1.1: Setting Goals

Start with an analyst kick-off call:

• Determine current and target maturity for various security programs.
• Develop SMART Goals.

Then complete these activities…

• CMMI Assessment

Step 1.2 – 1.3: KPI Development

Review findings with analyst:

• Prioritize goals
• Develop KPIs to track progress on goals
• Track associated metrics

Then complete these activities…

• KPI Development

With these tools & templates:

• KPI Development Worksheet
• Security Metrics Determination and Tracking Tool

Phase 1 Results & Insights:

• Basic Metrics program

1.1 Review current state and set your goals

120 minutes

Let’s put the security program under the microscope.

Before program improvement can take place, it is necessary to look at where things are at presently (in terms of maturity) and where we need to get them to.

In other words, we need to perform a security program gap analysis.

Info-Tech Best Practice

The most thorough way of performing this gap analysis is by completing Info-Tech’s Build an Information Security Strategy blueprint, as it will provide you with a prioritized list of initiatives to boost your security program maturity.

Completing an abbreviated gap analysis...

• Security Areas
• Network Security
• Endpoint Security
• Vulnerability Management
• Identity Access Management
• Incident Management
• Training & Awareness
• Compliance, Audit, & Review
• Risk Management
• Business Alignment & Governance
• Data Security

1. Using the CMMI scale on the next slide, assess your maturity level across the security areas to the left, giving your program a score from 1-5. Record your assessment on a whiteboard.
2. Zone in on your areas of greatest concern and choose 3 to 5 areas to prioritize for improvement.
3. Set a SMART goal for improvement, using the criteria on goals slides.

Use the CMMI scale to contextualize your current maturity

Use the Capability Maturity Model Integration (CMMI) scale below to help you understand your current level of maturity across the various areas of your security program.

1. Initial
   • Incident can be managed. Outcomes are unpredictable due to lack of a standard operating procedure.
2. Repeatable
   • Process in place, but not formally implemented or consistently applied. Outcomes improve but still lack predictability.
3. Defined
   • Process is formalized and consistently applied. Outcomes become more predictable, due to consistent handling procedure.
4. Managed
   • Process shows signs of maturity and can be tracked via metrics. Moving towards a predictive approach to incident management.
5. Optimizing
   • Process reaches a fully reliable level, though improvements still possible. Regularity allows for process to be automated.

(Adapted from the “CMMI Institute Maturity Model”)

Base your goals around the five types of metrics

Choose goals that make sense – even if they seem simple.

The most effective metrics programs are personalized to reflect the goals of the security team and the business they work for. Using goals-based metrics allows you to make incremental improvements that can be measured and reported on, which makes program maturation a natural process.

Info-Tech Best Practice

Before setting a SMART goal, take a moment to consider your maturity for each security area, and which metric type you need to collect first, before moving to more ambitious goals.

Security Areas

• Network Security
• Endpoint Security
• Vulnerability Management
• Identity Access Management
• Incident Management
• Training & Awareness
• Compliance, Audit & Review
• Risk Management
• Business Alignment & Governance
• Data Security

Set SMART goals for your security program

Specific

Measurable

Achievable

Realistic

Timebound

Now that you have determined which security areas you’d like to improve, decide on a goal that meets the SMART criteria.

Examples of possible goals for various maturity levels:

1. Perform initial probe to determine number of systems capable of providing metrics by the end of the week.
2. Take baseline measurements each month for three months to determine organization’s baseline state.
3. Implement a vulnerability management program to improve baseline state by the end of the quarter.
4. Improve deployment of critical patches by applying 90% of them within the set window by the end of the year.
5. Demonstrate how vulnerability management affects broad organizational trends at quarterly report to senior leadership.

Compare the bolded text in these examples with the metric types on the previous slide

Record and assess your goals in the Security Metrics Determination and Tracking Tool

1.1 Security Metrics Determination and Tracking Tool

Use tab “2. Identify Security Goals” to document and assess your goals.

To increase visibility into the cost, effort, and value of any given goal, assess them using the following criteria:

• Initial Cost
• Ongoing Cost
• Initial Staffing
• Ongoing Staffing
• Alignment w/Business
• Benefit

Use the calculated Cost/Effort Rating, Benefit Rating, and Difference Score later in this project to help with goal prioritization.

Info-Tech Best Practice

If you have already completed a security strategy with Info-Tech resources, this work may likely have already been done. Consult your Information Security Program Gap Analysis Tool from the Build an Information Security Strategy research.

1.2 Develop KPIs and prioritize your goals

There are two paths to success.

At this time, it is necessary to evaluate the priorities of your security program.

Option 1: Progress to KPI Development

• If you would like practice developing KPIs for multiple goals to get used to the process, move to KPI development and then assess which goals you can pursue now based on resources available, saving the rest for later.

Option 2: Progress to Prioritization of Goals

• If you are already comfortable with KPI development and do not wish to create extras for later use, then prioritize your goals first and then develop KPIs for them.

Phase 1 Schematic

• Gap Analysis
• Set SMART Goals (You are here.)
  • Develop KPIs
• Prioritize Goals
• Implement KPI & Monitor
• Phase 2

Develop a key performance indicator (KPI)

Find out if you’re meeting your goals.

Terms like “key performance indicator” may make this development practice seem more complicated than it really is. A KPI is just a single metric used to measure success towards a goal. In relational terms (i.e. as a percentage, ratio, etc.) to give it context (e.g. % of improvement over last quarter).

KPI development is about answering the question: what would indicate that I have achieved my goal?

To develop a KPI follow these steps:

1. Review the case study on the following slides to get a sense of how KPIs can start simple and general and get more specific and complex over time.
2. Using the example to the right, sort your SMART goals from step 1.1 into the various metric types, then determine what success would look like for you. What outcome are you trying to achieve? How will you know when you’ve achieved it?
3. Fill out the KPI Development Worksheets to create sample KPIs for each of the SMART goals you have created. Ensure that you complete the accompanying KPI Checklist.

KPIs differ from goal to goal, but their forms follow certain trends

Explore the five metric types

1. Initial Probe

Focused on determining how many sources for metrics exist.

• Question: What am I capable of knowing?
• Goal: To determine what level of insight we have into our security processes.
• Possible KPI: % of systems for which metrics are available.
• Decision: Do we have sufficient resources available to collect metrics?

2. Baseline Testing

Focused on gaining initial insights about the state of your security program (what are the measurements?).

• Question: Does this data suggest areas for improvement?
• Goal: To create a roadmap for improvement.
• Possible KPI: % of systems that provide useful metrics to measure improvement.
• Decision: Is it necessary to acquire tools to increase, enhance, or streamline the metrics-gathering process?

Info-Tech Insight

Don't lose hope if you lack resources to move beyond these initial steps. Even if you are struggling to pull data, you can still draw meaningful metrics. The percent or ratio of processes or systems you lack insight into can be very valuable, as it provides a basis to initiate a risk-based discussion with management about the organization's security blind spots.

Explore the five metric types (cont’d)

3. Program Implementation

Focused on developing a basic program to establish basic maturity (e.g. implement an awareness and training program).

• Question: What needs to be implemented to establish basic maturity?
• Goal: To begin closing the gap between current and desired maturity.
• Possible KPI: % of implementation completed.
• Decision: Have we achieved a formalized and repeatable process?

4. Improvement

Focused on attaining operational targets to lower organizational risk.

• Question: What other related activities could help to support this goal (e.g. regular training sessions)?
• Goal: To have metrics operate above or below a certain threshold (e.g. lower phishing-test click rate to an average of 10% across the organization)
• Possible KPI: Phishing click rate %
• Decision: What other metrics should be tracked to provide insight into KPI fluctuations?

Info-Tech Insight

Don't overthink your KPI. In many cases it will simply be your goal rephrased to express a percentage or ratio. In others, like the example above, it makes sense for them to be identical.

5. Organizational Impact

Focused on studying several related KPIs (Key Performance Index, or KPX) in an attempt to predict risks.

• Question: What risks does the organization need to address?
• Goal: To provide high-level summaries of several metrics that suggest emerging or declining risks.
• Possible KPI: Likelihood of a given risk (based on the trends of the KPX).
• Decision: Accept the risk, transfer the risk, mitigate the risk?

Case study: Healthcare example

Let’s take a look at KPI development in action.

Meet Maria, the new CISO at a large hospital that desperately needs security program improvements. Maria’s first move was to learn the true state of the organization’s security. She quickly learned that there was no metrics program in place and that her staff were unaware what, if any, sources were available to pull security metrics from.

After completing her initial probe into available metrics and then investigating the baseline readings, she determined that her areas of greatest concern were around vulnerability and access management. But she also decided it was time to get a security training and awareness program up and running to help mitigate risks in other areas she can’t deal with right away.

Info-Tech Insight

There is very little variation in the kinds of goals people have around initial probes and baseline testing. Metrics in these areas are virtually always about determining what data sources are available to you and what that data actually shows. The real decisions start in determining what you want to do based on the measures you’re seeing.

Metric development example: Vulnerability Management

See examples of Maria’s KPI development on the next four slides...

Implementation

Goal: Implement vulnerability management program

KPI: % increase of insight into existing vulnerabilities

Associated Metric: # of vulnerability detection methods

Improvement

Goal: Improve deployment time for patches

KPI: % of critical patches fully deployed within target window

• Associated Metric 1: # of critical vulnerabilities not patched
• Associated Metric 2: # of patches delayed due to lack of staff
• Associated Metric X

Metric development example: Identity Access Management

Implementation

Goal: Implement MFA for privileged accounts

KPI: % of privileged accounts with MFA applied

Associated Metric: # of privileged accounts

Improvement

Goal: Remove all unnecessary privileged accounts

KPI: % of accounts with unnecessary privileges

• Associated Metric 1: # of privileged accounts
• Associated Metric 2: # of necessary privileged accounts
• Associated Metric X

Metric development example: Training and Awareness

Implementation

Goal: Implement training and awareness program

KPI: % of organization trained

Associated Metric: # of departments trained

Improvement

Goal: Improve time to report phishing

KPI: % of phishing cases reported within target window

• Associated Metric 1: # of phishing tests
• Associated Metric 2: # of training sessions
• Associated Metric X

Metric development example: Key Performance Index

Organizational Trends

Goal: Predict Data Breach Likelihood

• KPX 1: Insider Threat Potential
  • % of phishing cases reported within target window
    • Associated Metrics:
      • # of phishing tests
      • # of training sessions
  • % of critical patches fully deployed within target window
    • Associated Metrics:
      • # of critical vulnerabilities not patched
      • # of patches delayed due to lack of staff
  • % of accounts with unnecessary privileges
    • Associated Metrics:
      • # of privileged accounts
      • # of necessary privileged accounts
• KPX 2: Data Leakage Issues
  • % of incidents related to unsecured databases
    • Associated Metrics:
      • # of unsecured databases
      • # of business-critical databases
  • % of misclassified data
    • Associated Metrics:
      • # of misclassified data reports
      • # of DLP false positives
  • % of incidents involving data-handling procedure violations.
    • Associated Metrics:
      • # of data processes with SOP
      • # of data processes without SOP
• KPX 3: Endpoint Vulnerability Issues
  • % of unpatched critical systems
    • Associated Metrics:
      • # of unpatched systems
      • # of missed patches
  • % of incidents related to IoT
    • Associated Metrics:
      • # of IoT devices
      • # of IoT unsecure devices
  • % of incidents related to BYOD
    • Associated Metrics:
      • # of end users doing BYOD
      • # of BYOD incidents

Develop Goals-Based KPIs

1.2 120 minutes

Materials

• Info-Tech KPI Development Worksheets

Participants

• Security Team

Output

• List of KPIs for immediate and future use (can be used to populate Info-Tech’s KPI Development Tool).

It’s your turn.

Follow the example of the CISO in the previous slides and try developing KPIs for the SMART goals set in step 1.1.

• To begin, decide if you are starting with implementation or improvement metrics.
• Enter your goal in the space provided on the left-hand side and work towards the right, assigning a KPI to track progress towards your goal.
• Use the associated metrics boxes to record what raw data will inform or influence your KPI.
  • Associated metrics are connected to the KPI box with a segmented line. This is because these associated metrics are not absolutely necessary to track progress towards your goal.
  • However, if a KPI starts trending in the wrong direction, these associated metrics would be used to determine where the problem has occurred.
• If desired, bundle together several related KPIs to create a key performance index (KPX), which is used to forecast the likelihood of certain risks that would have a major business impact (e.g. potential for insider threat, or risk for a data breach).

Record KPIs and assign them to goals in the Security Metrics Determination and Tracking Tool

1.2 Security Metrics Determination and Tracking Tool

Document KPI metadata in the tool and optionally assign them to a goal.

Tab “3. Identify Goal KPIs” allows you to record each KPI and its accompanying metadata:

• Source
• Owner
• Audience
• KPI Target
• Effort to Collect
• Frequency of Collection
• Comments

Optionally, each KPI can be mapped to goals defined on tab “2. Identify Security Goals.”

Info-Tech Best Practice

Ensure your metadata is comprehensive, complete, and realistic. A different employee should be able to use only the information outlined in the metadata to continue collecting measurements for the program.

Complete Info-Tech’s KPI Development Worksheets

1.2 KPI Development Worksheet

Use these worksheets to model the maturation of your metrics program.

Follow the examples contained in this slide deck and practice creating KPIs for:

• Implementation metrics
• Improvement metrics
• Organizational trends metrics

As well as drafting associated metrics to inform the KPIs you create.

Info-Tech Best Practice

Keep your metrics program manageable. This exercise may produce more goals, metrics, and KPIs than you deal with all at once. But that doesn’t mean you can’t save some for future use.

Build an effort map to prioritize your SMART goals

1.2 120 minutes

Materials

• Whiteboard
• Sticky notes
• Laptop

Participants

• Security team
• Other stakeholders

Output

• Prioritized list of SMART goals

An effort map visualizes a cost and benefit analysis. It is a quadrant output that visually shows how your SMART goals were assessed. Use the calculated Cost/Effort Rating and Benefit Rating values from tab “2. Identify Security Goals” of the Security Metrics Determination and Tracking Tool to aid this exercise.

Steps:

1. Establish the axes and colors for your effort map:
   1. X-axis (horizontal) - Security benefit
   2. Y-axis (vertical) - Overall cost/effort
   3. Sticky color - Business alignment
2. Create sticky notes for each SMART goal and place them onto the effort map based on your determined axes.
   • Goal # Example Security Goal - Benefit (1-12) - Cost (1-12)

1.3 Implement and monitor the KPI to track goal progress

Let’s put your KPI into action!

Now that you’ve developed KPIs to monitor progress on your goals, it’s time to use them to drive security program maturation by following these steps:

1. Review the KPI Development Worksheets (completed in step 1.2) for your prioritized list of goals. Be sure that you are able to track all of the associated metrics you have identified.
2. Track the KPI and associated metrics using Info-Tech’s KPI Development Tool (see following slide).
3. Update the data as necessary according to your SMART criteria of your goal.

A Word on Key Risk Indicators...

The term key risk indicator (KRI) gets used in a few different ways. However, in most cases, KRIs are closely associated with KPIs.

1. KPIs and KRIs are the same thing
   • A KPI, at its core, is really a measure of risk. Sometimes it is more effective to emphasize that risk rather than performance (i.e. the data shows you’re not meeting your goal).
2. KRI is KPI going the wrong way
   • After achieving the desired threshold for an improvement goal, our new goal is usually to maintain such a state. When this balance is upset, it indicates that settled risk has once again become active.
3. KRI as a predictor of emerging risks
   • When organizations reach a highly mature state, they often start assessing how events external to the organization can affect the optimal performance of the organization. They monitor such events or trends and try to predict when the organization is likely to face additional risks.

Track KPIs in the Security Metrics Determination and Tracking Tool

1.3 Security Metrics Determination and Tracking Tool

Once a metric has been measured, you have the option of entering that data into tab “4. Track Metrics” of the Tool.

Tracking metric data in Info-Tech's tool provides the following data visualizations:

• Sparklines at the end of each row (on tab “4. Track Metrics”) for a quick sense of metric performance.
• A metrics dashboard (on tab “5. Graphs”) with three graph options in two color variations for each metric tracked in the tool, and an overall metric program health gauge.

Info-Tech Best Practice

Be diligent about measuring and tracking your metrics. Record any potential measurement biases or comments on measurement values to ensure you have a comprehensive record for future use. In the tool, this can be done by adding a comment to a cell with a metric measurement.

If you want additional support, have our analysts guide you through this phase as part of an Info-Tech workshop

Book a workshop with our Info-Tech analysts:

Workshops offer an easy way to accelerate your project. While onsite, our analysts will work with you and your team to facilitate the activities outlined in the blueprint.

Getting key stakeholders together to formalize the program, while getting started on data discovery and classification, allows you to kickstart the overall program.

In addition, leverage over-the-phone support through Guided Implementations included in advisory memberships to ensure the continuous improvement of the classification program even after the workshop.

Logan Rohde

Research Analyst – Security, Risk & Compliance Info-Tech Research Group

Ian Mulholland

Senior Research Analyst – Security, Risk & Compliance Info-Tech Research Group

Call 1-888-670-8889 for more information.

Phase 2

Adapt Your Reporting Strategy for Various Metric Types

Phase 2

2.1 Review best practices for presenting metrics

2.2 Strategize your presentation based on metric type

2.3 Tailor your presentation to your audience

2.4 Use your metrics to create a story about risk

2.5 Revise Metrics

This phase will walk you through the following activities:

• Develop reporting strategy
• Use metrics to create a story about risk
• Metrics revision

This phase involves the following participants:

• Security Team

Outcomes of this phase

• Metrics Dashboard
• Metrics Presentation Deck

Phase 2 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Complete these steps on your own or call us to complete a guided implementation. A guided implementation is a series of two to three advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Guided Implementation 2: Adapt Your Reporting Strategy for Various Metric Types

Proposed Time to Completion: 2-4 weeks

Step 2.1 – 2.3: Best Practices and Reporting Strategy

Start with an analyst kick-off call:

• Do’s and Don’ts of reporting metrics.
• Strategize presentation based on metric type.

Then complete these activities…

• Strategy development for 3-5 metrics

Step 2.4 – 2.5: Build a Dashboard and Presentation Deck

Review findings with analyst:

• Review strategies for reporting.
• Compile a Key Performance Index.
• Revise metrics.

Then complete these activities…

• Dashboard creation
• Presentation development

With these tools & templates:

• Security Metrics Determination and Tracking Tool Template
• Security Metrics KPX Dashboard Tool

Phase 2 Results & Insights:

• Completed reporting strategy with presentable dashboard

2.1 Review best practices for presenting metrics

Avoid technical details (i.e. raw data) by focusing on the KPI.

• KPIs add context to understand the behavior and associated risks.

Put things in terms of risk; it's the language you both understand.

• This usually means explaining what will happen if not addressed and what you recommend.
• There are always three options:
  • Address it completely
  • Address it partially
  • Do not address it (i.e. accept the risk)

Explain why you’re monitoring metrics in terms of the goals you’re hoping to achieve.

• This sets you up well to explain what you've been doing and why it's important for you to meet your goals.

Choose between KPI or KRI as the presentation format.

• Base your decision on whether you are trying to emphasize current success or risk.

Match presentation with the audience.

• Board presentations will be short; middle-management ones may be a bit longer.
• Maximize your results by focusing on the minimum possible information to make sure you sufficiently get your point across.
• With the board, plan on showing no more than three slides.

Read between the lines.

• It can be difficult to get time with the board, so you may find yourself in a trial and error position, so pay attention to cues or suggestions that indicate the board is interested in something.
• If you can, make an ally to get the inside scoop on what the board cares about.

Read the news if you’re stuck for content.

• Board members are likely to have awareness (and interest) in large-scale risks like data breaches and ransomware.

Present your metrics as a story.

• Summarize how the security program looks to you and why the metrics lead you to see it this way.

2.2 Strategize your presentation based on metric type (1 of 5)

Metric Type: Initial Probe

Scenario: Implementing your first metrics program.

• All metrics programs start with determining what measurements you are capable of taking.

Decisions: Do you have sufficient insight into the program? (i.e. do you need to acquire additional tools to collect metrics?)

Strategy: If there are no barriers to this (e.g. budget), then focus your presentation on the fact that you are addressing the risk of not knowing what your organization's baseline state is and what potential issues exist but are unknown. This is likely the first phase of an improvement plan, so sketching the overall plan is a good idea too.

• If budget is an issue, explain the risks associated with not knowing and what you would need to make it happen.

Possible KPIs:

• % of project complete.
• % of systems that provide worthwhile metrics.

Strategize your presentation based on metric type (2 of 5)

Metric Type: Baseline Testing

Scenario: You've taken the metrics to determine what your organization’s normal state is and you're now looking towards addressing your gaps or problem areas.

Decisions: What needs to be prioritized first and why? Are additional resources required to make this happen?

Strategy: Explain your impression of the organization's normal state and what you plan to do about it. In other words, what goals are you prioritizing and why? Be sure to note any challenges that may occur along the way (e.g. staffing).

• If the board doesn't like to open their pocketbook, your best play is to explain what stands to happen (or is happening) if risks are not addressed.

Possible KPIs:

• % of goals complete.
• % of metrics indicating urgent attention needed.

Strategize your presentation based on metric type (3 of 5)

Metric Type: Implementation

Scenario: You are now implementing solutions to address your security priorities.

Decisions: What, to you, would establish the basis of a program?

Strategy: Focus on what you're doing to implement a certain security need, why, and what still needs to be done when you’re finished.

• Example: To establish a training and awareness program, a good first step is to actually hold training sessions with each department. A single lecture is simple but something to build from. A good next step would be to hold regular training sessions or implement monthly phishing tests.

Possible KPIs:

• % of implementation complete (e.g. % of departments trained).

Strategize your presentation based on metric type (4 of 5)

Metric Type: Improvement

Scenario: Now that a basic program has been established, you are looking to develop its maturity to boost overall performance (i.e. setting a new development goal).

Decisions: What is a reasonable target, given the organization's risk tolerance and current state?

Strategy: Explain that you're now working to tighten up the security program. Note that although things are improving, risk will always remain, so we need to keep it within a threshold that’s proportionate with our risk tolerance.

• Example: Lower phishing-test click rate to 10% or less. Phishing will always be a risk, and just one slip up can have a huge effect on business (i.e. lost money).

Possible KPIs:

• % of staff passing the phishing test.
• % of employees reporting phishing attempts within time window.

Strategize your presentation based on metric type (5 of 5)

Metric Type: Organizational Trends

Scenario: You've reached a mature state and now how several KPIs being tracked. You begin to look at several KPIs together (i.e. a KPX) to assess the organization's exposure for certain broad risk trends.

Decisions: Which KPIs can be used together to look at broader risks?

Strategy: Focus on the overall likelihood of a certain risk and why you've chosen to assess it with your chosen KPIs. Spend some time discussing what factors affect the movement of these KPIs, demonstrating how smaller behaviors create a ripple effect that affects the organization’s exposure to large-scale risks.

Possible KPX: Insider Threat Risk

• % of phishing test failures.
• % of critical patches missed.
• % of accounts with unnecessary privileges.

Change your strategy to address security challenges

Even challenges can elicit useful metrics.

Not every security program is capable of progressing smoothly through the various metric types. In some cases, it is impossible to move towards goals and metrics for implementation, improvement, or organizational trends because the security program lacks resources.

Info-Tech Insight

When your business is suffering from a lack of resources, acquiring these resources automatically becomes the goal that your metrics should be addressing. To do this, focus on what risks are being created because something is missing.

When your security program is lacking a critical resource, such as staff or technology, your metrics should focus on what security processes are suffering due to this lack. In other words, what critical activities are not getting done?

KPI Examples:

• % of critical patches not deployed due to lack of staff.
• % of budget shortfall to acquire vulnerability scanner.
• % of systems with unknown risk due to lack of vulnerability scanner.

2.3 Tailor presentation to your audience

Metrics come in three forms...

1. Raw Data

• Taken from logs or reports, provides values but not context.
• Useful for those with technical understanding of the organization’s security program.

2. Management-Level

• Raw data that has been contextualized and indicates performance of something (i.e. a KPI).
• Useful for those with familiarity with the overall state of the security program but do not have a hands-on role.

3. Board-Level

• KPI with additional context indicating overall effect on the organization.
• Useful for those removed from the security program but who need to understand the relationship between security, business goals, and cyber risk.

For a metric to be useful it must...

1. Be understood by the audience it’s being presented to.
   • Using the criteria on the left, choose which metric form is most appropriate.
2. Indicate whether or not a certain target or goal is being met.
   • Don’t expect metrics to speak for themselves; explain what the indications and implications are.
3. Drive some kind of behavioral or strategic change if that target or goal is not being met.
   • Metrics should either affirm that things are where you want them to be or compel you to take action to make an improvement. If not, it is not a worthwhile metric.

As a general rule, security metrics should become decreasingly technical and increasingly behavior-based as they are presented up the organizational hierarchy.

"The higher you travel up the corporate chain, the more challenging it becomes to create meaningful security metrics. Security metrics are intimately tied to their underlying technologies, but the last thing the CEO cares about is technical details." – Ben Rothke, Senior Information Security Specialist, Tapad.

Plan for reporting success

The future of your security program may depend on this presentation; make it count.

Reporting metrics is not just another presentation. Rather, it is an opportunity to demonstrate and explain the value of security.

It is also a chance to correct any misconceptions about what security does or how it works.

Use the tips on the right to help make your presentation as relatable as possible.

Info-Tech Insight

There is a difference between data manipulation and strategic presentation: the goal is not to bend the truth, but to present it in a way that allows you to show the board what they need to see and to explain it in terms familiar to them.

General Tips for a Successful Presentation

Avoid jargon; speak in practical terms

• The board won’t receive your message if they can’t understand you.
• Explain things as simply as you can; they only need to know enough to make decisions about addressing cyber risk.

Address compliance

• Boards are often interested in compliance, so be prepared to talk about it, but clarify that it doesn't equal security.
• Instead, use compliance as a bridge to discussing areas of the security program that need attention.

Have solid answers

• Try to avoid answering questions with the answer, “It depends.”
  • Depends on what?
  • Why?
  • What do you recommend?
• The board is relying on you for guidance, so be prepared to clarify what the board is asking (you may have to read between the lines to do this).
• Also address the pain points of board members and have answers to their questions about how to resolve them.

2.4 Use your metrics to create a story about risk

Become the narrator of your organization’s security program.

Security is about managing risk. This is also its primary value to the organization. As such, risk should be the theme of the story you tell.

"Build a cohesive story that people can understand . . . Raw metrics are valuable from an operations standpoint, but at the executive level, it's about a cohesive story that helps executives understand the value of the security program and keeps the company moving forward. "– Adam Ely, CSO and Co-Founder, Bluebox Security, qtd. by Tenable, 2016

How to Develop Your Own Story...

1. Review your security program goals and the metrics you’re using to track progress towards them. Then, decide which metrics best tell this story (i.e. what you’re doing and why).
   • Less is more when presenting metrics, so be realistic about how much your audience can digest in one sitting.
   • Three metrics is usually a safe number; choose the ones that are most representative of your goals.
2. Explain why you chose the goals you did (i.e. what risks were you addressing?). Then, make an honest assessment of how the security program is doing as far as meeting those goals:
   • What’s going well?
   • What still needs improvement?
   • What about your metrics suggests this?
3. Address how risks have changed and explain your new recommended course of action.
   • What risks were present when you started?
   • What risks remain despite your progress?
   • How do these risks affect the business operation and what can security do to help?

Story arc for security metrics

The following model encapsulates the basic trajectory of all story development.

Use this model to help you put together your story about risk.

Introduction: Overall assessment of security program.

Initial Incident: Determination of the problems and associated risks.

Rising Action: Creation of goals and metrics to measure progress.

Climax: Major development indicated by metrics.

Falling Action: New insights gained about organization’s risks.

Resolution: Recommendations based on observations.

Info-Tech Best Practice

Follow this model to ensure that your metrics presentation follows a coherent storyline that explains how you assessed the problem, why you chose to address it the way you did, what you learned in doing so, and finally what should be done next to boost the security program’s maturity.

Use a nesting-doll approach when presenting metrics

Move from high-level to low-level to support your claims

1. Avoid the temptation to emphasize technical details when presenting metrics. The importance of a metric should be clear from just its name.
2. This does not mean that technical details should be disregarded entirely. Your digestible, high-level metrics should be a snapshot of what’s taking place on the security ground floor.
3. With this in mind, we should think of our metrics like a nesting doll, with each metrics level being supported by the one beneath it.

...How do you know that?

Board-Level KPI

Mgmt.-Level KPI

Raw Data

Think of your lower-level metrics as evidence to back up the story you are telling.

When you’re asked how you arrived at a given conclusion, you know it’s time to go down a level and to explain those results.

Think of this like showing your work.

Info-Tech Insight

This approach is built into the KPX reporting format, but can be used for all metric types by drawing from your associated metrics and goals already achieved.

Use one of Info-Tech’s dashboards to present your metrics

2.4 Security Metrics Determination and Tracking Tool

Choose the dashboard tool that makes the most sense for you.

Info-Tech provides two options for metric dashboards to meet the varying needs of our members.

If you’re just starting out, you’ll likely be inclined towards the dashboard within the Security Metrics Determination and Tracking Tool (seen here).

But if you’ve already got several KPIs to report on, you may prefer the Security Metrics KPX Dashboard Tool, featured on the following slides.

Info-Tech Best Practice

Not all graphs will be needed in all cases. When presenting, consider taking screenshots of the most relevant data and displaying them in Info-Tech’s Board-Level Security Metrics Presentation Template.

Use one of Info-Tech’s dashboards to present your metrics

2.4 Security Metrics KPX Dashboard

Use Info-Tech’s Security Metrics KPX Dashboard to track and show your work.

1. Start by customizing the definitions on tab 1 to match your organization’s understanding of high, medium, and low risk across the three impact areas (functional, informational, and recoverability).
2. Next, enter up to 5 business goals that your security program supports.

Use one of Info-Tech’s dashboards to present your metrics

2.4 Security Metrics KPX Dashboard

Use Info-Tech’s Security Metrics KPX Dashboard to track and show your work.

3. On tab 2, enter the large-scale risk you are tracking
4. Proceed by naming each of your KPXs after three broad risks that – to you – contribute to the large-scale risk.

Use one of Info-Tech’s dashboards to present your metrics

2.4 Security Metrics KPX Dashboard

Use Info-Tech’s Security Metrics KPX Dashboard to track and show your work.

5. Then, add up to five KPIs aimed at managing more granular risks that contribute to the broad risk.
6. Assess the frequency and impact associated with these more granular risks to determine how likely it is to contribute to the broad risk the KPX is tracking.

Use one of Info-Tech’s dashboards to present your metrics

2.4 Security Metrics KPX Dashboard

Use Info-Tech’s Security Metrics KPX Dashboard to track and show your work.

7. Repeat as necessary for the other KPXs on tab 2.
8. Repeat steps 3-7 for up to two more large-scale risks and associated KPXs on tabs 3 and 4.

Use one of Info-Tech’s dashboards to present your metrics

2.4 Security Metrics KPX Dashboard

Use Info-Tech’s Security Metrics KPX Dashboard to track and show your work.

9. If desired, complete the Business Alignment evaluation (located to the right of KPX 2 on tabs 2-4) to demonstrate how well security is supporting business goals.

"An important key to remember is to be consistent and stick to one framework once you've chosen it. As you meet with the same audiences repeatedly, having the same framework for reference will ensure that your communications become smoother over time." – Caroline Wong, Chief Strategy Officer, Cobalt.io

Use one of Info-Tech’s dashboards to present your metrics

2.4 Security Metrics KPX Dashboard

Use Info-Tech’s Security Metrics KPX Dashboard to track and show your work.

10. Use the dashboard on tab 5 to help you present your security metrics to senior leadership.

Use one of Info-Tech’s dashboards to present your metrics

2.4 Security Metrics KPX Dashboard

Use Info-Tech’s Security Metrics KPX Dashboard to track and show your work.

Best Practice:

This tool helps you convert your KPIs into the language of risk by assessing frequency and severity, which helps to make the risk relatable for senior leadership. However, it is still useful to track fluctuations in terms of percentage. To do this, track changes in the frequency, severity, and trend scores from quarter to quarter.

Customize Info-Tech’s Security Metrics Presentation Template

2.4 Board-Level Security Metrics Presentation Template

Use the Board-Level Security Metrics Presentation Template deck to help structure and deliver your metrics presentation to the board.

To make the dashboard slide, simply copy and paste the charts from the dashboard tool and arrange the images as needed.

Adapt the status report and business alignment slides to reflect the story about risk that you are telling.

2.5 Revise your metrics

What's next?

Now that you’ve made it through your metrics presentation, it’s important to reassess your goals with feedback from your audience in mind. Use the following workflow.

If you want additional support, have our analysts guide you through this phase as part of an Info-Tech workshop

Book a workshop with our Info-Tech analysts:

Workshops offer an easy way to accelerate your project. While onsite, our analysts will work with you and your team to facilitate the activities outlined in the blueprint.

Getting key stakeholders together to formalize the program, while getting started on data discovery and classification, allows you to kickstart the overall program.

In addition, leverage over-the-phone support through Guided Implementations included in advisory memberships to ensure the continuous improvement of the classification program even after the workshop.

Logan Rohde

Research Analyst – Security, Risk & Compliance Info-Tech Research Group

Ian Mulholland

Senior Research Analyst – Security, Risk & Compliance Info-Tech Research Group

Call 1-888-670-8889 for more information.

Insight breakdown

Metrics lead to maturity, not vice versa.

• Tracking metrics helps you assess progress and regress in your security program, which helps you quantify the maturity gains you’ve made.

Don't lose hope if you lack resources to move beyond baseline testing.

• Even if you are struggling to pull data, you can still draw meaningful metrics. The percent or ratio of processes or systems you lack insight into can be very valuable, as it provides a basis to initiate a risk-based discussion with management about the organization's security blind spots.

The best metrics are tied to goals.

• Tying your metrics to goals ensures that you are collecting metrics for a specific purpose rather than just to watch the numbers change.

Summary of accomplishment

Knowledge Gained

• Current maturity assessment of security areas
• Setting SMART goals
• Metric types
• KPI development
• Goals prioritization
• Reporting and revision strategies

Processes Optimized

• Metrics development
• Metrics collection
• Metrics reporting

Deliverables Completed

• KPI Development Worksheet
• Security Metrics Determination and Tracking Tool
• Security Metrics KPX Dashboard Tool
• Board-Level Security Metrics Presentation Template

Research contributors and experts

Mike Creaney, Senior Security Engineer at Federal Home Loan Bank of Chicago

Peter Chestna, Director, Enterprise Head of Application Security at BMO Financial Group

Zane Lackey, Co-Founder / Chief Security Officer at Signal Sciences

Ben Rothke, Senior Information Security Specialist at Tapad

Caroline Wong, Chief Strategy Officer at Cobalt.io

2 anonymous contributors

Related Info-Tech research

Build an Information Security Strategy

Tailor best practices to effectively manage information security.

Implement a Security Governance and Management Program

Align security and business objectives to get the greatest benefit from both.

Bibliography

Capability Maturity Model Integration (CMMI). ISACA. Carnegie Mellon University.

Ely, Adam. “Choose Security Metrics That Tell a Story.” Using Security Metrics to Drive Action: 33 Experts Share How to Communicate Security Program Effectiveness to Business Executives and the Board Eds. 2016. Web.

https://www.ciosummits.com/Online_Assets_Tenable_eBook-_Using_Security_Metrics_to_Drive_Action.pdf

ISACA. “Board Director Concerns about Cyber and Technology Risk.” CSX. 11 Sep. 2018. Web.

Rothke, Ben. “CEOs Require Security Metrics with a High-Level Focus.” Using Security Metrics to Drive Action: 33 Experts Share How to Communicate Security Program Effectiveness to Business Executives and the Board Eds. 2016. Web.

https://www.ciosummits.com/Online_Assets_Tenable_eBook-_Using_Security_Metrics_to_Drive_Action.pdf

Wong, Caroline. Security Metrics: A Beginner’s Guide. McGraw Hill: New York, 2012.

Optimize IT Change Management

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

EXECUTIVE BRIEF

Analyst Perspective

Balance risk and efficiency to optimize IT change management.

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

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

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

Executive Summary

Your Challenge

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

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

Common Obstacles

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

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

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

Info-Tech’s Approach

Info-Tech’s approach will help you:

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

Balance Risk and Efficiency to Optimize IT Change Management

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

Your challenge

This research is designed to help organizations who need to:

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

Change management is heavily reliant on organizational culture

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

Increase the Effectiveness of Change Management in Your Organization

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

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

Common obstacles

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

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

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

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

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

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

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

Info-Tech’s approach

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

The Info-Tech difference:

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

IT change is constant and is driven by:

Change Management:

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

Insight summary

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

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

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

Use an objective framework for estimating risk

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

Integrate your change process with your IT service management system

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

Change management and DevOps can work together effectively

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

Change management and DevOps can coexist

Shift the responsibility and rigor to earlier in the process.

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

DEVOPS CALLOUTS

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

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

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

IT Benefits

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

Business Benefits

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

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

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

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

Control

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

Collaboration

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

Consistency

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

Confidence

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

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

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

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

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

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

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

Importance Scores

No importance: 1.0-6.9

Limited importance: 7.0-7.9

Significant importance: 8.0-8.9

Critical importance: 9.0-10.0

Effectiveness Scores

Not in place: n/a

Not effective: 0.0-4.9

Somewhat Ineffective: 5.0-5.9

Somewhat effective: 6.0-6.9

Very effective: 7.0-10.0

There are several common misconceptions about change management

Which of these have you heard in your organization?

Overcome perceived challenges to implementing change management to reap measurable reward

Before: Informal Change Management

Change Approval:

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

Change Prioritization

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

Change Deployment

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

After: Right-Sized Change Management

Change Approval

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

Change Prioritization

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

Change deployment

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

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

Blueprint deliverables

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

Change Management Process Library

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

Change Management Risk Assessment Tool

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

Project Summary Template

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

Change Management Roadmap Tool

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

Key Deliverable:

Change Management SOP

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

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

Define Change Management

Establish Roles and Workflows

Define RFC and Post-Implementation Activities

Measure, Manage, and Maintain

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

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

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

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

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

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

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

Case Study

Industry: Technology

Source: Daniel Grove, Intel

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

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

ITIL Change Management Implementation

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

Results

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

Define Change Management

↓

Establish Roles and Workflows

↓

Define RFC and Post-Implementation Activities

↓

Measure, Manage, and Maintain

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

DIY Toolkit

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

Guided Implementation

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

Workshop

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

Consulting

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

Diagnostics and consistent frameworks are used throughout all four options.

Guided Implementation

What does a typical GI on this topic look like?

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

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

Define Change Management

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

Establish Roles and Workflows

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

Define RFC and Post- Implementation Activities

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

Measure, Manage, and Maintain

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

Workshop Overview

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

Phase 1

Define Change Management

Define Change Management

1.1 Assess Maturity

1.2 Categorize Changes and Build Your Risk Assessment

Establish Roles and Workflows

2.1 Determine Roles and Responsibilities

2.2 Build Core Workflows

Define the RFC and Post-Implementation Activities

3.1 Design the RFC

3.2 Establish Post-Implementation Activities

Measure, Manage, and Maintain

4.1 Identify Metrics and Build the Change Calendar

4.2 Implement the Project

This phase will guide you through the following steps:

• Assess Maturity
• Categorize Changes and Build Your Risk Assessment

This phase involves the following participants:

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

Step 1.1

Assess Maturity

Activities

1.1.1 Outline the Organization’s Strengths and Challenges

1.1.2 Complete a Maturity Assessment

This step involves the following participants:

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

Outcomes of this step

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

Define Change Management

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

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

Change

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

Release

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

Info-Tech Insight

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

Integrate change management with other IT processes

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

Avoid the challenges of poor change management

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

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

1.1.1 Outline the Organization’s Strengths and Challenges

Input

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

Output

• List of strengths and challenges for change management

Materials

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

Participants

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

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

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

Assess current change management maturity to create a plan for improvement

Info-Tech Insight

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

1.1.2 Complete a Maturity Assessment

Input

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

Output

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

Materials

• Change Management Maturity Assessment Tool

Participants

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

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

Download the Change Management Maturity Assessment Tool

Case Study

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

Industry: Technology

Source: The Register

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

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

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

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

Solution

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

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

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

Step 1.2

Categorize Changes and Build Your Risk Assessment

Activities

1.2.1 Define What Constitutes a Change

1.2.2 Build a Change Categorization Scheme

1.2.3 Build a Classification Scheme to Assess Impact

1.2.4 Build a Classification Scheme to Define Likelihood

1.2.5 Evaluate and Adjust Your Risk Assessment Scheme

Define Change Management

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

This step involves the following participants:

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

Outcomes of this step

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

Change must be managed to mitigate risk to the infrastructure

Change management is the gatekeeper protecting your live environment.

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

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

80%

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

Attributes of a change

Differentiate changes from other IT requests

Is this in the production environment of a business process?

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

Does the task affect an enterprise managed system?

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

How many users are impacted?

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

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

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

Does the underlying service currently exist?

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

Is this done/requested by IT?

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

Will this take longer than one week?

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

Defining what constitutes a change

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

Do not treat every IT request as a change!

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

1.2.1 Define What Constitutes a Change

Input

• List of examples of each category of the chart

Output

• Definitions for each category to be used at change intake

Materials

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

Participants

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

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

Download the Change Management Standard Operating Procedure (SOP).

Each RFC should define resources needed to effect the change

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

Categories include

Normal

Emergency

Pre-Approved

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

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

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

Info-Tech Best Practice

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

The category of the change determines the process it follows

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

1.2.2 Build a Change Categorization Scheme

Input

• List of examples of each change category

Output

• Definitions for each change category

Materials

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

Participants

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

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

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

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

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

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

Consider risk

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

Info-Tech Insight

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

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

Every normal RFC should be assigned a risk rating.

How is risk rating determined?

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

Who determines priority?

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

How is risk rating used?

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

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

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

Risk Matrix

1.2.3 Build a Classification Scheme to Assess Impact

Input

• Current risk assessment (if available)

Output

• Tailored impact assessment

Materials

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

Participants

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

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

1.2.4 Build a Classification Scheme to Define Likelihood

Input

• Current risk assessment (if available)

Output

• Tailored likelihood assessment

Materials

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

Participants

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

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

1.2.5 Evaluate and Adjust Your Risk Assessment Scheme

Input

• Impact and likelihood assessments from previous two activities

Output

• Vetted risk assessment

Materials

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

Participants

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

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

Download the Change Management Rick Assessment Tool.

Case Study

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

Industry: Manufacturing

Source: Anonymous Info-Tech member

Challenge

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

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

This could have derailed the change management project.

Solution

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

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

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

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

Results

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

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

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

Case Study (part 1 of 4)

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

Industry: Technology

Source: Daniel Grove, Intel

Challenge

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

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

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

Solution

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

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

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

Results

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

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

Phase 2

Establish Roles and Workflows

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

Define Change Management

1.1 Assess Maturity

1.2 Categorize Changes and Build Your Risk Assessment

Establish Roles and Workflows

2.1 Determine Roles and Responsibilities

2.2 Build Core Workflows

Define RFC and Post-Implementation Activities

3.1 Design the RFC

3.2 Establish Post-Implementation Activities

Measure, Manage, and Maintain

4.1 Identify Metrics and Build the Change Calendar

4.2 Implement the Project

This phase will guide you through the following steps:

• Determine Roles and Responsibilities
• Build Core Workflows

This phase involves the following participants:

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

Step 2.1

Determine Roles and Responsibilities

Activities

2.1.1 Capture Roles and Responsibilities Using a RACI Chart

2.1.2 Determine Your Change Manager’s Responsibilities

2.1.3 Define the Authority and Responsibilities of Your CAB

2.1.4 Determine an E-CAB Protocol for Your Organization

Establish Roles and Workflows

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

This step involves the following participants:

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

Outcomes of this step

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

Identify roles and responsibilities for your change management team

Business System Owner

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

Technical Subject Matter Expert (SME)

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

CAB

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

Change Manager

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

2.1.1 Capture Roles and Responsibilities Using a RACI Chart

Input

• Current SOP

Output

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

Materials

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

Participants

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

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

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

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

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

Info-Tech Best Practice

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

Responsibilities

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

2.1.2 Document Your Change Manager’s Responsibilities

Input

• Current Change Manager job description (if available)

Output

• Change Manager job description and list of responsibilities

Materials

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

Participants

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

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

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

Example:

Change Manager: James Corey

Responsibilities

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

Download the Change Manager Job Description

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

The primary functions of the CAB are to:

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

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

Use diverse representation from the business to form an effective CAB

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

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

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

Info-Tech Best Practice

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

2.1.3 Define the Authority and Responsibilities of Your CAB

Input

• Current SOP or CAB charter (if available)

Output

• Documented list of CAB authorities and responsibilities

Materials

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

Participants

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

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

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

Example:

Establish an emergency CAB (E-CAB) protocol

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

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

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

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

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

Info-Tech Best Practice

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

2.1.4 Determine an E-CAB Protocol for Your Organization

Input

• Current SOP or CAB charter (if available)

Output

• E-CAB protocol

Materials

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

Participants

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

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

Example

Assemble E-CAB

Assess Change

Test (if Applicable)

Deploy Change

Create Retroactive RFC

Review With CAB

Step 2.2

Build Core Workflows

Activities

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

2.2.2 Create a Normal Change Process

2.2.3 Create a Pre-Approved Change Process

2.2.4 Create an Emergency Change Process

Establish Roles and Workflows

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

This step involves the following participants:

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

Outcomes of this step

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

Establishing Workflows: Change Management Lifecycle

Improve

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

Request

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

Assess

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

Plan

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

Approve

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

Implement

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

Establishing workflows: employ a SIPOC model for process definition

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

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

Supplier

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

Input

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

Process

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

Output

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

Customer

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

Optional Fields

Metrics

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

Controls

• Checkpoints to ensure process step quality.

Dependencies

• Other process steps that require the output.

RACI

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

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

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

Dependencies

Identify all components of the change.

Ask how changes will affect:

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

Business Impact

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

Your assessment should cover:

• Business processes
• User productivity
• Customer service
• BCPs

SLA Impact

Each new change can impact the level of service available.

Examine the impact on:

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

Required Resources

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

These include:

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

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

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

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

Services Impacted

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

Technical Teams Impacted

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

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

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

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

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

Input

• Current system ownership documentation

Output

• Documented reference for change requests (CMDB-lite)

Materials

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

Participants

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

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

Establishing workflows: create standards for change approvals to improve efficiency

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

Info-Tech Best Practice

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

Example:

Example process: Normal Change – Change Initiation

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

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

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

Example process: Normal Change – Technical Build and Test

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

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

Example process: Normal Change – Change Approval (CAB)

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

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

Example process: Normal Change – Change Implementation

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

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

2.2.2 Create a Normal Change Process

Input

• Current SOP/workflow library

Output

• Normal change process

Materials

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

Participants

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

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

Download the Change Management Process Library.

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

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

IT should flag changes they would like pre-approved:

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

Pre-approved changes are not exempt from due diligence:

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

Info-Tech Best Practice

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

Example process: Pre-Approved Change Process

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

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

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

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

Info-Tech Best Practice

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

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

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

2.2.3 Create a Pre-Approved Change Process

Input

• Current SOP/workflow library

Output

• Pre-approved change process

Materials

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

Participants

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

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

Reserve the emergency designation for real emergencies

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

Info-Tech Best Practice

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

Example process: Emergency Change Process

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

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

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

2.2.4 Create an Emergency Change Process

Input

• Current SOP/workflow library

Output

• Emergency change process

Materials

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

Participants

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

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

Case Study (part 2 of 4)

Intel implemented a robust change management process.

Industry: Technology

Source: Daniel Grove, Intel

Challenge

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

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

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

Solution

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

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

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

Results

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

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

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

Phase 3

Define the RFC and Post-Implementation Activities

Define Change Management

1.1 Assess Maturity

1.2 Categorize Changes and Build Your Risk Assessment

Establish Roles and Workflows

2.1 Determine Roles and Responsibilities

2.2 Build Core Workflows

Define the RFC and Post-Implementation Activities

3.1 Design the RFC

3.2 Establish Post-Implementation Activities

Measure, Manage, and Maintain

4.1 Identify Metrics and Build the Change Calendar

4.2 Implement the Project

This phase will guide you through the following activities:

• Design the RFC
• Establish Post-Implementation Activities

This phase involves the following participants:

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

Step 3.1

Design the RFC

Activities

3.1.1 Evaluate Your Existing RFC Process

3.1.2 Build the RFC Form

Define the RFC and Post-Implementation Activities

Step 3.1: Design the RFC

Step 3.2: Establish Post-Implementation Activities

This step involves the following participants:

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

Outcomes of this step

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

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

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

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

Info-Tech Insight

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

RFCs should contain the following information, at a minimum:

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

3.1.1 Evaluate Your Existing RFC Process

Input

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

Output

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

Materials

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

Participants

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

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

Download the Request for Change Form Template.

Design the RFC to encourage process buy-in

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

Draft:

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

Technical Build:

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

CAB:

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

Complete:

• Deploy changes:
  • Post-implementation review

Designing your RFC: RFC draft

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

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

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

Designing your RFC: technical build

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

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

Designing your RFC: approval and deployment

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

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

Standardize the request for change protocol

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

Info-Tech Best Practice

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

3.1.2 Build the RFC Form

Input

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

Output

• List of changes to the current RFC and RFC process

Materials

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

Participants

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

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

Case Study (part 3 of 4)

Intel implemented automated RFC form generation.

Industry: Technology

Source: Daniel Grove, Intel

Challenge

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

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

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

Solution

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

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

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

Results

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

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

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

Step 3.2

Establish Post-Implementation Activities

Activities

3.2.1 Determine When the CAB Would Reject Tested Changes

3.2.2 Create a Post-Implementation Activity Checklist

Define the RFC and Post-Implementation Activities

Step 3.1: Design RFC

Step 3.2: Establish Post-Implementation Activities

This step involves the following participants:

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

Outcomes of this step

• A formalized post-implementation process for continual improvement

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

Possible reasons the CAB would reject a change include:

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

Info-Tech Best Practice

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

Determine When the CAB Would Reject Tested Changes

Input

• Current SOP (if available)

Output

• List of reasons to reject tested changes

Materials

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

Participants

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

Avoid hand-offs to ensure a smooth implementation process

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

1.

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

Implement change →

2.

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

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

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

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

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

Notify the Service Desk

• Notify the Service Desk about backout plan initiation.

Disable Access

• Disable user access to affected system(s).

Conduct Checks

• Conduct checks to all affected components.

Enable User Access

• Enable user access to affected systems.

Notify the Service Desk

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

Info-Tech Best Practice

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

Ensure the following post-implementation review activities are completed

Service Catalog

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

CMDB

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

Asset DB

Add notes about any assets newly affected by changes.

Architecture Map

Update your map based on the new change.

Technical Documentation

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

Training Documentation

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

Use a post-implementation review process to promote continual improvement

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

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

Info-Tech Best Practice

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

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

Determine the strategy for your PIR to establish a standardized process

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

3.2.2 Create a Post-Implementation Activity Checklist

Input

• Current SOP (if available)

Output

• List of reasons to reject tested changes

Materials

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

Participants

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

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

Download the Change Management Post-Implementation Checklist

Case Study

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

Industry: Technology

Source: Jason Zander, Microsoft

Challenge

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

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

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

Solution

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

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

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

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

Results

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

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

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

Phase 4

Measure, Manage, and Maintain

Define Change Management

1.1 Assess Maturity

1.2 Categorize Changes and Build Risk Assessment

Establish Roles and Workflows

2.1 Determine Roles and Responsibilities

2.2 Build Core Workflows

Define RFC and Post-Implementation Activities

3.1 Design RFC

3.2 Establish post-implementation activities

Measure, Manage, and Maintain

4.1 Identify Metrics and Build the Change Calendar

4.2 Implement the Project

This phase will guide you through the following activities:

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

This phase involves the following participants:

• CIO/IT Director
• IT Managers
• Change Manager

Step 4.1

Identify Metrics and Build the Change Calendar

Activities

4.1.1 Create an Outline for Your Change Calendar

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

4.1.3 Track and Record Metrics Using the Change Management Metrics Tool

Measure, Manage, and Maintain

Step 4.1: Identify Metrics and Build the Change Calendar

Step 4.2: Implement the Project

This step involves the following participants:

• CIO/IT Director
• IT Managers
• Change Manager

Outcomes of this step

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

Enforce a standard method of prioritizing and scheduling changes

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

Risk of Not Deploying

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

Positive Impact of Deployment

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

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

Info-Tech Insight

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

Develop a change schedule to formalize the planning process

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

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

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

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

Roles

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

Inputs

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

Guidelines

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

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

4.1.1 Create Guidelines for Your Change Calendar

Input

• Current change calendar guidelines

Output

• Change calendar inputs and schedule checklist

Materials

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

Participants

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

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

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

Number of change-related incidents that occur each month

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

Number of unauthorized changes applied each month

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

Percentage of emergency changes

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

Info-Tech Insight

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

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

Improve

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

Request

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

Assess

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

Plan

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

Approve

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

Implement

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

Use metrics to inform project KPIs and CSFs

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

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

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

Metrics:

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

KPIs:

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

CSFs:

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

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

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

Input

• Current metrics

Output

• List of trackable metrics, KPIs and CSFs

Materials

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

Participants

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

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

Measure changes in selected metrics to evaluate success

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

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

Outcomes of standardizing change management should include:

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

Info-Tech Best Practice

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

4.1.3 Track and Record Metrics Using the Change Management Metrics Tool

Input

• Current metrics

Output

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

Materials

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

Participants

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

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

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

Download the Change Management Metrics Tool

Case Study

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

Industry: Federal Credit Union (anonymous)

Source: Info-Tech Workshop

Challenge

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

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

Solution

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

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

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

Results

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

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

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

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

Step 4.2

Implement the Project

Activities

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

4.2.2 Create a Project Roadmap to Track Your Implementation Progress

Measure, Manage, and Maintain

Step 4.1: Identify Metrics and Build the Change Calendar

Step 3.2: Implement the Project

This step involves the following participants:

• CIO/IT Director
• IT Managers
• Change Manager

Outcomes of this step

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

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

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

Info-Tech Best Practice

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

Main Challenges with Communication

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

Educate affected stakeholders to prepare for organizational change

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

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

Host a lunch-and-learn session

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

Communicate the new process to all affected stakeholders

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

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

Info-Tech Insight

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

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

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

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

Management

Technicians

Business Stakeholders

Provide separate communications to key stakeholder groups

Why? What problems are you trying to solve?

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

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

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

How? How will these changes manifest themselves?

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

Info-Tech Insight

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

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

Input

• List of stakeholder groups for change management

Output

• Tailored communications plans for various stakeholder groups

Materials

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

Participants

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

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

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

Download the Change Management Communications Plan

Present your SOP to key stakeholders and obtain their approval

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

Know your audience:

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

Info-Tech Insight

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

Download the Change Management Project Summary Template

4.2.2 Create a Project Roadmap to Track Your Implementation Progress

Input

• List of implementation tasks

Output

• Roadmap and timeline for change management implementation

Materials

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

Participants

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

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

Download the Change Management Roadmap Tool

Case Study (part 4 of 4)

Intel implemented a robust change management process.

Industry: Technology

Source: Daniel Grove, Intel

Challenge

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

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

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

Solution

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

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

Top-level buy-in was another concern.

Results

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

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

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

Summary of Accomplishment

Problem Solved

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

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

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

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

Contact your account representative for more information.

workshops@infotech.com

1-888-670-8889

Additional Support

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

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

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

Contact your account representative for more information.

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

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

1.1.2 Complete a Change Management Maturity Assessment

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

2.2.1 Plot the Process for a Normal Change

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

Related Info-Tech Research

Standardize the Service Desk

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

Stabilize Release and Deployment Management

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

Incident and Problem Management

Don’t let persistent problems govern your department.

Select Bibliography

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Appendix I: Expedited Changes

Employ the expedited change to promote process adherence

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

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

Two possible ways to build an expedited change category”

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

Example process: Expedited Change Process

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

Appendix II: Optimize IT Change Management in a DevOps Environment

Change Management cannot be ignored because you are DevOps or Agile

But it can be right-sized.

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

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

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

Five principals for implementing change in DevOps

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

People

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

DevOps Lifecycles

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

Automation

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

Contingencies

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

Continually Improve

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

Increasing the proportion of pre-approved changes

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

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

Turn your CAB into a virtual one

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