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.

Create a Transparent and Defensible IT Budget

Build in approvability from the start.

EXECUTIVE BRIEF

Analyst Perspective

A budget’s approvability is about transparency and rationale, not the size of the numbers.

It’s that time of year again – budgeting. Most organizations invest a lot of time and effort in a capital project selection process, tack a few percentage points onto last year’s OpEx, do a round of trimming, and call it a day. However, if you want to improve IT financial transparency and get your business stakeholders and the CFO to see the true value of IT, you need to do more than this. Yourcrea IT budget is more than a once-a-year administrative exercise. It’s an opportunity to educate, create partnerships, eliminate nasty surprises, and build trust. The key to doing these things rests in offering a range of budget perspectives that engage and make sense to your stakeholders, as well as providing iron-clad rationales that tie directly to organizational objectives. The work of setting and managing a budget never stops – it’s a series of interactions, conversations, and decisions that happen throughout the year. If you take this approach to budgeting, you’ll greatly enhance your chances of creating and presenting a defensible annual budget that gets approved the first time around.

Jennifer Perrier Principal Research Director IT Financial Management Practice Info-Tech Research Group

Executive Summary

Info-Tech Insight
CIOs need a straightforward way to create and present an approval-ready IT budget that demonstrates the value IT is delivering to the business and speaks directly to different stakeholder priorities.

IT struggles to get budgets approved due to low transparency and failure to engage

Reflect on the numbers…

To move forward, first you need to get unstuck

Today’s IT budgeting challenges have been growing for a long time. Overcoming these challenges means untangling yourself from the grip of the root causes.

The three principles above are all about IT’s changing relationship to the business. IT leaders need a systematic and repeatable approach to budgeting that addresses these principles by:

• Clearly illustrating the alignment between the IT budget and business objectives.
• Showing stakeholders the overall value that IT investment will bring them.
• Demonstrating where IT is already realizing efficiencies and economies of scale.
• Gaining consensus on the IT budget from all parties affected by it.

“The culture of the organization will drive your success with IT financial management.”

– Dave Kish, Practice Lead, IT Financial Management Practice, Info-Tech Research Group

Info-Tech’s approach

CIOs need a straightforward way to convince approval-granting CFOs, CEOs, boards, and committees to spend money on IT to advance the organization’s strategies.

IT budget approval cycle

The Info-Tech difference:

This blueprint provides a framework, method, and templated exemplars for building and presenting your IT budget to different stakeholders. These will speed the approval process and ensure that a higher percentage of your proposed spend is approved.

Info-Tech’s methodology for how to create a transparent and defensible it budget

Insight summary

Overarching insight: Create a transparent and defensible IT budget

CIOs need a straightforward way to create and present an approval-ready IT budget that demonstrates the value IT is delivering to the business and speaks directly to different stakeholder priorities.

Phase 1 insight: Lay your foundation

IT needs to step back and look at it’s budget-creation process by first understanding exactly what a budget is intended to do and learning what the IT budget means to IT’s various business stakeholders.

Phase 2 Insight: Get into budget-starting position

Presenting your proposed IT budget in the context of past IT expenditure demonstrates a pattern of spend behavior that is fundamental to next year’s expenditure rationale.

Phase 3 insight: Develop your forecasts

Forecasting costs according to a range of views, including CapEx vs. OpEx and project vs. non-project, and then positioning it according to different stakeholder perspectives, is key to creating a transparent budget.

Phase 4 insight: Build your proposed budget

Fine-tuning and hardening the rationales behind every aspect of your proposed budget is one of the most important steps for facilitating the budgetary approval process and increasing the amount of your budget that is ultimately approved.

Phase 5 insight: Create and deliver your budget presentation

Selecting the right content to present to your various stakeholders at the right level of granularity ensures that they see their priorities reflected in IT’s budget, driving their interest and engagement in IT financial concerns.

Blueprint deliverables

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

IT Cost Forecasting and Budgeting Workbook This Excel tool allows you to capture and work through all elements of your IT forecasting from the perspective of multiple key stakeholders and generates compelling visuals to choose from to populate your final executive presentation.

Also download this completed sample:

Sample: IT Cost Forecasting and Budgeting Workbook

Key deliverable

IT Budget Executive Presentation Template

Phase 5: Create a focused presentation for your proposed IT budget that will engage your audience and facilitate approval.

Blueprint benefits

Measure the value of this blueprint

Ease budgetary approval and improve its accuracy.

Near-term goals

• Percentage of budget approved: Target 95%
• Percentage of IT-driven projects approved: Target 100%
• Number of iterations/re-drafts required to proposed budget: One iteration

Long-term goal

• Variance in budget vs. actuals: Actuals less than budget and within 2%

In Phases 1 and 2 of this blueprint, we will help you understand what your approvers are looking for and gather the right data and information.

In Phase 3, we will help you forecast your IT costs it terms of four stakeholder views so you can craft a more meaningful IT budget narrative.

In Phases 4 and 5, we will help you build a targeted presentation for your proposed IT budget.

Value you will receive:

1. Increased forecast accuracy through using a sound cost-forecasting methodology.
2. Improved budget accuracy by applying more thorough and transparent techniques.
3. Increased budget transparency and completeness by soliciting input earlier and validating budgeting information.
4. Stronger alignment between IT and enterprise goals through building a better understanding of the business values and using language they understand.
5. A more compelling budget presentation by offering targeted, engaging, and rationalized information.
6. A faster budgeting rework process by addressing business stakeholder concerns the first time.

An analogy…

“A budget isn’t like a horse and cart – you can’t get in front of it or behind it like that. It’s more like a river…

When developing an annual budget, you have a good idea of what the OpEx will be – last year’s with an annual bump. You know what that boat is like and if the river can handle it.

But sometimes you want to float bigger boats, like capital projects. But these boats don’t start at the same place at the same time. Some are full of holes. And does your river even have the capacity to handle a boat of that size?

Some organizations force project charters by a certain date and only these are included in the following year’s budget. The project doesn’t start until 8-12 months later and the charter goes stale. The river just can’t float all these boats! It’s a failed model. You have to have a great governance processes and clear prioritization so that you can dynamically approve and get boats on the river throughout the year.”

– Mark Roman, Managing Partner, Executive Services,
Info-Tech Research Group and Former Higher Education CIO

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

Guided Implementation

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

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

Workshop Overview

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

Phase 1

Lay Your Foundation

This phase will walk you through the following activities:

• Seeing your budget as a living governance tool
• Understanding the point of view of different stakeholders
• Gaining tactics for setting future IT spend expectations

This phase involves the following participants:

• Head of IT
• IT Financial Lead
• Other IT Management

Lay Your Foundation

Before starting any process, you need to understand exactly why you’re doing it.

This phase is about understanding the what, why, and who of your IT budget.

• Understand what your budget is and does. A budget isn’t just an annual administrative event – it’s an important governance tool. Understand exactly what a budget is and your budgetary accountabilities as an IT leader.
• Know your stakeholders. The CFO, CEO, and CXOs in your organization have their own priorities, interests, and professional mandates. Get to know what their objectives are and what IT’s budget means to them.
• Continuously pre-sell your budget. Identifying, creating, and capitalizing on opportunities to discuss your budget well in advance of its formal presentation will get influential stakeholders and approvers on side, foster collaborations, and avoid unpleasant surprises on all fronts.

“IT finance is more than budgeting. It’s about building trust and credibility in where we’re spending money, how we’re spending money. It’s about relationships. It’s about financial responsibility, financial accountability. I rely on my entire leadership team to all understand what their spend is. We are a steward of other people’s money.”

– Rick Hopfer, CIO, Hawaii Medical Service Association

What does your budget actually do?

A budget is not just a painful administrative exercise that you go through once a year.

Most people know what a budget is, but it’s important to understand its true purpose and how it’s used in your organization before you engage in any activity or dialogue about it.

In strictly objective terms:

• A budget is a calculated estimate of income vs. expenditure for a period in the future, often one year. Basically, it’s an educated guess about how much money will come into a business entity or unit and how much money will go out of it.
• A balanced budget is where income and expenditure amounts are equal.
• The goal in most organizations is for the income component of the budget to match or exceed the expenditure component.
  If it doesn’t, this results in a deficit that may lead to debt.

Simply put, a budget’s fundamental purpose is to plan and communicate how an organization will avoid deficit and debt and remain financially viable while meeting its various accountabilities and responsibilities to its internal and external stakeholders.

“CFOs are not thinking that they want to shut down IT spend. Nobody wants to do that. I always looked at things in terms of revenue streams – where the cash inflow is coming from, where it’s going to, and if I can align my cash outflows to my revenue stream. Where I always got suspicious as a CFO is if somebody can’t articulate spending in terms of a revenue stream. I think that’s how most CFOs operate.”

– Carol Carr, Technical Counselor,
Info-Tech Research Group and Former CFO

Put your IT budget in context

Your IT budget is just one of several budgets across your organization that, when combined, create an organization-wide budget. In this context, IT’s in a tough spot.

It’s a competition: The various units in your organization are competing for the biggest piece they can get of the limited projected income pie. It’s a zero-sum game. The organization’s strategic and operational priorities will determine how this projected income is divvied up.

Direct-to-revenue units win: Business units that directly generate revenue often get bigger relative percentages of the organizational budget since they’re integral to bringing in the projected income part of the budget that allows the expenditure across all business units to happen in the first place.

Indirect-to-revenue units lose: Unlike sales units, for example, IT’s relationship to projected income tends to be indirect, which means that IT must connect a lot more dots to illustrate its positive impact on projected income generation.

In financial jargon, IT really is a cost center: This indirect relationship to revenue also explains why the focus of IT budget conversations is usually on the expenditure side of the equation, meaning it doesn’t have a clear positive impact on income.

Contextual metrics like IT spend as a percentage of revenue, IT OpEx as a percentage of organizational OpEx, and IT spend per organizational employee are important baseline metrics to track around your budget, internally benchmark over time, and share, in order to illustrate exactly where IT fits into the broader organizational picture.

Budgeting isn’t a once-a-year thing

Yet, many organizations treat it like a “one and done” point of annual administration. This is a mistake that misses out on the real benefits of budgeting.

Many organizations have an annual budgeting and planning event that takes place during the back half of the fiscal year. This is where all formal documentation around planned projects and proposed spend for the upcoming year is consolidated, culminating in final presentation, adjustment, and approval. It’s basically a consolidation and ranking of organization-wide priorities at the highest level.

If things are running well, this culmination point in the overall budget development and management process is just a formality, not the beginning, middle, and end of the real work. Ideally:

• Budgets are actually used: The whole organization uses budgets as tools to actively manage day-to-day operations and guide decision making throughout the year in alignment with priorities as opposed to something that’s put on a shelf or becomes obsolete within a few months.
• Interdependencies are evident: No discrete area of spend focus is an island – it’s connected directly or indirectly with other areas of spend, both within IT and across the organization. For example, one server interacts with multiple business applications, IT and business processes, multiple IT staff, and even vendors or external managed service providers. Cost-related decisions about that one server – maintain, repurpose, consolidate, replace, discard – will drive other areas of spend up or down.
• There are no surprises: While this does happen, your budget presentation isn’t a great time to bring up a new point of significant spend for the first time. The items in next year’s proposed budget should be priorities that are already known, vetted, supported, and funded.

"A well developed and presented budget should be the numeric manifestation of your IT strategy that’s well communicated and understood by your peers. When done right, budgets should merely affirm what’s already been understood and should get approved with minimal pushback.“

– Patrick Gray, TechRepublic, 2020

Understand your budgetary responsibilities as the IT leader

It’s in your job description. For some stakeholders, it’s the most important part of it.

While not a contract per se, your IT budget is an objective and transparent statement made in good faith that shows:

• You know what it takes to keep the organization viable.
• You understand the organization’s accountabilities and responsibilities as well as those of its leaders.
• You’re willing and able to do your part to meet these accountabilities and responsibilities.
• You know what your part of this equation is, as well as what parts should and must be played by others.

When it comes to your budget (and all things financial), your job is to be ethical, careful, and wise:

1. Be honest. Business ethics matter.
2. Be as accurate as possible. Your expenditure predictions won’t be perfect, but they need to be best-effort and defensible.
3. Respect the other players. They have their own roles, motivations, and mandates. Accept and respect these by being a supporter of their success instead of an obstacle to them achieving it.
4. Connect the dots to income. Always keep the demonstration of business value in your sights. Often, IT can’t draw a straight line to income, but demonstrating how IT expenditure supports and benefits future, current, and past (but still relevant) business goals and strategies, which in turn affect income, is the best course.
5. Provide alternatives. There are only so many financial levers your organization can pull. An action on one lever will have wanted and unwanted consequences on another. Aim to put financial discussions in terms of risk-focused “what if” stories and let your business partners decide if those risks are satisfactory.

Budgeting processes tend to be similar – it’s budgeting cultures that drive differences

The basic rules of good budgeting are the same everywhere. Bad budgeting processes, however, are usually caused by cultural factors and can be changed.

1.1 Review your budgeting process and culture

1 hour

1. Review the following components of your budget process using the questions provided for each as a guideline.
1. Legal and regulatory mandates. What are the external rules that govern how we do financial tracking and reporting? How do they manifest in our processes?
2. Accounting rules used. What rules does our finance department use and why? Do these rules allow for more meaningful representations of IT spend? Are there policies or practices in place that don’t appear to be backed by any external standards?
3. Timeframes and deadlines. Are we starting the budgeting process too late? Do we have enough time to do proper due diligence? Will expenditures approved now be out of date when we go to execute? Are there mechanisms to update spend plans mid-cycle?
4. Order of operations. What areas of spend do we always look at first, such as CapEx? Are there any benefits to changing the order in which we do things, such as examining OpEx first?
5. Areas of focus. Is CapEx taking up most of our budgeting cycle time? Are we spending enough time examining OpEx? Is IT getting enough time from the CFO compared to other units?
6. Funding sources and ownership. Is IT footing most of the technology bills? Are business unit leaders fronting any technology business case pitches? Is IT appropriately included in business case development? Is there any benefit to implementing show-back or charge-back?
7. Review/approval mechanisms. Are strategies and priorities used to rank proposed spend clear and well communicated? Are spend approvers objective in their decision making? Do different approvers apply the same standards and tools?
8. Templates and tools. Are the ones provided by Finance, the PMO, and other groups sufficient to document what we need to document? Are they accessible and easy to use? Are they automated and integrated so we only have to enter data once?
2. On the slide following these activity instructions, rate how effective each of the above is on a scale of 1-10 (where 10 is very effective) in supporting the budgeting process. Note specific areas of challenge and opportunity for change.

1.1 Review your budgeting process and culture

Budget process and culture assessment

Document the outcomes of your assessment. Examples are provided below.

Receptive audiences make communication a lot easier

To successfully communicate anything, you need to be heard and understood.

The key to being heard and understood is first to hear and understand the perspective of the people with whom you’re trying to communicate – your stakeholders. This means asking some questions:

• What context are they operating in?
• What are their goals and responsibilities?
• What are their pressures and stresses?
• How do they deal with novelty and uncertainty?
• How do they best take in information and learn?

The next step of this blueprint shows the perspectives of IT’s key stakeholders and how they’re best able to absorb and accept the important information contained in your IT budget. You will:

• Learn a process for discovering these stakeholders’ IT budget information needs within the context of your organization’s industry, goals, culture, organizational structure, personalities, opportunities, and constraints.
• Document key objectives and messages when communicating with these various key stakeholders.

There are certain principles, mandates, and priorities that drive your stakeholders; they’ll want to see these reflected in you, your work, and your budget.

Your IT budget means different things to different stakeholders

Info-Tech’s ITFM Cost Model lays out what matters most from various points of view.

The CFO: Understand their role

The CFO is the first person that comes to mind in dealing with budgets. They’re personally and professionally on the line if anything runs amiss with the corporate purse.

What are the CFO’s role and responsibilities?

• Tracking cash flow and balancing income with expenditures.
• Ensuring fiscal reporting and legal/regulatory compliance.
• Working with the CEO to ensure financial-strategic alignment.
• Working with business unit heads to set aligned budgets.
• Seeing the big picture.

What’s important to the CFO?

• Costs
• Benefits
• Value
• Analysis
• Compliance
• Risk Management
• Strategic alignment
• Control
• Efficiency
• Effectiveness
• Reason
• Rationale
• Clarity
• Objectivity
• Return on investment

“Often, the CFO sees IT requests as overhead rather than a need. And they hate increasing overhead.”

– Larry Clark, Executive Counselor, Info-Tech Research Group and Former CIO

The CFO carries big responsibilities focused on mitigating organizational risks. It’s not their job to be generous or flexible when so much is at stake. While the CEO appears higher on the organizational chart than the CFO, in many ways the CFO’s accountabilities and responsibilities are on par with, and in some cases greater than, those of the CEO.

The CFO: What they want from the IT budget

What they need should look familiar, so do your homework and be an open book.

The CFO: Budget challenges and opportunities

Budget season is a great time to start changing the conversation and building trust.

The CXO: Understand their role

CXOs are a diverse group who lead a range of business functions including admin, operations, HR, legal, production, sales and service, and marketing, to name a few.

What are the CXO’s role and responsibilities?

Like you, the CXO’s job is to help the organization realize its goals and objectives. How each CXO does this is specific to the domain they lead. Variations in roles and responsibilities typically revolve around:

• Law and regulation. Some functions have compliance as a core mandate, including legal, HR, finance, and corporate risk groups.
• Finance and efficiency. Other functions prioritize time, money, and process such as finance, sales, customer service, marketing, production, operations, and logistics units.
• Quality. These functions prioritize consistency, reliability, relationship, and brand such as production, customer service, and marketing.

What’s important to the CXO?

• Staffing
• Skills
• Reporting
• Funding
• Planning
• Performance
• Predictability
• Customers
• Visibility
• Inclusion
• Collaboration
• Reliability
• Information
• Knowledge
• Acknowledgement

Disagreement is common between business-function leaders – they have different primary focus areas, and conflict and misalignment are natural by-products of that fact. It’s also hard to make someone care as much about your priorities as you do. Focus your efforts on sharing and partnering, not converting.

The CXO: What they want from the IT budget

Focus on their unique part of the organization and show that you see them.

The CXO: Budget challenges and opportunities

Seek out your common ground and be the solution for their real problems.

The CEO: Understand their role

A CEO sets the tone for an organization, from its overall direction and priorities to its values and culture. What’s possible and what’s not is usually determined by them.

What are the CEO’s role and responsibilities?

• Assemble an effective team of executives and advisors.
• Establish, communicate, and exemplify the organizations core values.
• Study the ecosystem within which the organization exists.
• Identify and evaluate opportunities.
• Set long-term directions, priorities, goals, and strategies.
• Ensure ongoing organizational performance, profitability, and growth.
• Connect the inside organization to the outside world.
• Make the big decisions no one else can make.

What’s important to the CEO?

• Strategy
• Leadership
• Vision
• Values
• Goals
• Priorities
• Performance
• Metrics
• Accountability
• Stakeholders
• Results
• Insight
• Growth
• Cohesion
• Context

Unlike the CFO and CXOs, the CEO is responsible for seeing the big picture. That means they’re operating in the realm of big problems and big ideas – they need to stay out of the weeds. IT is just one piece of that big picture, and your problems and ideas are sometimes small in comparison. Use any time you get with them wisely.

The CEO: What they want from the IT budget

The CEO wants what the CFO wants, but at a higher level and with longer-term vision.

The CEO: Budget challenges and opportunities

Strategically address the big issues, but don’t count on their direct assistance.

What about the CIO view on the IT budget?

IT leaders tend to approach budgeting from an IT services perspective. After all, that’s how their departments are typically organized.

The CFO expense view, CXO business view, and CEO innovation view represent IT’s stakeholders. The CIO service view, however, represents you, the IT budget creator. This means that the CIO service view plays a slightly different role in developing your IT budget communications.

1.2 Assess your stakeholders

1 hour

1. Use the “Stakeholder alignment assessment” template slide following this one to document the outcomes of this activity.
2. As an IT management team, identify your key budget stakeholders and specifically those in an approval position.
3. Use the information provided in this blueprint about various stakeholder responsibilities, areas of focus, and what’s typically important to them to determine each key stakeholder’s needs regarding the information contained in your IT budget. Note their stated needs, any idiosyncrasies, and IT’s current relationship status with the stakeholder (positive, neutral, or negative).
4. Assess previous years’ IT budgets to determine how well they targeted each different stakeholder’s needs. Note any gaps or areas for future improvement.
5. Develop a high-level list of items or elements to stop, start, or continue during your next budgeting cycle.

Stakeholder alignment assessment

Document the outcomes of your assessment below. Examples are provided below.

Set your IT budget pre-selling strategy

Pre-selling is all about ongoing communication with your stakeholders. This is the most game-changing thing you can do to advance a proposed IT budget’s success.

When IT works well, nobody notices. When it doesn’t, the persistent criticism about IT not delivering value will pop up, translating directly into less funding. Cut this off at the pass with an ongoing communications strategy based on facts, transparency, and perspective taking.

1. Know your channels

Identify all the communication channels you can leverage including meetings, committees, reporting cycles, and bulletins. Set up new channels if they don’t exist.

2. Identify partners

Nothing’s better than having a team of supporters when pitch day comes. Quietly get them on board early and be direct about the role each of you will play.

3. Always be prepared

Have information and materials about proposed initiatives at-the-ready. You never know when you’ll get your chance. But if your facts are still fuzzy, do more homework first.

4. Don’t be annoying

Talking about IT all the time will turn people off. Plan chats that don’t mention IT at all. Ask questions about their world and really listen. Empathy’s a powerful tool.

5. Communicate IT initiatives at launch

Describe what you will be doing and how it will benefit the business in language that makes sense to the beneficiaries of the initiative.

6. Communicate IT successes

Carry the same narrative forward through to the end and tell the whole story. Include comments from stakeholders and beneficiaries about the value they’re receiving.

Pre-selling with partners

The thing with pre-selling to partners is not to take a selling approach. Take a collaborative approach instead.

A partner is an influencer, advocate, or beneficiary of the expenditure or investment you’re proposing. Partners can:

• Advise you on real business impacts.
• Voice their support for your funding request.
• Present the initial business case for funding approval themselves.
• Agree to fund all or part of an initiative from their own budget.

When partners agree to pitch or fund an initiative, IT can lose control of it. Make sure you set specific expectations about what IT will help with or do on an ongoing basis, such as:

• Calculating the upfront and ongoing technology maintenance/support costs of the initiative.
• Leading the technology vetting and selection process, including negotiating with vendors, setting service-level agreements, and finalizing contracts.
• Implementing selected technologies and training users.
• Maintaining and managing the technology, including usage metering.
• Making sure the bills get paid.

A collaborative approach tends to result in a higher level of commitment than a selling approach.

Put yourself in their shoes using their language. Asking “How will this affect you?” focuses on what’s in it for them.

Example:

CIO: “We’re thinking of investing in technology that marketing can use to automate posting content to social media. Is that something you could use?”

CMO: “Yes, we currently pay two employees to post on Facebook and Twitter, so if it could make that more efficient, then there would be cost savings there.”

Pre-selling with approvers

The key here is to avoid surprises and ensure the big questions are answered well in advance of decision day.

An approver is the CFO, CEO, board, council, or committee that formally commits funding support to a program or initiative. Approvers can:

• Point out factors that could derail realization of intended benefits.
• Know that a formal request is coming and factor it into their planning.
• Connect your idea with others to create synergies and efficiencies.
• Become active advocates.

When approvers cool to an idea, it’s hard to warm them up again. Gradually socializing an idea well in advance of the formal pitch gives you the chance to isolate and address those cooling factors while they’re still minor. Things you can address if you get an early start with future approvers include:

• Identify and prepare for administrative, regulatory, or bureaucratic hurdles.
• Incorporate approvers’ insights about organizational realities and context.
• Further reduce the technical jargon in your language.
• Fine tune the relevance and specificity of your business benefits statements.
• Get a better sense of the most compelling elements to focus on.

Blindsiding approvers with a major request at a budget presentation could trigger an emotional response, not the rational and objective one you want.

Make approvers part of the solution by soliciting their advice and setting their expectations well in advance.

Example:

CIO: “The underwriting team and I think there’s a way to cut new policyholder approval turnaround from 8 to 10 days down to 3 or 4 using an online intake form. Do you see any obstacles?”

CFO: “How do the agents feel about it? They submit to underwriting differently and might not want to change. They’d all need to agree on it. Exactly how does this impact sales?”

1.3 Set your budget pre-selling strategy

1 hour

1. Use the “Stakeholder pre-selling strategy” template slide following this instruction slide to document the outcomes of this activity.
2. Carry forward your previously-generated stakeholder alignment assessment from Step 1.2. As a management team, discuss the following for each stakeholder:
   1. Forums and methods of contact and interaction.
   2. Frequency of interaction.
   3. Content or topics typically addressed during interactions.
3. Discuss what the outcomes of an ideal interaction would look like with each stakeholder.
4. List opportunities to change or improve the nature of interactions and specific actions you plan to take.

Stakeholder pre-selling strategy

Document the outcomes of your discussion. Examples are provided below.

Phase recap: Lay your foundation

Build in the elements from the start that you need to facilitate budgetary approval.

You should now have a deeper understanding of the what, why, and who of your IT budget. These elements are foundational to streamlining the budget process, getting aligned with peers and the executive, and increasing your chances of winning budgetary approval in the end.

In this phase, you have:

• Reviewed what your budget is and does. Your budget is an important governance and communication tool that reflects organizational priorities and objectives and IT’s understanding of them.
• Taken a closer look at your stakeholders. The CFO, CEO, and CXOs in your organization have accountabilities of their own to meet and need IT and its budget to help them succeed.
• Developed a strategy for continuously pre-selling your budget. Identifying opportunities and approaches for building relationships, collaborating, and talking meaningfully about IT and IT expenditure throughout the year is one of the leading things you can do to get on the same page and pave the way for budget approval.

“Many departments have mostly labor for their costs. They’re not buying a million and a half or two million dollars’ worth of software every year or fixing things that break. They don’t share IT’s operations mindset and I think they get frustrated.”

– Matt Johnson, IT Director Governance and Business Solutions, Milwaukee County

Phase 2

Get Into Budget-Starting Position

This phase will walk you through the following activities:

• Putting together your budget team and gather your data.
• Selecting which views of the ITFM Cost Model you’ll use.
• Mapping and analyzing IT’s historical expenditure.
• Setting goals and metrics for the next budgetary cycle.

This phase involves the following participants:

• Head of IT
• IT Financial Lead
• Other IT Management

Get into budget-starting position

Now’s the time to pull together your budgeting resources and decision-making reference points.

This phase is about clarifying your context and defining your boundaries.

• Assemble your resources. This includes the people, data, and other information you’ll need to maximize insight into future spend requirements.
• Understand the four views of the IT Cost Model. Firm up your understanding of the CFO expense view, CIO service view, CXO business view, and CEO innovation view and decide which ones you’ll use in your analysis and forecasting.
• Review last year’s budget versus actuals. You need last year’s context to inform next year’s numbers as well as demonstrate any cost efficiencies you successfully executed.
• Review five-year historical trends. This long-term context gives stakeholders and approvers important information about where IT fits into the business big picture and reminds them how you got to where you are today.
• Set your high-level goals. You need to decide if you’re increasing, decreasing, or holding steady on your budget and whether you can realistically meet any mandates you’ve been handed on this front. Set a target as a reference point to guide your decisions and flag areas where you might need to have some tough conversations.

“A lot of the preparation is education for our IT managers so that they understand what’s in their budgets and all the moving parts. They can actually help you keep it within bounds.”

– Trisha Goya, Director, IT Governance & Administration, Hawaii Medical Service Association

Gather your budget-building team

In addition to your CFO, CXOs, and CEO, there are other people who will provide important information, insight, and skill in identifying IT budget priorities and costs.

As the head of IT, your role is as the budgeting team lead. You understand both the business and IT strategies, and have relationships with key business partners. Your primary responsibilities are to guide and approve all budget components and act as a liaison between finance, business units, and IT.

Set expectations with your budgeting team

Be clear on your goals and ensure everyone has what they need to succeed.

2.1 Brief and mobilize your IT budgeting team

2 hours

1. Download the IT Cost Forecasting and Budgeting Workbook
2. Organize a meeting with your IT department management team, team leaders, and project managers.
3. Review their general financial management accountabilities and responsibilities.
4. Discuss the purpose and context of the budgeting exercise, different budget components, and the organization’s milestones/deadlines.
5. Identify specific tasks and activities that each member of the team must complete in support of the budgeting exercise.
6. Set up additional checkpoints, working sessions, or meetings that will take you through to final budget submission.
7. Document your budget team members, responsibilities, deliverables, and due dates on the “Planning Variables” tab in the IT Cost Forecasting & Budgeting Workbook.

Download the IT Cost Forecasting and Budgeting Workbook

Leverage the ITFM Cost Model

Each of the four views breaks down IT costs into a different array of categories so you and your stakeholders can see expenditure in a way that’s meaningful for them.

You may decide not to use all four views based on your goals, audience, and available time. However, let’s start with how you can use the first two views, the CFO expense view and the CIO service view.

Extend your dialogue to the business

Applying the business optimization views of the ITFM Cost Model can bring a level of sophistication to your IT cost analysis and forecasting efforts.

Some views take a bit more work to map out, but they can be powerful tools for communicating the value of IT to the business. Let’s look at the last two views, the CXO business view and the CEO innovation view.

2.2 Select the ITFM Cost Model views you plan to complete based on your goals

30 minutes

The IT Cost Forecasting and Budgeting Workbook contains standalone sections for each view, as well as rows for each lowest-tier sub-category in a view, so each view can be analyzed and forecasted independently.

1. Review Info-Tech’s ITFM Cost Model and the expenditure categories and sub-categories each view contains.
2. Revisit your stakeholder analysis for the budgeting exercise. Plan to:
   1. Complete the CFO expense view regardless.
   2. Complete the CIO service view – consider doing this one first for forecasting purposes as it may be most familiar to you and serve as an easier entry point into the forecasting process.
   3. Complete the CXO business view – consider doing this only for select business units if you have the objective of enhancing awareness of their true consumption of IT resources or if you have (or plan to have) a show-back/chargeback mechanism.
   4. Complete the CEO innovation view only if your data allows it and there’s a compelling reason to discuss the strategic or innovative role of IT in the organization.

Gather your budget-building data

Your data not only forms the content of your budget but also serves as the supporting evidence for the decisions you’ve made.

Ensure you have the following data and information available to you and your budgeting team before diving in:

Past data

• Last fiscal year’s budget.
• Actuals for the past five fiscal years.
• Pre-set capital depreciation/amortization amounts to be applied to next fiscal year’s budget.

Current data

• Current-year IT positions and salaries.
• Active vendor contracts with payment schedules and amounts (including active multi-year agreements).
• Cost projections for remainder of any projects that are committed or in-progress, including projected OpEx for ongoing maintenance and support.

Future data

• Estimated market value for any IT positions to be filled next year (both backfill of current vacancies and proposed net-new positions).
• Pricing data on proposed vendor purchases or contracts.
• Cost estimates for any capital/strategic projects that are being proposed but not yet committed, including resulting maintenance/support OpEx.
• Any known pending credits to be received or applied in the next fiscal year.

If you’re just getting started building a repeatable budgeting process, treat it like any other project, complete with a formal plan/ charter and a central repository for all related data, information, and in-progress and final documents.

Once you’ve identified a repeatable approach that works for you, transition the budgeting project to a regular operational process complete with policies, procedures, and tools.

Review last year’s budget vs. actuals

This is the starting point for building your high-level rationale around what you’re proposing for next fiscal year.

But first, some quick definitions:

• Budgeted: What you planned to spend when you started the fiscal year.
• Actual: What you ended up spending in real life by the end of the fiscal year.
• Variance: The difference between budgeted expenditure and actual expenditure.

For last fiscal year, pinpoint the following metrics and information:

Next, review your five-year historical expenditure trends

The longer-term pattern of IT expenditure can help you craft a narrative about the overarching story of IT.

For the previous five fiscal years, focus on the following:

Actual IT expenditure as a percentage of organizational revenue.

Again, for historical years 2-5, you can break this down into granular cost categories like workforce, software, and infrastructure like you did for last fiscal year. Avoid getting bogged down and focusing on the past – you ultimately want to redirect stakeholders to the future.

Percentage expenditure increase/decrease year to year.

You may choose to show overall IT expenditure amounts, breakdowns by CapEx and OpEx, as well as high-level cost categories.

As you go back in time, some data may not be available to you, may be unreliable or incomplete, or employ the same cost categories you’re using today. Use your judgement on the level of granularity you want to and can apply when going back two to five years in the past.

So, what’s the trend? Consider these questions:

• Is the year-over-year trend on a steady trajectory or are there notable dips and spikes?
• Are there any one-time capital projects that significantly inflated CapEx and overall spend in a given year or that forced maintenance-and support-oriented OpEx commitments in subsequent years?
• Does there seem to be an overall change in the CapEx-to-OpEx ratio due to factors like increased use of cloud services, outsourcing, or contract-based staff?

Take a close look at financial data showcasing the cost-control measures you’ve taken

Your CFO will look for evidence that you’re gaining efficiencies by controlling costs, which is often a prerequisite for them approving any new funding requests.

Your objective here is threefold:

1. Demonstrate IT’s track record of fiscal responsibility and responsiveness to business priorities.
2. Acknowledge and celebrate your IT-as-cost-center efficiency gains to clear the way for more strategic discussions.
3. Identify areas where you can potentially source and reallocate recouped funds to bolster other initiatives or business cases for net-new spend.

This step is about establishing credibility, demonstrating IT value, building trust, and showing the CFO you’re on their team.

Do the following:

• List any specific cost-control initiatives and their initial objectives and targets.
• Identify any changes made to those targets and your approaches due to changing conditions, with rationales for the decisions made. For example:
  • Mid-year, the business decided to allow approximately half the workforce to work from home on a permanent basis.
  • As a result, remote-worker demand on the service desk remained high and actually increased in some areas. You were unable to reduce service desk staff headcount as originally planned.
  • You’re now exploring ways to streamline ticket intake and assignment to increase throughput and speed resolution.
• Report on completed cost-control initiatives first, including targets, actuals, and related impacts. Include select feedback from business stakeholders and users about the impact of your cost-control measure on them.
• For in-progress initiatives, report progress made to-date, benefits realized to date, and plans for continuation next fiscal year.

“Eliminate the things you don’t need. People will give you what you need when you need it if you’re being responsible with what you already have.”

– Angela Hintz, VP of PMO & Integrated Services,
Blue Cross and Blue Shield of Louisiana

2.3 Review your historical IT expenditure

8 hours

1. Download the IT Cost Forecasting and Budgeting Workbook.
2. On Tab 1, “Historical Events & Projects,” note the cost-driving and cost-saving events that occurred last fiscal year that drove any variance between budgeted and actual expenditure. Describe the nature of their impact and current status (ongoing, resolved – temporary impact, or resolved – permanent impact).
3. Also on Tab 1, “Historical Events & Projects”, summarize the work done on capital or strategic projects, expenditures, and status (in progress, deferred, canceled, or complete).
4. On Tab 2, “Historical Expenditure”:
   1. Enter the budgeted and actuals data for last fiscal year in columns D-H for the views of the ITFM Cost Model you’re opted to do, i.e. CFO expense view, CIO service view, CXO business view, and CEO innovation view.
   2. Enter a brief rationale for any notable budgeted-versus-actuals variances or other interesting items in column K.
   3. Enter actuals data for the remaining past five fiscal years in columns L-O. Year-over-year comparative metrics will be calculated for you.
   4. Enter FTEs by business function in columns R-AA, rows 34-43.
      Expenditure per FTE and year-over year comparative metrics will be
      calculated for you.
5. Using Tabs 2, “Historical Expenditure” and 3, “Historical Analysis”, review and analyze the resulting data sets and graphs to identify overall patterns, specifically notable increases or decreases in a particular category of expenditure or where rationales are repeated across categories or views (these are significant).
6. Finally, flag any data points that help demonstrate achievement of, or progress toward, any cost-control measures you implemented.

2.3 Review your historical IT expenditure

Pull historical trends into a present-day context when setting your high-level goals

What’s happening to your organization and the ecosystem within which it’s operating right now? Review current business concerns, priorities, and strategies.

Knowing what happened in the past can provide good insights and give you a chance to show stakeholders your money-management track record. However, what stakeholders really care about is “now” and “next”. For them, it’s all about current business context.

Ask these questions about your current context to assess the relevance of your historical trend data:

Set metrics and targets for some broader budget effectiveness improvement efforts

Budget goalsetting isn’t limited to CapEx and OpEx targets. There are several effectiveness metrics to track overall improvement in your budgeting process.

Step back and think about other budget and expenditure goals you have.
Do you want to:

• Better align the budget with organizational objectives?
• Increase cost forecasting accuracy?
• Increase budget transparency and completeness?
• Improve the effectiveness of your budget presentation?
• Reduce the amount of budget rework?
• Increase the percentage of the budget that’s approved?
• Reduce variance between what was budgeted and actuals?

Establish appropriate metrics and targets that will allow you to define success, track progress, and communicate achievement on these higher-level goals.

Check out some example metrics in the table below.

Set your high-level OpEx budget targets

The high-level targets you set now don’t need to be perfect. Think of them as reference points or guardrails to sanity-check the cost forecasting exercise to come.

If cost-cutting or optimization is a priority, then a zero-based approach is the right decision. If doing this every year is too onerous, plan to do it for your OpEx at least every few years to examine what’s actually in there, clean house, and re-set.

Set your high-level CapEx budget targets

A lot of IT CapEx is conceived in business projects, so your proposed expenditure here may not be up to you. Exercise as much influence as you can.

Unanticipated hiring and the need to buy end-user hardware is cited as a top cause of budget grief by IT leaders – get ahead of this. Project CapEx, however, is usually determined via business-based capital project approval mechanisms well in advance. And don’t forget to factor in pre-established capital asset depreciation amounts generated by all the above!

2.4 Set your high-level IT budget targets and metrics

8 hours

1. Download the IT Cost Forecasting and Budgeting Workbook to document the outcomes of this activity.
2. Review the context in which your organization is currently operating and expects to operate in the next fiscal year. Specifically, look at:
   1. The state of the economy.
   2. Stated goals, objectives, and targets.
   3. The executive’s point of view on budget increase requests.
   Document your factors, assessment, rationale, and considerations in the “Business Context Assessment” table on the “Planning Variables” tab in the IT Cost Forecasting and Budgeting Workbook.
3. Based on the business context, anticipated flips of former CapEx to OpEx, and realization of previous years’ efficiency measures, set a general non-project OpEx target as a percentage increase or decrease for next fiscal year to serve as a guideline in the cost forecasting guideline. Document this in the “Budget Targets & Metrics” table on the “Planning Variables” tab in the IT Cost Forecasting and Budgeting Workbook. sed on known capital projects, changes in headcount, typical “business as usual” equipment expenditure, and pre-established capital asset depreciation amounts, set general project CapEx and non-project CapEx targets. Document these in the “Budget Targets & Metrics” table on the “Planning Variables” tab in the IT Cost Forecasting and Budgeting Workbook.
4. Finally, set your overarching IT budget process success metrics. Also document these in the “Budget Targets & Metrics” table on the “Planning Variables” tab in the IT Cost Forecasting and Budgeting Workbook.

Download the IT Cost Forecasting and Budgeting Workbook

2.4 Set your high-level IT budget targets and metrics

Phase recap: Get into budget-starting position

Now you’re ready to do the deep dive into forecasting your IT budget for next year.

In this phase, you clarified your business context and defined your budgetary goals, including:

• Assembling your resources. You’ve built and organized your IT budgeting team, as well as gathered the data and information you’ll need to do your historical expenditure analysis and future forecasting
• Understanding the four views of the IT Cost Model. You’ve become familiar with the four views of the model and have selected which ones you’ll map for historical analysis and forecasting purposes.
• Reviewing last year’s budget versus actuals and five-year historical trends. You now have the critical rationale-building context to inform next year’s numbers and demonstrate any cost efficiencies you’ve successfully executed.
• Setting your high-level goals. You’ve established high-level targets for project and non-project CapEx and OpEx, as well as set some IT budget process improvement goals.

“We only have one dollar but five things. Help us understand how to spend that dollar.”

– Trisha Goya, Director, IT Governance & Administration, Hawaii Medical Service Association

Phase 3

Develop Your Forecasts

This phase will walk you through the following activities:

• Documenting the assumptions behind your proposed budget and develop alternative scenarios.
• Forecasting your project CapEx.
• Forecasting your non-project CapEx and OpEx.

This phase involves the following participants:

• Head of IT
• IT Financial Lead
• Other IT Management

Develop your forecasts

Start making some decisions.

This phase focuses on putting real numbers on paper based on the research and data you’ve collected. Here, you will:

• Develop assumptions and alternative scenarios. The assumptions you make are the logical foundation for your decisions, and your primary and alternative scenarios focus your thinking and demonstrate that you’ve thoroughly examined your organization’s current and future context.
• Forecast your project CapEx costs. These costs are comprised of all the project-related capital expenditures for strategic or capital projects, including in-house labor.
• Forecast your non-project CapEx and OpEx costs. These costs are the ongoing “business as usual” expenditures incurred via the day-to-day operations of IT and delivery of IT services.

“Our April forecast is what really sets the bar for what our increase is going to be next fiscal year. We realized that we couldn’t change it later, so we needed to do more upfront to get that forecast right.

If we know that IT projects have been delayed, if we know we pulled some things forward, if we know that a project isn’t starting until next year, let’s be really clear on those things so that we’re starting from a better forecast because that’s the basis of deciding two percent, three percent, whatever it’s going to be.”

– Kristen Thurber, IT Director, Office of the CIO, Donaldson Company

When pinning down assumptions, start with negotiable and non-negotiable constraints

Assumptions are things you hold to be true. They may not actually be true, but they are your logical foundation and must be shared with stakeholders so they can follow your thinking.

Start with understanding your constraints. These are either negotiable (adjustable) or non-negotiable (non-adjustable). However, what is non-negotiable for IT may be negotiable for the organization as a whole, such as its strategic objectives. Consider each of the constraints below, determine how it relates to IT expenditure options, and decide if it’s ultimately negotiable or non-negotiable.

Identifying your negotiable and non-negotiable constraints is about knowing what levers you can pull. Government entities have more non-negotiable constraints than private companies, which means IT and the organization as a whole have fewer budgetary levers to pull and a lot less flexibility.

An un-pullable lever and a pullable lever (and how much you can pull it) have one important thing in common – they are all fundamental assumptions that influence your decisions.

Brainstorm your assumptions even further

The tricky thing about assumptions is that they’re taken for granted – you don’t always realize you’ve made them. Consider these common assumptions and test them for validity.

You won’t put some of these assumptions into your final budget presentation. It’s simply worthwhile knowing what they are so you can challenge them when forecasting.

Based on your assumptions, define the primary scenario that will frame your budget

Your primary scenario is the one you believe is most likely to happen and upon which you’ll build your IT cost forecasts.

Now it’s time to outline your primary scenario.

• A scenario is created by identifying the variable factors embedded in your assumptions and manipulating them across the range of possibilities. This manipulation of variables will result in different scenarios, some more likely or feasible than others.
• Your primary scenario is the one you believe is the most feasible and/or likely to happen (i.e. most probable). This is based on:
  • Your understanding of past events and patterns.
  • Your understanding of your organization’s current context.
  • Your understanding of IT’s current context.
  • Your understanding of the organization’s objectives.
  • Your assessment of negotiable and non-negotiable constraints and other assumptions for both IT and the organization.

A note on probability…

• A non-negotiable constraint doesn’t have any variables to manipulate. It’s a 100% probability that must be rigidly accommodated and protected in your scenario. An example is a long-standing industry regulation that shows no signs of being updated or altered and must be complied with in its current state.
• A negotiable constraint has many more variables in play. Your goal is to identify the different potential values of the variables and determine the degree of probability that one value is more likely to be true or feasible than another. An example is that you’re directed to cut costs, but the amount could be as little as 3% or as much as 20%.
• And then there are the unknowns. These are circumstances, events, or initiatives that inevitably happen, but you can’t predict when, what, or how much. This is what contingency planning and insurance are for. Examples include a natural disaster, a pandemic, a supply chain crisis, or the CEO simply changing their mind. Its safe to assume something is going to happen, so if you’re able to establish a contingency fund or mechanisms that let you respond, then do it.

What could or will be your organization’s new current state at the end of next fiscal year?

Next, explore alternative scenarios, even those that may seem a bit outrageous

Offering alternatives demonstrates that you weighed all the pertinent factors and that you’ve thought broadly about the organization’s future and how best to support it.

Primary scenario approval can be helped by putting that scenario alongside alternatives that are less attractive due to their cost, priority, or feasibility. Alternative scenarios are created by manipulating or eliminating your negotiable constraints or treating specific unknowns as knowns. Here are some common alternative scenarios.

The high-cost scenario: Assumes very positive economic prospects. Characterized by more of everything – people and skills, new or more sophisticated technologies, projects, growth, and innovation. Remember to consider the long-term impact on OpEx that higher capital spend may bring in subsequent years.

Target 10-20% more expenditure than your primary scenario

The low-cost scenario: Assumes negative economic prospects or cost-control objectives. Characterized by less of everything, specifically capital project investment, other CapEx, and OpEx. Must assume that business service-level expectations will be down-graded and other sacrifices will be made.

Target 5-15% less expenditure than your primary scenario

The dark horse scenario: This is a more radical proposition that challenges the status quo. For example, what would the budget look like if all data specialists in the organization were centralized under IT? What if IT ran the corporate PMO? What if the entire IT function was 100% outsourced?

No specific target

Case Study

INDUSTRY: Manufacturing

SOURCE: Anonymous

A manufacturing IT Director gets budgetary approval by showing what the business would have to sacrifice to get the cheap option.

3.1 Document your assumptions and alternative scenarios

2 hours

1. Download the IT Cost Forecasting and Budgeting Workbook and document the outcomes of this activity on Tab 9, “Alternative Scenarios.”
2. As a management team, identify and discuss your non-negotiable and negotiable constraints. Document these in rows 4 and 5 respectively in the Workbook.
3. Brainstorm, list, and challenge any other assumptions being made by IT or the organization’s executive in terms of what can and cannot be done.
4. Identify the most likely or feasible scenario (primary) and associated assumptions. You will base your initial forecasting on this scenario.
5. Identify alternative scenarios. Document each scenario’s name, description, and key assumptions, and major opportunities in columns B-D on Tab 9, “Alternative Scenarios.” You will do any calculations for these scenarios after you have completed the forecast for your primary scenario.

Download the IT Cost Forecasting and Budgeting Workbook

Before diving into actual forecasting, get clear on project and non-project CapEx and OpEx

Traditional, binary “CapEx vs. OpEx” distinctions don’t seem adequate for showing where expenditure is really going. We’ve added a new facet to help further differentiate one-time project costs from recurring “business as usual” expenses.

Project CapEx
Includes all workforce and vendor costs associated with planning and execution of projects largely focused on the acquisition or creation of new capital assets.

Non-project CapEx
Includes “business as usual” capital asset acquisition in the interest of managing, maintaining, or supporting ongoing performance of existing infrastructure or services, such as replacement network equipment, end-user hardware (e.g. laptops), or disaster recovery/business continuity redundancies. Also includes ongoing asset depreciation amounts.

Non-project OpEx
Includes all recurring, non-CapEx “business as usual” costs such as labor compensation and training, cloud-based software fees, outsourcing costs, managed services fees, subscriptions, and other discretionary spend.

Depreciation is technically CapEx. However, for practical purposes, most organizations list it under OpEx, which can cause it to get lost in the noise. Here, depreciation is under non-project CapEx to keep its true CapEx nature visible and in the company of other “business as usual” capital purchases that will ultimately join the depreciation ranks.

Forecast your project CapEx costs

This process can be simple as far as overall budget forecasting is concerned. If it isn’t simple now, plan to make it simpler next time around.

What to expect…

• Ideally, the costs for all projects should have been thoroughly estimated, reviewed, and accepted by a steering committee, your CFO, or other approving entity at the start of the budgeting season, and funding already committed to. In a nutshell, forecasting your project costs should already have been done and will only require plugging in those numbers.
• If projects have yet to be pitched and rubber stamped, know that your work is cut out for you. Doing things in a rush or without proper due diligence will result in certain costs being missed. This means that you risk going far over budget in terms of actuals next year, or having to borrow from other areas in your budget to cover unplanned or underestimated project costs.

Key forecasting principles…

Develop rigorous business cases
Secure funding approval well in advance
Tie back costs benefitting business units
Consider the longer-term OpEx impact

For more information about putting together sound business cases for different projects and circumstances, see the following Info-Tech blueprints:

Build a Comprehensive Business Case

Fund Innovation with a Minimum Viable Business Case

Reduce Time to Consensus with an Accelerated Business Case

Apply these project CapEx forecasting tips

A good project CapEx forecast requires steady legwork, not last-minute fast thinking.

Tip #1: Don’t surprise your approvers. Springing a capital project on approvers at your formal presentation isn’t a good idea and stands a good chance of rejection, so do whatever you can to lock these costs down well in advance.

Tip #2: Project costs should be entirely comprised of CapEx if possible. Keep in mind that some of these costs will convert to depreciated non-project CapEx and non-project OpEx as they transition from project costs to ongoing “business as usual” costs, usually in the fiscal year following the year of expenditure. Creating projections for the longer-term impacts of these project CapEx costs on future types of expenditure is a good idea. Remember that a one-time project is not the same thing as a one-time cost.

Tip #3: Capitalize any employee labor costs on capital projects. This ensures the true costs of projects are not underestimated and that operational staff aren’t being used for free at the expense of their regular duties.

Tip #4: Capitalizing cloud costs in year one of a formal implementation project is usually acceptable. It’s possible to continue treating cloud costs as CapEx with some vendors via something called reserved instances, but organizations report that this is a lot of work to set up. In the end, most capitalized cloud will convert into non-project OpEx in years two and beyond.

Tip #5: Build in some leeway. By the time a project is initiated, circumstances may have changed dramatically from when it was first pitched and approved, including business priorities and needs, vendor pricing, and skillset availability. Your costing may become completely out of date. It’s a good practice to work within more general cost ranges than with specific numbers, to give you the flexibility to respond and adapt during actual execution.

3.2 Forecast your project CapEx

Time: Depends on size of project portfolio

1. Download the IT Cost Forecasting and Budgeting Workbook and navigate to Tab 5, “Project CapEx Forecast”. Add more columns as required. Enter the following for all projects:
   • Row 5 – Its name and/or unique identifier.
   • Row 6 – Its known or estimated project start/end dates.
   • Row 7 – Its status (in proposal, committed, or in progress).
2. Distribute each project’s costs across the categories listed for each view you’ve selected to map. Do not include any OpEx here – it will be mapped separately under non-project OpEx.
3. Rationalize your values. A running per-project total for each view, as well as totals for all projects combined, are in rows 16, 28, 39, and 43. Ensure these totals match or are very close across all the views you are mapping. If they don’t match, review the views that are lower-end outliers as there’s a good chance something has been overlooked.

Download the IT Cost Forecasting and Budgeting Workbook

Forecast your non-project OpEx

Most of your budget will be non-project OpEx, so plan to spend most of your forecasting effort here.

What to expect…

Central to the definition of OpEx is the fact that it’s ongoing. It rarely stops, and tends to steadily increase over time due to factors like inflation, rising vendor prices, growing organizational growth, increases in the salary expectations of employees, and other factors.

The only certain ways to reduce OpEx are to convert it to capitalizable expenditure, decrease staffing costs, not pursue cloud technologies, or for the organization to simply not grow. For most organizations, none of these approaches are feasible. Smaller scale efficiencies and optimizations can keep OpEx from running amok, but they won’t change its overall upward trajectory over time. Expect it to increase.

Key forecasting principles…

Focus on optimization and efficiency.
Aim for full spend transparency.
Think about appropriate chargeback options.
Give it the time it deserves.

For more information about how to make the most out of your IT OpEx, see the following Info-Tech blueprints:

Develop Your Cost Optimization Roadmap

Achieve IT Spend & Staffing Transparency

Discover the Hidden Costs of Outsourcing

Apply these non-project OpEx forecasting tips

A good forecast is in the details, so take a very close look to see what’s really there.

Tip #1: Consider zero-based budgeting. You don’t have to do this every year, but re-rationalizing your OpEx every few years, or a just a segment of it on a rotational basis, will not only help you readily justify the expenditure but also find waste and inefficiencies you didn’t know existed.

Tip #2: Capitalize your employee capital project work. While some organizations aren’t allowed to do this, others who can simply don’t bother. Unfortunately, this act can bloat the OpEx side of the equation substantially. Many regular employees spend a significant amount of their time working on capital projects, but this fact is invisible to the business. This is why the business keeps asking why it takes so many people to run IT.

Tip #3: Break out your cloud vs. on-premises costs. Burying cloud apps costs in a generic software bucket works against any transparency ambitions you may have. If you have anything resembling a cloud strategy, you need to track, report, and plan for these costs separately in order to measure benefits realization. This goes for cloud infrastructure costs, too.

Tip #4: Spend time on your CIO service view forecast. Completing this view counts as a first step toward service-based costing and is a good starting point for setting up an accurate service catalog. If looking for cost reductions, you’ll want to examine your forecasts in this view as there will likely be service-level reductions you’ll need to propose to hit your cost-cutting goals.

Tip #5: Budget with consideration for chargeback. chargeback mechanisms for OpEx can be challenging to manage and have political repercussions, but they do shift accountability back to the business, guarantee that the IT bills get paid, and reduce IT’s OpEx burden. Selectively charging business units for applications that only they use may be a good entry point into chargeback. It may also be as far as you want to go with it. Doing the CXO business view forecast will provide insight into your opportunities here.

Forecast your non-project CapEx

These costs are often the smallest percentage of overall expenditure but one of the biggest sources of financial grief for IT.

What to expect…

• These costs can be hard to predict. Anticipating expenditure on end-user hardware such as laptops depends on knowing how many new staff will be hired by the organization next year. Predicting the need to buy networking hardware depends on knowing if, and when, a critical piece of equipment is going to spontaneously fail. You can never be completely sure.
• IT often must reallocate funds from other areas of its budget to cover non-project CapEx costs. Unfortunately, keeping the network running and ensuring employees have access to that network is seen exclusively as an IT problem, not a business problem. Plan to change this mindset.

Key forecasting principles…

Discuss hiring plans with the business.
Pay close attention to your asset lifecycles.
Prepare to advise about depreciation schedules.
Build in contingency for the unexpected.

For more information about ensuring IT isn’t left in the lurch when it comes to non-project CapEx, see the following Info-Tech blueprints:

Manage End-User Devices

Develop an Availability and Capacity Management Plan

Modernize the Network

Apply these non-project CapEx forecasting tips

A good forecast relies on your ability to accurately predict the future.

Tip #1: Top up new hire estimations: Talk to every business unit leader about their concrete hiring plans, not their aspirations. Get a number, increase that number by 25% or 20 FTEs (whichever is less), and use this new number to calculate your end-user non-project CapEx.

Tip #2: Make an arrangement for who’s paying for operational technology (OT) devices and equipment. OT involves specialized devices such as in-the-field sensors, scanners, meters, and other networkable equipment. Historically, operational units have handled this themselves, but this has created security problems and they still rely on IT for support. Sort the financials out now, including whose budget device and equipment purchases appear on, as well as what accommodations IT will need to make in its own budget to support them.

Tip #3: Evaluate cloud infrastructure and managed services. These can dramatically reduce your non-project CapEx, particularly on the network and data center fronts. However, these solutions aren’t necessarily less expensive and will drive up OpEx, so tread cautiously.

Tip #4: Definitely do an inventory. If you haven’t invested in IT asset management, put it on your project and budgetary agenda. You can’t manage what you don’t know you have, so asset discovery should be your first order of business. From there, start gathering asset lifecycle information and build in alerting to aid your spend planning.

Tip #5: Think about retirement: What assets are nearing end of life or the end of their depreciation schedule? What impact is this having on non-project OpEx in terms of maintenance and support? Deciding to retire, replace, or extend an IT operational asset will change your non-project CapEx outlook and will affect costs in other areas.

Tip #6: Create a contingency fund: You need one to deal with surprises and emergencies, so why wait?

Document the organization’s projected FTEs by business function

This data point is usually missing from IT’s budget forecasting data set. Try to get it.

A powerful metric to share with business stakeholders is expenditure per employee or FTE. It’s powerful because:

• It’s one of the few metrics that’s intuitively understood by most people
• It can show changes in IT expenditure over time at both granular and general levels.

This metric is one of the simplest to calculate. The challenge is in getting your hands on the data in the first place.

• Most business unit leaders struggle to pin down this number in terms of actuals as they have difficulty determining what an FTE actually is. Does it include contract staff? Part-time staff? Seasonal workers? Volunteers and interns? And if the business unit has high turnover, this number can fluctuate significantly.
• Encourage your business peers to produce a rational estimate. Unlike the headcount number you’re seeking to forecast for non-project capital expenditure for end-user hardware, this FTE number should strive to be more in the ballpark, as you’re not using it to ensure sufficient funds but comparatively track expenditure year to year.
• Depending on your industry, employees or FTEs may not be the best measurement. Use what works best for you. Number of unique users is a common one. Other industry-specific examples include per student, per bed, per patient, per account, and per resident.

Start to build in long-term and short-term forecasting into your budgeting process

These are growing practices in mature IT organizations that afford significant flexibility.

3.4 Forecast your non-project OpEx and CapEx

Time: Depends on size of vendor portfolio and workforce

1. Download the IT Cost Forecasting and Budgeting Workbook and navigate to Tab 4, “Business as Usual Forecast”. This tab assumes an incremental budgeting approach. Last year’s actuals have been carried forward for you to build upon.
2. Enter expected percentage-based cost increases/decreases for next fiscal year for each of the following variables (columns E-I): inflation, vendor pricing, labor costs, service levels, and depreciation. Do this for all sub-categories for the ITFM cost model views you’ve opted to map. Provide rationales for your percentage values in column K.
3. In columns M and N, enter the anticipated percentage allocation of cost to non-project CapEx versus non-project OpEx.
4. In column O, rows 29-38, enter the projected FTEs for each business function (if available).
5. If you choose, make longer-term, high-level forecasts for 2-3 years in the future in columns P-U. Performing longer-term forecasts for at least the CFO expense view categories is recommended.

Download the IT Cost Forecasting and Budgeting Workbook

Case Study

INDUSTRY: Insurance

SOURCE: Anonymous

Phase recap: Develop your forecasts

The hard math is done. Now it’s time to step back and craft your final proposed budget and its key messages.

This phase focused on developing your forecasts and proposed budget for next fiscal year. It included:

• Developing assumptions and alternative scenarios. These will showcase your understanding of business context as well as what’s most likely to happen (or should happen) next year.
• Forecasting your project CapEx costs. If these costs weren’t laid out already in formal, approved project proposals or plans, now you know why it’s the better approach for developing a budget.
• Forecasting your non-project CapEx and OpEx costs. Now you should have more clarity and transparency concerning where these costs are going and exactly why they need to go there.

“Ninety percent of your projects will get started but a good 10% will never get off the ground because of capacity or the business changes their mind or other priorities are thrown in. There are always these sorts of challenges that come up.”

– Theresa Hughes, Executive Counselor,
Info-Tech Research Group
and Former IT Executive

Phase 4

Build Your Proposed Budget

This phase will walk you through the following activities:

• Pulling your forecasts together into a comprehensive IT budget for next fiscal year.
• Double checking your forecasts to ensure they’re accurate.
• Fine tuning the rationales behind your proposals.

This phase involves the following participants:

• Head of IT
• IT Financial Lead
• Other IT Management

Build your proposed budget

Triple check your numbers and put the finishing touches on your approval-winning rationales.

This phase is where your analysis and decision making finally come together into a coherent budget proposal. Key steps include:

• Aggregating your numbers. This step involves pulling together your project CapEx, non-project CapEx, and non-project OpEx forecasts into a comprehensive whole and sanity-checking your expenditure-type ratios.
• Stress-testing your forecasts. Do some detailed checks to ensure everything’s accounted for and you haven’t overlooked any significant information or factors that could affect your forecasted costs.
• Challenging and perfecting your rationales. Your ability to present hard evidence and rational explanations in support of your proposed budget is often the difference between a yes or a no. Look at your proposals from different stakeholder perspectives and ask yourself, “Would I say yes to this if I were them?”

“We don’t buy servers and licenses because we want to. We buy them because we have to. IT doesn’t need those servers out at our data center provider, network connections, et cetera. Only a fraction of these costs are to support us in the IT department. IT doesn’t have control over these costs because we’re not the consumers.”

– Matt Johnson, IT Director Governance and Business Solutions, Milwaukee County

Great rationales do more than set you up for streamlined budgetary approval

Rationales build credibility and trust in your business capabilities. They can also help stop the same conversations happening year after year.

Any item in your proposed budget can send you down a rabbit hole if not thoroughly defensible.

You probably won’t need to defend every item, but it’s best to be prepared to do so. Ask yourself:

• What areas of spend does the CFO come back to year after year? Is it some aspect of OpEx, such as workforce costs or cloud software fees? Is it the relationship between proposed project spend and business benefits? Provide detailed and transparent rationales for these items to start re-directing long-term conversations to more strategic issues.
• What areas of spend seem to be recurring points of conflict with business unit leaders? Is it surprise spend that comes from business decisions that didn’t include IT? Is it business-unit leaders railing against chargeback? Have frank, information-sharing conversations focused on business applications, service-level requirements, and true IT costs to support them.
• What’s on the CEO’s mind? Are they focused on entering a new overseas market, which will require capital investment? Are they interested in the potential of a new technology because competitors are adopting it? It may not be the same focus as last year, so ensure you have fresh rationales that show how IT will help deliver on these business goals.

“Budgets get out of control when one department fails to care for the implications of change within another department's budget. This wastes time, reduces accuracy and causes conflict.”

– Tara Kinney, Atomic Revenue, LLC.

Rationalizing costs depends on the intention of the spend

Not all spending serves the same purpose. Some types require deeper or different justifications than others.

For the business, there are two main purposes for spend:

1. Spending that drives revenues or the customer experience. Think in terms of return on investment (ROI), i.e. when will the expenditure pay for itself via the revenue gains it helps create?
2. Spending that mitigates and manages risk. Think in terms of cost-benefit, i.e. what are the costs of doing something versus doing nothing at all?

Source: Kris Blackmon, NetSuite Brainyard.

“Approval came down to ROI and the ability to show benefits realization for years one, two, and three through five.”

– Duane Cooney, Executive Counselor, Info-Tech Research Group, and Former Healthcare CIO

Regardless of its ultimate purpose, all expenditure needs statements of assumptions, obstacles, and likelihood of goals being realized behind it.

• What are the assumptions that went into the calculation?
• Is the spend new or a reallocation (and from where)?
• What’s the likelihood of realizing returns or benefits?
• What are potential obstacles to realizing returns or benefits?

Rationales aren’t only for capital projects – they can and should be applied to all proposed OpEx and CapEx. Business project rationales tend to drive revenue and the customer experience, demanding ROI calculations. Internal IT-projects and non-project expenditure are often focused on mitigating and managing risk, requiring cost-benefit analysis.

First, make sure your numbers add up

There are a lot of numbers flying around during a budgeting process. Now’s the time to get out of the weeds, look at the big picture, and ensure everything lines up.

4.1 Aggregate your proposed budget numbers and stress test your forecasts

2 hours

1. Download the IT Cost Forecasting and Budgeting Workbook for this activity. If you have been using it thus far, the Workbook will have calculated your numbers for you across the four views of the ITFM Cost Model on Tab 7, “Proposed Budget”, including:
   1. Forecasted non-project OpEx, non-project CapEx (including depreciation values), project CapEx, and total values.
   2. Numerical and percentage variances from the previous year.
2. Test and finalize your forecasts by applying the questions on the previous slide.
3. Flag cost categories where large variances from the previous year or large numbers in general appear – you will need to ensure your rationales for these variances are rigorous in the next step.
4. Make amendments if needed to Tabs 4, “Business as Usual Forecast” and 5, “Project CapEx Forecast” in the IT Cost Forecasting and Budgeting Workbook.

Download the IT Cost Forecasting and Budgeting Workbook

Case Study

INDUSTRY: Healthcare

SOURCE: Anonymous

The strength of your rationales will determine how readily your budget is approved

When proposing expenditure, you need to thoroughly consider the organization’s goals, its governance culture, and the overall feasibility of what’s being asked.

First, recall what budgets are really about.

The completeness, accuracy, and granularity of your numbers and thorough ROI calculations for projects are essential. They will serve you well in getting the CFO’s attention. However, the numbers will only get you halfway there. Despite what some people think, the work in setting a budget is more about the what, how, and why – that is, the rationale – than about the how much.

Next, revisit Phase 1 of this blueprint and review:

• Your organization’s budgeting culture and processes.
• The typical accountabilities, priorities, challenges, opportunities, and expectations associated with your CFO, CEO, and CXO IT budget stakeholders.
• Your budgetary mandate as the head of IT.

Then, look at each component of your proposed budget through each of these three rationale-building lenses.

Business goals
What are the organization’s strategic priorities?

Governance culture
How constrained is the decision-making process?

Feasibility
Can we make it happen?

Linking proposed spend to strategic goals isn’t just for strategic project CapEx

Tie in your “business as usual” non-project OpEx and CapEx, as well.

Your governance culture will determine what you need to show and when you show it

The rigor of your rationales is entirely driven by “how things are done around here.”

No matter which way your goals and culture lean, ground all your rationales in reality

Objective, unapologetic facts are your strongest rationale-building tool.

Double-check to ensure your bases are covered

For more on creating detailed business cases for projects and investments, see Info-Tech’s comprehensive blueprint, Build a Comprehensive Business Case.

4.2 Challenge and perfect your rationales

2 hours

1. Based on your analysis in Phase 1, review your organization’s current and near-term business goals (context, lifecycle position, opportunities), governance culture (risk tolerance, control, speed to action), and feasibility (funding, capabilities, risk) to understand what’s possible, what’s not, and your general boundaries.
2. Review your proposed budget in its current form and flag items that may be difficult or impossible to sell, given the above.
3. Systematically go through each item in you proposed budget and apply the detailed data and information and high-level rationale checklists on the previous slide to ensure you have considered it from every angle and have all the information you need to defend it.
4. Track down any additional information needed to fill gaps and fine-tune your budget based on any discoveries, including eliminating or adding elements if needed.

Download the IT Cost Forecasting and Budgeting Workbook

Phase recap: Build your proposed budget

You can officially say your proposed IT budget is done. Now for the communications part.

This phase is where everything came together into a coherent budget proposal. You were able to:

• Aggregate your numbers. This involved pulling for project and non-project CapEx and OpEx forecasts into a single proposed IT budget total.
• Stress-test your forecasts. Here, you ensured that all your numbers were accurate and made sense.
• Challenge and perfect your rationales. Finally, you made sure you have all your evidence in place and can defend every component in your proposed IT budget regardless of who’s looking at it.

“Current OpEx is about supporting and aligning with past business strategies. That’s alignment. If the business wants to give up on those past business strategies, that’s up to them.”

– Darin Stahl, Distinguished Analyst and Research Fellow, Info-Tech Research Group

Phase 5

Create and Deliver Your Presentation

This phase will walk you through the following activities:

• Planning the content you’ll include in your budget presentation.
• Pulling together your formal presentation.
• Presenting, finalizing, and submitting your budget.

This phase involves the following participants:

• Head of IT
• IT Financial Lead
• Other IT Management

Create and deliver your presentation

Pull it all together into something you can show your approvers and stakeholders and win IT budgetary approval.

This phase focuses on developing your final proposed budget presentation for delivery to your various stakeholders. Here you will:

• Plan your final content. Decide the narrative you want to tell and select the visualizations and words you want to include in your presentation (or presentations) depending on the makeup of your target audience.
• Build your presentation. Pull together all the key elements in a PowerPoint template in a way that best tells the IT budget story.
• Present to stakeholders. Deliver your IT budgetary message.
• Make final adjustments and submit your budget. Address any questions, make final changes, and deconstruct your budget into the account categories mandated by your Finance Department to plug into the budget template they’ve provided.

“I could have put the numbers together in a week. The process of talking through what the divisions need and spending time with them is more time consuming than the budget itself.”

– Jay Gnuse, IT Director, Chief Industries

The content you select to present depends on your objectives and constraints

Info-Tech classifies potential content according to three basic types: mandatory, recommended, and optional. What’s the difference?

Deciding what to include or exclude depends 100% on your target audience. What will fulfill their basic information needs as well as increase their engagement in IT financial issues?

Revisit your assumptions and alternative scenarios first

These represent the contextual framework for your proposal and explain why you made the decisions you did.

Stating your assumptions and presenting at least two alternative scenarios helps in the following ways:

1. Identifies the factors you considered when setting budget targets and proposing specific expenditures, and shows that you know what the important factors are.
2. Lays the logical foundation for all the rationales you will be presenting.
3. Demonstrates that you’ve thought broadly about the future of the organization and how IT is best able to support that future organization regardless of its state and circumstances.

Your assumptions and alternative scenarios may not appear back-to-back in your presentation, yet they’re intimately connected in that every unique scenario is based on adjustments to your core assumptions. These tweaks – and the resulting scenarios – reflect the different degrees of probability that a variable is likely to land on a certain value (i.e. an alternative assumption).

Your primary scenario is the one you believe is most likely to happen and is represented by the complete budget you’re recommending and presenting.

Target timeframe for presentation: 2 minutes

Key objectives: Setting context, demonstrating breadth of thought.

Potential content for section:

• List of assumptions for the budget being presented (primary target scenario).
• Two or more alternative scenarios.

“Things get cut when the business
doesn’t know what something is,
doesn’t recognize it, doesn’t understand it. There needs to be an education.”

– Angie Reynolds, Principal Research Director, ITFM Practice,
Info-Tech Research Group,

Select your assumptions and scenarios

See Tabs “Planning Variables” and 9, “Alternative Scenarios” in your IT Cost Forecasting and Budgeting Workbook for these outputs.

The first major section of your presentation will be a retrospective

Plan to kick things off with a review of last year’s results, factors that affected what transpired, and longer-term historical IT expenditure trends.

This retrospective on IT expenditure is important for three reasons:

1. Clarifying definitions and the different categories of IT expenditure.
2. Showing your stakeholders how, and how well you aligned IT expenditure with business objectives.
3. Setting stakeholder expectations about what next year’s budget will look like based on past patterns.

You probably won’t have a lot of time for this section, so everything you select to share should pack a punch and perform double duty by introducing concepts you’ll need your stakeholders to have internalized when you present next year’s budget details.

Target timeframe for presentation: 7 minutes

Key objectives: Definitions, alignment, expectations-setting.

Potential content for section:

• Last fiscal year budgeted vs. actuals
• Expenditure by type
• Major capital projects completed
• Top vendor spend
• Drivers of last year’s expenditures and efficiencies
• Last fiscal year in in detail (expense view, service view, business view, innovation view)
• Expenditure trends for the past five years

“If they don’t know the consequences of their actions, how are they ever going to change their actions?”

– Angela Hintz, VP of PMO & Integrated Services,
Blue Cross and Blue Shield of Louisiana

Start at the highest level

See Tabs 1 “Historical Events & Projects,” 3 “Historical Analysis,” and 6 “Vendor Worksheet” in your IT Cost Forecasting and Budgeting Workbook for these outputs.