Improve IT Team Effectiveness

Implement the four critical factors required for all high-performing teams.

Analyst Perspective

All teams need to operate effectively; however, IT teams experience unique challenges.

IT often struggles to move from an effective to a high-performing team due to the very nature of their work. They work across multiple disciplines and with multiple stakeholders.

When operating across many disciplines it can become more difficult to identify the connections or points of interactions that define effective teams and separate them from being a working group or focus on their individual performance.

IT employees also work in close partnership with multiple teams outside their IT domain, which can create confusion as to what team are they a primary member of. The tendency is to advocate for or on behalf of the team they primarily work with instead of bringing the IT mindset and alignment to IT roadmap and goals to serve their stakeholders.

Amanda Mathieson
Research Director, People & Leadership Practice
Info-Tech Research Group

Executive Summary

The Challenge

Organizations rely on team-based work arrangements to provide organizational benefits and better navigate the volatile, uncertain, complex, and ambiguous (VUCA) operating environment.

This is becoming more challenging in a hybrid environment as interactions now rely less on casual encounters and must become more intentional.

A high-performing team is more than productive. They are more resilient and able to recognize opportunities. They are proactive instead of reactive due to the trust and high level of communication and collaboration.

Common Obstacles

IT teams are more unique, which also provides unique challenges other teams don't experience:

• Multiple disciplines that tend to operate in parallel versus within a sequence of events
• Multiple incumbent roles where people operate in parallel versus needing to share information to produce an outcome
• Multiple stakeholders that create a tension with competing priorities

Info-Tech's Approach

Use Info-Tech's phased approach to diagnose your team and use the IDEA model to drive team effectiveness.

The IDEA model includes four factors to identify team challenges and focus on areas for improvement: identity, decision making, exchanges within the team, and atmosphere of team psychological safety.

Info-Tech Insight

IT teams often fail to reach their full potential because teamwork presents unique challenges and complexities due to the work they do across the organization and within their own group. Silos, not working together, and not sharing knowledge are all statements that indicate a problem. As a leader it's difficult to determine what to do first to navigate the different desires and personalities on a team.

How this blueprint will help

Assess, diagnose, and address issues to realize your team's full potential.

This research helps IT support:

• Work Teams: Operate under one organizational unit or function. Their membership is generally stable with well-defined roles.
• Project Teams: Typically, are time-limited teams formed to produce a particular output or project. Their membership and expertise tend to vary over time.
• Management or Leadership Teams: Provide direction and guidance to the organization and are accountable for overall performance. Membership is structured by the hierarchy of the organization and includes a diverse set of skills, experience, and expertise.

Traditionally, organizations have tried to fix ineffective teams by focusing on these four issues: composition, leadership competencies, individual-level performance, and organizational barriers. While these factors are important, our research has shown it is beneficial to focus on the four factors of effective teams addressed in this blueprint first. Then, if additional improvement is needed, shift your focus to the traditional issue areas.

Common obstacles

These barriers make it difficult to address effectiveness for many IT teams:

• Teams do not use one standard set of processes because they may have a wide variety of assignments requiring different sets of processes.
  Source: Freshworks

• There are multiple disciplines within IT that require vastly different skill sets. Finding the connection points can be difficult when on the surface it seems like success doesn't require interconnectivity.
• IT has many people in the same roles that act independently based on the stakeholder or internal customer they are serving. This can lead to duplication of effort if information and solutions aren't shared.
• IT serves many parts of the organization that can bring competing priorities both across the groups they support and with the IT strategy and roadmap itself. Many IT leaders work directly in or for the business, which can see them associate with the internal client team more than their IT team – another layer of conflicting priorities.

IT also experience challenges with maturity and data silos

Current realities require teams to operate effectively

Teams struggle to realize their full potential

Poor Communication

To excel, teams must recognize and adapt to the unique communication styles and preferences of their members.

To find the "just right" amount of communication for your team, communication and collaboration expectations should be set upfront.

85% of tech workers don't feel comfortable speaking in meetings.
Source: Hypercontext, 2022

Decision Making

Decision making is a key component of team effectiveness. Teams are often responsible for decisions without having proper authority.

Establishing a team decision-making process becomes more complicated when appropriate decision-making processes vary according to the level of interdependency between team members and organizational culture.

20% of respondents say their organization excels at decision making.
Source: McKinsey, 2019

Resolving Conflicts

It is common for teams to avoid/ignore conflict – often out of fear. People fail to see how conflict can be healthy for teams if managed properly.

Leaders assume mature adults will resolve conflicts on their own. This is not always the case as people involved in conflicts can lack an objective perspective due to charged emotions.

56% of respondents prioritize restoring harmony in conflict and will push own needs aside.
Source: Niagara Institute, 2022

Teams with a shared purpose are more engaged and have higher performance

Increased Engagement

Effective and high-performing teams exchange information freely. They are clear on the purpose and goals of the organization, which enable empowerment.

Info-Tech Insight

Clear decision-making processes allow employees to focus on getting the work done versus navigating the system.

Case Study

Project Aristotle at Google – What makes a team effective at Google?

INDUSTRY: Technology
SOURCE: reWork

Challenge

Google wanted to clearly define what makes a team effective to drive a consistent meaning among its employees. The challenge was to determine more than quantitative measures, because more is not always better as it can just mean more mistakes to fix, and include the qualitative factors that bring some groups of people together better than others.

Solution

There was no pattern in the data it studied so Google stepped back and defined what a team is before embarking on defining effectiveness. There is a clear difference between a work group (a collection of people with little interdependence) and a team that is highly interdependent and relies on each other to share problems and learn from one another. Defining the different meanings took time and Google found that different levels of the organization were defining effectiveness differently.

Results

Google ended up with clear definitions that were co-created by all employees, which helped drive the meaning behind the behaviors. More importantly it was also able to define factors that had no bearing on effectiveness; one of which is very relevant in today's hybrid world – colocation.

It was discovered that teams need to trust, have clarity around goals, have structure, and know the impact their work has.

Overcoming barriers

Teams often lack the skills or knowledge to increase effectiveness and performance.

• Leaders struggle with team strife and ineffectiveness.
• A leader's ability to connect with and engage team members is vital for driving desired outcomes. However, many team leads struggle to deal with low-performing or conflict-ridden teams.
• Without adequate training on providing feedback, coaching, and managing difficult conversations, team leads often do not have the skills to positively affect team performance – and they do not appreciate the impact their actions have on desired outcomes.
• Team leads often find it difficult to invest time and resources in addressing challenges when the team is working toward deadlines.
• Team leads who are new to a management role within the organization often struggle to transition from independent contributor to leader – especially when they are tasked with managing team members who are former peers.
• Some team leads believe that soliciting help will be viewed as a personal failure, so they are reluctant to seek support for team performance management from more-senior leaders.

It's unrealistic to expect struggling teams to improve without outside help; if they were able to, they would have already done so.
To improve, teams require:

• A clearly defined team identity
• A clearly defined decision-making paradigm
• Consistently productive exchanges within the team
• An atmosphere of psychological safety

BUT these are the very things they are lacking when they're struggling.

Improving team effectiveness

Use the Info-Tech IDEA Model to assess and improve your team's effectiveness.

Begin by assessing, recognizing, and addressing challenges in:

• Identity – team goals, roles, responsibilities, and accountabilities
• Decision-making paradigms and processes within the team.
• Exchanges of information, motivation, and emotions between team members
• Atmosphere of team psychological safety

IDEA Model of Team Effectiveness

Effective Team

• Identity
• Decisions
• Exchanges
• Atmosphere

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

What does a typical GI on this topic look like?

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 6 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

Assess the team

Improving team effectiveness

Use the Info-Tech IDEA Model to assess and improve your team's effectiveness

Begin by assessing, recognizing, and addressing challenges in:

• Identity – team goals, roles, responsibilities, and accountabilities.
• Decision-making paradigms and processes within the team.
• Exchanges of information, motivation, and emotions between team members.
• Atmosphere of team psychological safety.

Effective Team

• Identity
• Decisions
• Exchanges
• Atmosphere

Assess the shared understanding of team identity

In addition to having a clear understanding of the team's goals and objectives, team members must also:

• Understand their own and each other's roles, responsibilities, and accountabilities.
• Recognize and appreciate the value of each team member.
• Realize how their actions impact each others' work and the overall goals and objectives.
• Understand that working in silos is considered a work group whereas a team coordinates activities, shares information, and supports each other to achieve their goals.

Clear goals enable employees to link their contributions to overall success of the team. Those who feel their contributions are important to the success of the department are two times more likely to feel they are part of a team working toward a shared goal compared to those who don't (McLean & Company, Employee Engagement Survey, IT respondents, 2023; N=4,551).

Goals matter in teamwork

The goals and objectives of the team are the underlying reason for forming the team in the first place. Without a clear and agreed-upon goal, it is difficult for teams to understand the purpose of their work.

Clear goals support creating clear roles and the contributions required for team success.

Assess the shared understanding of decision making

Decision making adds to the complexity of teamwork.
Individual team members hold different information and opinions that need to be shared to make good decisions.
Ambiguous decision-making processes can result in team members being unable to continue their work until they get clear direction.
The most appropriate decision-making process depends on the type of team:

• The higher the degree of interconnectivity in team members' work, the greater the need for a general consensus approach to decision making. However, if you opt for a general consensus approach, a backup decision-making method must be identified in the event consensus cannot be reached.
• High-pressure and high-stakes environments tend to centralize decision making to make important decisions quickly.
• Low-pressure and low-stakes environments are more likely to adopt consensus models.

Ensure team members understand how decisions are made within the team. Ask:

• Do team members recognize the importance of sharing information, opinions, and suggestions?
• Do team members feel their voices are heard?
• Must there be consensus between all team members?
• Is there a single decision maker?

Assess team exchanges by focusing on communication

Evaluate exchanges within your team using two categories:

These categories are related, but there is not always overlap. While some conflicts involve failures to successfully exchange information, conflict can also occur even when everyone is communicating successfully.

Successful exchange behaviors

• Shared understanding of how to motivate one another and how team members respond emotionally.
• Team moving beyond conflict to united action.
• Formalized processes used for resolving conflicts.
• Platforms provided for expressing diverse or conflicting perspectives and opinions – and used in a constructive manner.
• Use of agendas at meetings as well as clearly defined action items that reflect meeting outcomes.
• Avoidance of language that is exclusive, such as jargon and inside jokes.

Exchanges of information, emotion, and motivation

When selecting a method of communication (for example, in-person versus email), consider how that method will impact the exchange of all three aspects – not just information.

Downplaying the importance of emotional and motivational exchanges and focusing solely on information is very risky since emotional and motivational exchanges can impact human relationships and team psychological safety.

• Information: data or opinions.
• Emotions: feelings and evaluations about the data or opinions.
• Motivations: what we feel like doing in response to the data or opinions.

Communication affects the whole team

Effects are not limited to the team members communicating directly:

• How team members interact one on one transmits information and causes emotional and motivational responses in other group members not directly involved.
• How the larger group receives information, emotions, and motivations will also impact how individuals relate to each other in group settings.

Remember to watch the reactions and behavior of participants and observers when assessing how the team behaves.

Managing conflict

Identify how conflict management is embedded into team practices.

• Resolving conflicts is difficult and uses up a lot of time and energy. This is especially true if the team needs to figure out what to do each and every time people disagree.
• Teams that take the time to define conflict resolution processes upfront:
  • Demonstrate their commitment to resolving conflict in a healthy way.
  • Signal that diverse perspectives and opinions are valued, even if they spur disagreement sometimes.
  • Are ready for conflict when it arises – prepared to face it and thrive.

Successfully communicating information, emotions, and motivations is not the same as managing conflict.

Teams that are communicating well are more likely to uncover conflicting perspectives and opinions than teams that are not.

Conflict is healthy and can be an important element of team success if it is managed.

The team should have processes in place to resolve conflicts and move to united action.

Assess the atmosphere

Team psychological safety

A team atmosphere that exists when all members feel confident that team members can do the following without suffering negative interpersonal consequences such as blame, shame, or exclusion:

• Admit mistakes
• Raise questions or concerns
• Express dissenting views

(Administrative Science Quarterly, 1999;
The New York Times, 2016)

What psychologically safe teams look like:

• Open and learning-focused approach to error.
• Effective conflict management within the team.
• Emotional and relational awareness between team members.
• Existence of work-appropriate interpersonal relationships between team members (i.e. beyond mere working relationships).

(Administrative Science Quarterly, 1999;
The New York Times, 2016)

What "team psychological safety" is not:

• A situation where all team members are friends.
  In some cases psychologically safe team atmospheres might be harder to create when team members are friends since they might be more reluctant to challenge or disagree with friends.
• Merely trust. Being able to rely on people to honor their commitments is not the same as feeling comfortable admitting mistakes in front of them or disagreeing with them.

"Psychological safety refers to an individual's perception of the consequences of taking an interpersonal risk or a belief that a team is safe for risk taking in the face of being seen as ignorant, incompetent, negative, or disruptive… They feel confident that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea."

– re:Work

Psychological safety

The impact of psychological safety on team effectiveness

Why does an atmosphere of team psychological safety matter?

• Prevents groupthink.
  • People who do not feel safe to hold or express dissenting views gravitate to teams that think like they do, resulting in the well-known dangers of groupthink.
• Encourages contribution and co-operation.
  • One study found that if team psychological safety is present, even people who tend to avoid teamwork will be more likely to contribute in team settings, thereby increasing the diversity of perspectives that can be drawn on (Journal of Organizational Culture, 2016).

Creating psychological safety in a hybrid environment requires a deliberate approach to creating team connectedness.

In the Info-Tech State of Hybrid Work in IT report autonomy and team connectedness present an interesting challenge in that higher levels of autonomy drove higher perceptions of lack of connectedness to the respondent's team. In a hybrid world, this means leaders need to be intentional in creating a safe team dynamic.

47% of employees who experienced more control over their decisions related to where, when, and how they work than before the pandemic are feeling less connected to their teams.
Source: Info-Tech, State of Hybrid Work in IT, 2022

1.1 Prepare to launch the survey

1-2 hours

1. Review and record the objectives and outcomes that support your vision of a high-performing team:
   1. Why is this important to you?
   2. What reactions do you anticipate from the team?
2. In your team meeting, share your vision of what a high-performing team looks like. Engage the team in a discussion:
   1. Ask how they work. Ask them to describe their best working team environment from a previous experience or an aspirational one.
   2. Option: Instruct them to write on sticky notes, one idea per note, and share. This approach will allow for theming of ideas.
3. Introduce the survey as a way, together as a team, the current state can be assessed against the desired state discussed.
   1. Be clear that as the leader, you won't be completing the survey as you don't want to influence their perceptions of the team. As the leader, you hold authority, and therefore, experience the team differently. This is about them and their feedback.

Input

• Observations of team behavior
• Clearly articulated goals for team cohesion

Output

• Speaking notes for introducing survey
• Survey launch

Materials

• Whiteboard/flip charts
• Sticky notes
• IDEA Assessment

Participants

• Leader
• Team Members

Download the IT Team Effectiveness Survey

1.2 Launch the survey

1-2 hours

1. Determine how the survey will be completed.
   1. Paper-based
      1. Email a copy of the Word document IT Team Effectiveness Survey for each person to complete individually.
      2. Identify one person to collect each survey and enter the results into the team effectiveness survey tool (tab 2. Data – Effectiveness Answers and tab 3. Data – Team Type Answers). This must be someone outside the team.
   2. Online direct input into Team Effectiveness Survey Tool
      1. Post the document in a shared folder.
      2. Instruct individuals to select one of the numbered columns and enter their information into tab 2. Data – Effectiveness Answers and tab 3. Data – Team Type Answers.
      3. To protect anonymity and keep results confidential, suggest each person opens document in "Cognito mode."
      4. Hide the Summary and Results tabs to avoid team members previewing them.

Download the IT Team Effectiveness Survey Results Tool

Paper-Based Cautions & Considerations

• Heavily dependent on a trusted third party for genuine results
• Can be time consuming to enter the results

Online Direct Cautions & Considerations

• Ensure that users keep to the same numbered column across both entry tabs
• Seeing other team members' responses may influence others
• Least amount of administration

Phase 2

Review Results and Action Plan

This phase will walk you through the following activities:

• Analyzing and debriefing the results to determine themes and patterns to come to a team consensus on what to focus on.
• Facilitated activities to drive awareness, build co-created definitions of what an effective team looks like, and identify solutions the team can undertake to be more effective.

This phase involves the following participants:

• Leader of the team
• All team members

Deliverables:

• A presentation that communicates the team assessment results
• A plan for effectively delivering the assessment results

Phase 2: Build a plan to review results and create an action plan

Reviewing assessment results and creating an improvement action plan is best accomplished through a team meeting.

Analyzing and preparing for the team meeting may be done by:

• The person charged with team effectiveness (i.e. team coach).
• For teams that are seriously struggling with team effectiveness, the coach should complete this step in its entirety.
• The team coach and the team lead.
• Truly effective teams are self-reliant. Begin upskilling team leads by involving team leads from the start.

1. Analyze team assessment results
2. Prepare to communicate results to the team
3. Select team activities that will guide the identification of action items and next steps
4. Facilitate the team meeting

2.1 Analyze results

Health Dials

1. Once the results are final, review the Health Dials for each of the areas.
   1. For each area of the team's effectiveness
      • Red indicates a threat – this will derail the team and you will require an external person to help facilitate conversations.
        It would be recommended to contact us for additional guidance if this is one of your results.
      • Yellow is a growth opportunity.
      • Green is a strength and pay attention to where the dial is – deep into strength or just past the line?
   2. Think about these questions and record your initial reactions.
      1. What surprises you – either positively or negatively?
      2. What areas are as expected?
      3. What behaviors are demonstrated that support the results?

Prioritize one to two factors for improvement by selecting those with:

• The lowest overall score.
• The highest variance in responses.
• If psychological safety is low, be sure to prioritize this factor; it is the foundation of any effective team.

2.2 Analyze results

Alignment of Responses

1. The alignment of responses area provides you with an overview of the range of responses from the team for each area.
   • The more variety in the bars indicates how differently each person is experiencing the team.
   • The more aligned the bars are the more shared the experiences.

The flatter the bars are across the top, the more agreement there was. Factors that show significant differences in opinion should be discussed to diagnose what is causing the misalignment within your team.

2. Recommendation is to look at high scores and the alignment and lower scores and the alignment to determine where you may want to focus.

The alignment chart below shows varied responses; however, there are two distinct patterns. This will be an important area to review.
Things to think about:

• Are there new team members?
• Has there been a leadership change?
• Has there been a change that has impacted the team?

2.3 Analyze results

Team Characteristics and Stakes

1. Team Characteristics. Use the Team Type Results tab in the IT Team Effectiveness Assessment Tool to identify how the team characterizes itself along the High-Low Scale. The closer the dark blue bar is to the right or left suggests to which degree the team views the characteristic.
   1. Interdependence highlights the team's view on how interconnected and dependent they are on each other to get work done. Think of examples where they should be sharing or collaborating, and they are not.
   2. Virtual describes the physicality of the team. This area has changed a lot since 2020; however, it's still important to note if the team shares the same understanding of work location. Are they thinking of team members in a different geography or referring to hybrid work?
   3. Decision making describes the scale of one decision maker or many. Where are most decisions made by on your team or who is making them?
   4. Stability refers to the degree to which the team stays the same – no membership change or turnover. It can be defined by length of time the group has been together. Looking at this will help understand alignment results. If alignment is varied, one might expect a less stable team.
2. Stakes and Pressure
   1. Pressure refers to the conditions in which the team must work. How urgent are requests?
   2. Stakes refers to the degree of impact the work has. Will outputs impact safety, health, or a service?
   3. This category can be reviewed against decision making – high pressure, high stakes environments usually have a high concentration of authority. Low pressure, low stakes decisions can also be made either by one person as there is relatively no impact or with many as you have time to get many perspectives.
   4. This area informs what your decision-making protocols should look like.

2.4 Prepare for meeting

1-2 hours

1. Select a facilitator
   • The right person to facilitate the meeting and present the results is dependent upon the results themselves, the team lead's comfort level, and the root and degree of team dysfunction.
   • Typically, the team lead will facilitate and present the results. However, it will be more appropriate to have a member of the HR team or an external third party facilitate.
2. Set the agenda (recommended sample to the right) that ensures:
   • Team members reflect on the results and discuss reaction to the results. (E.g. Are they surprised? Why/why not?)
   • Results are clearly understood and accepted by team members before moving on to activities.
   • The aim of the meeting is kept in mind. The purpose of the team meeting is to involve all team members in the creation of an effectiveness improvement plan.
3. Customize the Facilitation Guide and activities in the Improve IT Team Effectiveness Facilitation Guide. (Activities are aligned with the four factors in the IDEA model.)
   • Identify a clear objective for each activity given the team assessment results. (E.g. What are the areas of improvement? What is the desired outcome of the activity?)
   • Review and select the activities that will best achieve the objectives.
   • Customize and prepare for chosen activities appropriately.
   • Obtain all necessary materials.
   • Practice by anticipating and preparing for questions, objectives, and what you will say and do.

Facilitation Factors
Select a third-party facilitator if:

• The team lead is uncomfortable.
• The leadership or organization is implicated in the team's dysfunction, a third party can be sought in place of HR.
• Regardless of who facilitates, it is critical that the team lead understands the process and results and is comfortable answering any questions that arise.

Agenda

• Review the IDEA Model.
• Discuss the assessment results.
• Invite team members to reflect on the results and discuss reaction to the results.
• Ensure results are clearly understood and accepted.
• Examine team challenges and strengths through selected team activities.
• Create a team charter and effectiveness improvement plan.

Materials

• IT Team Effectiveness Activities Facilitation Guide
• IT Team Effectiveness Survey results

Participants

• Leader

2.5 Run the meeting

2-3 hours

Facilitate the team meeting and agree on the team effectiveness improvement plan.

Work with the team to brainstorm and agree on an action plan of continuous improvements.

By creating an action plan together with the team, there is greater buy-in and commitment to the activities identified within the action plan.

Don't forget to include timelines and task owners in the action plan – it isn't complete without them.

Document final decisions in Info-Tech's Improve IT Team Effectiveness Action Plan Tool.

Review activity Develop Team Charter in the Improve IT Team Effectiveness Facilitation Guide and conclude the team meeting by creating a team charter. With a team charter, teams can better understand:

• Team objectives
• Team membership and roles
• Team ground rules

Facilitation Factors

Encourage and support participation from everyone.

Be sure no one on the team dismisses anyone's thoughts or opinions – they present the opportunity for further discussion and deeper insight.

Watch out for anything said or done during the activities that should be discussed in the activity debrief.

Debrief after each activity, outlining any lessons learned, action items, and next steps.

Agenda

• Review the IDEA Model.
• Discuss the assessment results.
• Invite team members to reflect on the results and discuss reaction to the results.
• Ensure results are clearly understood and accepted.
• Examine team challenges and strengths through selected team activities.
• Create a team charter and effectiveness improvement plan.

Materials

• IT Team Effectiveness Activities Facilitation Guide
• Whiteboard/flip charts
• Sticky notes
• IT Team Effectiveness Survey results

Participants

• Leader
• Team Members
• Optional – External Facilitator

Phase 3

Document and measure

This phase will walk you through the following activities:
Building your team charter that will include:

• Team vision, mission, and goals
• Roles and responsibilities of each member
• Decision-making responsibilities and process
• How information will be shared and by whom
• Ways to build psychological safety on the team

This phase involves the following participants:

• Leader of the team
• All team members

Document and agree to regular check-ins to reassess.

As a team it will be important to drive your brainstormed solutions into an output that is co-created.

• Agree to what actions can be implemented.
• Capture agreed-to team goals, roles, responsibilities, and decision process into a team charter. Also include your communication protocol that articulates how information will be shared in future.

1. Review suggestions and actions
2. Capture in team charter
3. Assign metrics to measure success and determine when to review
4. Complete ongoing check-ins with team through team meeting and plan to reassess if agreed to

Team Charter

Never assume everyone "just knows."

Set clear expectations for the team's interactions and behaviors.

• Some teams call this a team agreement, team protocol, or ways of working. Determine the naming convention that works best for your team and culture.
• This type of document saw a renewed popularity during COVID-19 as face-to-face interactions were more difficult, and as teams, news ways to work needed to be discovered, shared, and documented.
• A co-created team charter is a critical component to onboarding new employees in the hybrid world.

Info-Tech Insight – State of Hybrid Work in IT

One contributor to the report shared the effort and intention around maintaining their culture during the pandemic. The team agreement created became a critical tool to enable conversations between leaders and their team – it was not a policy document.

Team effectiveness is driven through thoughtful planned conversations. And it's a continued conversation.

Download the IT Team Charter Template

Establish Baseline Metrics

Baseline metrics will be improved through:

Identify the impact that improved team effectiveness will have on the organization.
Determine your baseline metrics to assess the success of your team interventions and demonstrate the impact to the rest of the organization using pre-determined goals and metrics.
Share success stories through:

• Newsletters or email announcements
• Team meetings
• Presentations to business partners or the organization

Reassess team effectiveness

Reassess and identify trends after they have worked on key focus areas for improvement.

Track the team's progress by reassessing their effectiveness six to twelve months after the initial assessment.
Identify if:

• Team characteristics have changed.
• Areas of team strengths are still a source of strength.
• Areas for improvement have, in fact, improved.
• There are opportunities for further improvement.

As the team matures, priorities and areas of concern may shift; it is important to regularly reassess team effectiveness to ensure ongoing alignment and suitability.
Note: It is not always necessary to conduct a full formal assessment; once teams become more effective and self-sufficient, informal check-ins by team leads will be sufficient.

If you assess team effectiveness for multiple teams, you have the opportunity to identify trends:

• Are there common challenges within teams?
• If so, what are they?
• How comfortable are teams with intervention?
• How often is outside help required?

Identifying these trends, initiatives, training, or tactics may be used to improve team effectiveness across the department – or even the organization.

Teams are ultimately accountable for their own effectiveness.

As teams mature, the team lead should become less involved in action planning. However, enabling truly effective teams takes significant time and resources from the team lead.

Use the action plan created and agreed upon during the team meeting to hold teams accountable:

• Ensure teams follow through on action items.
• Ensure you are continuously assessing team effectiveness (formally or informally).

The team coach should have a plan to transition into a supportive role by:

• Providing teams with the knowledge, resources, and tools required to improve and sustain high effectiveness.
• Providing team members and leads with a safe, open, and honest environment.
• Stepping in as an objective third party when required.

If the team continues to face barriers

Other important information: If team effectiveness has not significantly improved, other interventions may be required that are beyond the scope of this project.

The four factors outlined in the IDEA Model of team effectiveness are very important, but they are not the only things that have a positive or negative impact on teams. If attempts to improve the four factors have not resulted in the desired level of team effectiveness, evaluate other barriers:

For organizational culture, ask if performance and reward programs do the following:

• Value teamwork alongside individual achievement and competition
• Provide incentives that promote a focus on individual performance over team performance
• Reward or promote those who sabotage their teams

For learning and development, ask:

• Is team effectiveness included in our manager or leadership training?
• Do we offer resources to employees seeking to improve their teamwork competencies?

If an individual team member's or leader's performance is not meeting expectations, potential remedies include a performance improvement plan, reassignment, and termination of employment.

These kinds of interventions are beyond the control of the team itself. In these cases, we recommend you consult with your HR department; HR professionals can be important advocates because they possess the knowledge, influence, and authority in the company to promote changes that support teamwork.

Related Info-Tech Research

Redesign Your IT Department

• You could have the best IT employees in the world, but if they aren't structured well your organization will still fail in reaching its vision.
• Increase the effectiveness of IT as a function.
• Provide employees with clarity in their roles and responsibilities.

Build an IT Employee Engagement Program

• With the growing IT job market, turnover is a serious threat to IT's ability to deliver seamless value and continuously drive innovation.
• Engagement initiatives are often seen as being HR's responsibility; however, IT leadership needs to take accountability for the retention and productivity of their employees in order to drive business value.

Info-Tech Leadership Programs

• Development of the leadership mind should never stop. This program will help IT leaders continue to craft their leadership competencies to navigate the ever-changing world in which we operate.
• Actively delegate responsibilities and opportunities that engage and develop team members to build on current skills and prepare for the future.

Research Contributors and Experts

Carlene McCubbin
Practice Lead
Info-Tech Research Group

Nick Kozlo
Senior Research Analyst
Info-Tech Research Group

Heather Leier-Murray
Senior Research Analyst
Info-Tech Research Group

Stephen O'Conner
Executive Counselor
Info-Tech Research Group

Jane Kouptsova
Research Director
Info-Tech Research Group

Dr. Julie D. Judd, Ed.D.
Chief Technology Officer
Ventura County Office of Education

Works Cited

Aminov, I., A. DeSmet, and G. Jost. "Decision making in the age of urgency." McKinsey. April 2019. Accessed January 2023.
Duhigg, Charles. "What Google Learned From Its Quest to Build the Perfect Team." The New York Times, 25 Feb. 2016. Accessed January 2023.
Edmondson, Amy. "Psychological Safety and Learning Behavior in Work Teams." Administrative Science Quarterly, vol. 44, no. 2, June 1999, pp. 350-383.
Gardner, Kate. "Julie Judd – Ventura County Office of Education." Toggle, 12 Sept. 2022. Accessed January 2023.
Google People Operations. "Guide: Understand Team Effectiveness." reWork, n.d. Accessed February 2023.
Harkins, Phil. "10 Leadership Techniques for Building High-Performing Teams." Linkage Inc., 2014. Accessed 10 April 2017.
Heath, C. and D. Heath. Decision: How to make better choices in life and work. Random House, 2013, ISBN 9780307361141.
Hill, Jon. "What is an Information Silo and How Can You Avoid It." Bloomfire, 23 March 2022. Accessed January 2023.
"IT Team Management Software for Enhanced Productivity." Freshworks, n.d. Accessed January 2023.
Jackson, Brian. "2022 Tech Trends." Info-Tech Research Group, 2022. Accessed December 2022.
Kahneman, Daniel. Thinking fast and slow. Farrar, Straus and Giroux. 2011.
Kouptsova, J., and A. Mathieson. "State of Hybrid Work in IT." Info-Tech Research Group, 2023. Accessed January 2023.
Mayfield, Clifton, et al. "Psychological Collectivism and Team Effectiveness: Moderating Effects of Trust and Psychological Safety." Journal of Organizational Culture, Communications and Conflict, vol. 20, no. 1, Jan. 2016, pp. 78-94.
Rock, David. "SCARF: A Brain-Based Model for Collaborating With and Influencing Others." NeuroLeadership Journal, 2008. Web.
"The State of High Performing Teams in Tech Hypercontext." Hypercontext. 2022. Accessed November 2022.
Weick, Carl, and Kathleen Sutcliff. Managing the unexpected. John Wiley & Sons, 2007.
"Workplace Conflict Statistics: How we approach conflict at work." The Niagara Institute, August 2022. Accessed December 2022.

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 an Effective SEO Keyword Strategy
Update your on-page SEO strategy with competitively relevant keywords.

Analyst Perspective

Most marketers fail in their SEO efforts because they focus on creating content for computers, not people.

Leading search engine optimization methods focus on creating and posting relevant keyword-rich content, not just increasing page rank. Content and keywords should move a buyer along their journey, close a sale, and develop long-term relationships. Unfortunately, many SEO specialists focus on computers, not the buyer. What's even more concerning is that up to 70% of SaaS businesses have already been impacted by outdated and inefficient SEO techniques. Poor strategies often focus on ballooning SEO metrics in the short-term instead of building the company's long-term PageRank.

Best-in-class digital marketers stop chasing the short-term highs and focus on long-term growth. This starts with developing a competitive keyword strategy and updating website content with the new keywords.

SEO is a large topic, so we have broken the strategy into small, easy-to-implement steps, taking the guesswork out of how to use the data from SEO tools and giving CMOs a solid path to increase their SEO results.

Terra Higginson
Marketing Research Director
SoftwareReviews

Executive Summary

Your Challenge

Digital marketers working with an outdated or bad SEO strategy often see:

• Declining keyword ranking and traffic
• Poor keyword strategy
• On-page errors

Search algorithms change all the time, which means that the strategy is often sitting on the sifting sands of technology, making SEO strategies quickly outdated.

Common Obstacles

Digital marketers are responsible for developing and implementing a competitive SEO strategy but increasingly encounter the following obstacles:

• SEO practitioners that focus on gaming the system
• Ever-changing SEO technology
• Lack of understanding of the best SEO techniques
• SEO techniques focus on the needs of computers, not people
• Lack of continued investment

SoftwareReviews' Approach

Using the SoftwareReviews methodology, digital marketers are able to break up their SEO project and data into bite-sized, actionable steps that focus on long-term improvement. Our methodology includes:

• Competitive keyword research and identification of opportunities
• On-page keyword strategy

Our methodology will take a focused step-by-step strategy in a series of phases that will increase PageRank and competitive positioning.

SoftwareReviews' SEO Methodology

In this blueprint, we will cover:

Good SEO vs. Poor SEO Techniques

The difference between good and bad SEO techniques.

Companies With Great SEO…

Keyword Strategy

• Have identified a keyword strategy that carves out targets within the white space available between themselves and the competition.

Error-Free Site

• Have error-free sites without duplicate content. Their URLs and redirects are all updated. Their site is responsive, and every page loads in under two seconds.

Pillar & Content Clusters

• Employ a pillar and content cluster strategy to help move the buyer through their journey.

Authentic Off-Page Strategy

• Build an authentic backlink strategy that incorporates the right information on the right sites to move the buyer through their journey.

SEO Terms Defined

A glossary to define common Phase 1 SEO terms.

Search Volume: this measures the number of times a keyword is searched for in a certain time period. Target keywords with a volume of between 100-100,000. A search volume greater than 100,000 will be increasingly difficult to rank (A Beginner's Guide to Keyword Search Volume, 2022, Semrush).

Keyword Difficulty: the metric that quantifies how difficult it will be to rank for a certain keyword. The keyword difficulty percentage includes the number of competitors attempting to rank for the same keyword, the quality of their content, the search intent, backlinks, and domain authority (Keyword Difficulty: What Is It and Why Is It Important? 2022, Semrush).

Intent: this metric focuses on the intent of the user's search. All search intent is categorized into Informational, Commercial, Navigational, and Transactional (What Is Search Intent? A Complete Guide, 2022, Semrush).

On-Page SEO: refers to the practice of search engine optimizing elements of your site such as title tags, internal links, HTML code, URL optimization, on-page content, images, and user experience.

Off-Page SEO: refers to the practice of optimizing brand awareness (What Is Off-Page SEO? A Comprehensive Guide, 2022, Semrush).

H1: HTML code that tells a search engine the title of the page (neilpatel.com).

SEO Tool: A subscription-based all-in-one search engine optimization MarTech tool.

Google's mission is to organize the world's information and make it universally accessible and useful… We believe Search should deliver the most relevant and reliable information available.
– An excerpt from Google's mission statement

Your Challenge

Google makes over 4.5k algorithm changes per year1, directly impacting digital marketing search engine optimization efforts.

Digital marketers with SEO problems will often see the following issues:

• Keyword ranking – A decline in keyword ranking is alarming and results in decreased PageRank.
• Bounce rate – Attracting the wrong audience to your site will increase the bounce rate because the H1 doesn't resonate with your audience.
• Outdated keywords – Many companies are operating on a poor keyword strategy, or even worse, no keyword strategy. In addition, many marketers haven't updated their strategy to include pillar and cluster content.
• Errors – Neglected sites often have a large number of errors.
• Bad backlinks – Neglected sites often have a large number of toxic backlinks.

The best place to hide a dead body is on page two of the search results.
– Huffington Post

Common Obstacles

Digital marketers are responsible for developing and executing a competitive SEO strategy but increasingly encounter the following obstacles:

• Inefficient and ineffective SEO practitioners.
• Changing SEO technology and search engine algorithms.
• Lack of understanding of the best-in-class SEO techniques.
• Lack of a sustainable plan to manage the strategy and invest in SEO.

SEO is a helpful activity when it's applied to people-first content. However, content created primarily for search engine traffic is strongly correlated with content that searchers find unsatisfying.
– Google Search Central Blog

Benefits of Proper SEO

A good SEO keyword strategy will create long-term, sustainable SEO growth:

• Write content for people, not algorithms – Good SEO prioritizes the needs of humans over the needs of computers, being ever thoughtful of the meaning of content and keywords.
• Content that aligns with intent – Content and keyword intent will align with the buyer journey to help move prospects through the funnel.
• Competitive keyword strategy – Find keyword white space for your brand. Keywords will be selected to optimize your ranking among competition with reasonable and sustainable targets.
• Actionable and impactful fixes – By following the SoftwareReviews phases of SEO, you will be able to take a very large task and divide it into conquerable actions. Small improvements everyday lead to very large improvements over time.

Digital Marketing SEO Stats

61%
61% of marketers believe that SEO is the key to online success.
Source: Safari Digital

437%
Updating an existing title tag with an SEO optimised one can increase page clicks by more than 437%.
Source: Safari Digital

Good SEO Aligns With Search Intent

What type of content is the user searching for? Align your keyword to the logical search objective.

Informational

This term categorizes search intent for when a user wants to inform or educate themselves on a specific topic.

Commercial

This term categorizes search intent for when a user wants to do research before making a purchase.

Transactional

This term categorizes search intent for when a user wants to purchase something.

Navigational

This term categorizes search intent for when a user wants to find a specific page.

SoftwareReviews' Methodology toCreate an Effective SEO Strategy

Guided Implementation

What does a typical GI on this topic look like?

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 between 8 to 12 calls over the course of 1 to 2 months.

SoftwareReviews offers various levels of support to best suit your needs

Insight Summary

People-First Content

Best-in-class SEO practitioners focus on people-first content, not computer-first content. Search engine algorithms continue to focus on how to rank better content first, and a strategy that moves your buyers through the funnel in a logical and cohesive way will beat any SEO trick over the long run.

Find White Space

A good SEO strategy uses competitive research to carve out white space and give them a competitive edge in an increasingly difficult ranking algorithm. An understanding of the ideal client profile and the needs of their buyer persona(s) sit as a pre-step to any good SEO strategy.

Optimize On-Page Keywords

By optimizing the on-page strategy with competitively relevant keywords that target your ideal client profile, marketers are able to take an easy first step at improving the SEO content strategy.

Understand the Strategy

If you don't understand the strategy of your SEO practitioner, you are in trouble. Marketers need to work hand in hand with their SEO specialists to quickly uncover gaps, create a strategy that aligns with the buyer persona(s), and execute the changes.

Quality Trumps Quantity

The quality of the prospect that your SEO efforts bring to your site is more important than the number of people brought to your site.

Stop Here and Ask Yourself:

• Do I have an updated (completed within the last two years) buyer persona and journey?
• Do I know who the ICP (ideal client profile) is for my product or company?

If not, stop here, and we can help you define your buyer persona and journey, as well as your ideal client profile before moving forward with SEO Phase 1.

The Steps to SEO Phase 1

The Keyword Strategy

1. Current Keywords
   • Identify the keywords your SEO strategy is currently targeting.
2. Competitive Analysis
   • Research the keywords of competitor(s). Identify keyword whitespace.
3. New Target Keywords
   • Identify and rank keywords that will result in more quality leads and less competition.
4. Product & Service Pages
   • Identify your current product and service pages. These pages represent the easiest content to update on your site.
5. Individual Page Update
   • Develop an SEO strategy for each of your product and service pages, include primary target keyword, H1, and title tags, as well as keyword-rich description.

Resources Needed for Search Engine Optimization

Consider the working skills required for search engine optimization.

Required Skills/Knowledge

• SEO
• Web development
• Competitive analysis
• Content creation
• Understanding of buyer persona and journey
• Digital marketing

Suggested Titles

• SEO Analyst
• Competitive Intelligence Analyst
• Content Marketing Manager
• Website Developer
• Digital Marketing Manager

Digital Marketing Software

• CMS that allows you to easily access and update your content

SEO Software

• SEO tool

Step 1: Current Keywords

Use this sheet to record your current keyword research.

Use your SEO tool to research keywords and find the following:
Use a quality tool like SEMRush to obtain SEO data.

1. Keyword difficulty
2. Search volume
3. Search intent

Step 2: Competitive Analysis

Use this sheet to guide the research on your competitors' keywords.

Use your SEO tool to find the following:

1. Top organic keywords
2. Ranking of keywords
3. Domain authority and trust
4. Position changes

Step 3: New Target Keywords

Use this sheet to record target keywords that have a good volume but are less competitive. The new target keywords should align with your buyer persona and their journey.

Use your SEO tool to research keywords and find the following:
Use a quality tool like SEMRush to obtain SEO data.

1. Keyword difficulty
2. Search volume
3. Search intent

Step 4: Product & Service Pages

Duplicate this page so that you have a separate page for each URL from Step 4

Use this sheet to identify your current product and service pages.

Use your SEO tool to find the following:

1. Current rank
2. Current keywords

Step 5: Individual Page Strategy

Develop a keyword strategy for each of your product and service pages. Use a fresh page for each URL.

Date last optimized:
mm/dd/yyyy

Bibliography

Council, Y. "Council Post: The Rundown On Black Hat SEO Techniques And Why You Should Avoid Them." Forbes, 2022. Accessed September 2022.

"Our approach – How Google Search works." Google Search. Accessed September 2022.

"The Best Place to Hide a Dead Body is Page Two of Google." HuffPost, 2022. Accessed September 2022.

Patel, Neil. "How to Create the Perfect H1 Tag for SEO." neilpatel.com. Accessed September 2022.

Schwartz, B. "Google algorithm updates 2021 in review: Core updates, product reviews, page experience and beyond." Search Engine Land, 2022. Accessed September 2022.

Schwartz, B. "Google algorithm updates 2021 in review: Core updates, product reviews, page experience and beyond." Search Engine Land, 2022. Accessed September 2022.

Select a Sourcing Partner for Your Application Development Team

Choose the right partner to enable your firm to maximize the value realized from your sourcing strategy.

Analyst Perspective

Selecting the right partner for your sourcing needs is no longer a cost-based exercise. Driving long-term value comes from selecting the partner who best matches your firm on a wide swath of factors and fits your needs like a glove.

Sourcing in the past dealt with a different kind of conversation involving two key questions: Where will the work be done? How much will it cost? How people think about sourcing has changed significantly. People are focused on gaining a partner, and not just a vendor to execute a single transaction. They will add skills your team lacks, and an ability to adapt to your changing needs, all while ensuring you operate within any constraints based on your business. Selecting a sourcing partner is a matching exercise that requires you to look deep into yourself, understand key factors about your firm, and then seek the partner who best meets your profile.

Dr. Suneel Ghei Principal Research Director, Application Development Info-Tech Research Group

Executive Summary

Info-Tech Insight

Successfully selecting a sourcing partner is not a simple RFP exercise to choose the lowest cost. It is a complex process of introspection, detailed examination of partners and locations, and matching the fit. It requires you to seek a partner that is the Yin to your Yang, and failure is not an option.

You need a new source for development resources

You are facing immediate challenges that require a new approach to development resourcing.

• Your firm is under fire; you are facing pressures financially from clients and your competitors.
• Your pace of innovation and talent sourcing is too slow and too limiting.
• Your competition is moving faster and your clients are considering their options.
• Revenues and costs of development are trending in the wrong direction.
• You need to act now to avoid spiraling further.

Given how critical our applications are to the business and our clients, there is no room for error in choosing our partner.

A study of 121 firms outsourcing various processes found that 50% of those surveyed saw no gains from the outsourcing arrangement, so it is critical to make the right choice the first time.

Source: Zhang et al

Big challenges await you on the journey

The road to improving sourcing has many potholes.

• In a study of 121 firms who moved development offshore, almost 50% of all outsourcing and offshoring initiatives do not achieve the desired results.
• In another study focused on large corporations, it was shown that 70% of respondents saw negative outcomes from offshoring development.
• Globalization of IT Services and the ability to work from anywhere have contributed to a significant increase in the number of development firms to choose from.
• Choosing and implementing a new partner is costly, and the cost of choosing the wrong partner and then trying to correct your course is significant in dollars and reputation:
  • Costs to find a new partner and transition
  • Lost revenue due to product issues
  • Loss of brand and reputation due to poor choice
• The wrong choice can also cost you in terms of your own resources, increasing the risk of losing more knowledge and skills.

A survey of 25 large corporate firms that outsourced development offshore found that 70% of them had negative outcomes.

(Source: University of Oregon Applied Information Management, 2019)

Info-Tech’s approach

Selecting the right partner is a matching exercise.

Selecting the right partner is a complex exercise with many factors

1. Look inward. Assess your culture, your skills, and your needs.

• Market
• People
• Culture
• Technical aspects

• Sourcing Strategy
• Priorities
• Profile

• Define RFx
• Target Partners
• Evaluate

• Contract Partner
• Develop Goals
• Create Process and Metrics

The Info-Tech difference:

1. Assess your own organization’s characteristics and capabilities in four key areas.
2. Based on these characteristics and the sourcing strategy you are seeking to implement, build a profile for your perfect partner.
3. Define an RFx and assessment matrix to survey the market and select the best partner.
4. Implement the partner with process and controls to manage the relationship, built collaboratively and in place day 1.

Insight summary

Addressing the myth – Single country offshoring or outsourcing

Research shows that a multi-country approach has a higher chance of success.

• Research shows that firms trying their own captive development centers fail 20% of the time. ( Journal of Information Technology, 2008)
• Further, the overall cost of ownership for an offshore center has shown to be significantly higher than the cost of outsourcing, as the offshore center requires more internal management and leadership.
• Research shows that offshoring requires the offshore location to also house business team members to allow key relationships to be built and ensure more access to expertise. (Arxiv, 2021)
• Given the specificity of employment laws, cultural differences, and leadership needs, it is very beneficial to have a Corporate HR presence in countries where an offshore center is being set up. (Arxiv, 2021)
• Lastly, given the changing climate on security, geopolitical changes, and economic factors, our research with service providers and corporate clients shows a need to have more diversity in provider location than a single center can provide.

Info-Tech Insight

Long-term success of sourcing requires more than a development center. It requires a location that houses business and HR staff to enable the new development team to learn and succeed.

Addressing the myth – Outsourcing is a simple RFP for skills and lowest cost

Success in outsourcing is an exercise in finding a match based on complex factors.

• In the past, outsourcing was a simple RFP exercise to find the cheapest country with the skills.
• Our research shows this is no longer true; the decision is now more complex.
• Competition has driven costs higher, while time business integration and security constraints have served to limit the markets available.
• Company culture fit is key to the ability to work as one team, which research shows is a key element in delivery of long-term value. (University of Oregon, 2019).
• These are some of the many factors that need to be considered as you choose your outsourcing partner.
• The right decision is to find the vendor that best matches the current state of your culture, meets your market constraints, and will allow for best integration to your team – it's not about cheapest or pure skills. (IEEE Access, 2020)

Info-Tech Insight

Finding the right outsourcing vendor is an exercise in knowing yourself and then finding the best match to align with your key traits. It's not just costs and skills, but the partner who best matches with your ability to mitigate the risks of outsourcing.

Phase 1

Look inward to gain insight on key factors

This phase will walk you through assessing and documenting the key driving factors about your firm and the current situation.

By defining these factors, you will be able to apply this information in the matching process to select the best fit in a partner.

This phase involves the following participants:

Line of Business leaders

Technology leaders

Key criteria to assess your firm

Research shows firms must assess themselves in different areas.

Market factors

• Who are your clients and your competitors, and what legal constraints do you face?

People / Process factors

• What employee skills are you seeking, what is your maturity in product management and stakeholder engagement, and what languages are spoken most predominantly?

Cultural factors

• What is your culture around communications, collaboration, change management, and conflict resolution?

Technical factors

• What is your current / future technical platform, and what is the maturity of your applications?

Info-Tech Best Practice

When assessing these areas, consider where you are today and where you want to go tomorrow, as choosing a partner is a long-term endeavor.

Step 1.1

Assess your market factors

Activities

1.1.1 Review your client list and future projections to determine your market factors.

1.1.2 Review your competitive analysis to determine your competitive factors

This step involves the following participants:

Business leaders

Product Owners

Technology leaders

Outcomes of this step

Details of key market factors that will drive the selection of the right partner.

Market factors

The Market has a lot to say about the best match for your application development partner.

Research in the space has defined key market-based factors that are critical when selecting a partner.

1. Market sectors you service or plan to service – This is critical, as many market sectors have constraints on where their data can be accessed or stored. These restrictions also change over time, so they must be consistently reviewed.

• E.g. Canadian government data must be stored and only accessed in Canada.
• E.g. US Government contracts require service providers to avoid certain countries.

Info-Tech Insight

Understanding your current and future market factors ensure that your business can not only be successful with the chosen partner today, but also in the future.

1.1.1 Assess your market factors

30 min

Market factors

1. Group your current client list into three categories:
   1. Those that have no restrictions on data security, privacy or location.
   2. Those that ask for assurances on data security, privacy and location.
   3. Those clients who have compliance restrictions related to data security, privacy, and location.
2. Categorize future markets into the same three categories.
3. Based on revenue projections, estimate the revenue from each category as a percentage of your total revenue.

Download the Select a Sourcing Partner Presentation Template

Assess your market factors

1.1.2 Review your competitive factors

30 min

Competitive factors

1. List your largest competitors.
2. Document their sourcing strategies for their development team – are they all onshore or nearshore? Do they outsource?
3. Based on this, identify competitive threats based on changing sourcing strategies.

Download the Select a Sourcing Partner Presentation Template

Review your competitive factors

Step 1.2

Consider your people-related factors

Activities

1.2.1 Define your people factors

1.2.2 Assess your process factors

This step involves the following participants:

Technical leaders

Outcomes of this step

Details of key people factors that will drive the selection of the right partner.

People / process factors

People and process have a large hand in the success or failure of a partner relationship.

• Alignment of people and process are critical to the success of the partner relationship over the long term.
• In research on outsourcing / offshoring, Rahman et al identified ten factors that directly impact success or failure in offshoring or outsourcing of development.
• Key among them are the following:
  • Employee skills
  • Project management
  • Maturity of process concerning product and client management
  • Language barrier

Info-Tech Insight

People are a critical resource in any sourcing strategy. Making sure the people and the processes will mesh seamlessly is how to ensure success.

1.2.1 Define your people factors

30 min

Skills Inventory

1. List skills needed in the development team to service current needs.
2. Based on future innovation and product direction, add skills you foresee needing in the next 12-24 months. Where do you see a new technology platform (e.g. move from .NET to Java) or innovation (addition of Mobile)?
3. List current skills present in the team.
4. Identify skills gaps.

Download the Select a Sourcing Partner Presentation Template

Assess your people - Skills inventory

1.2.2 Assess your process factors

30 min

Process factors

1. Do you have a defined product ownership practice?
2. How mature is the product ownership for the product you are seeking to change sourcing for (H/M/L)?
3. Do you have project management principles and governance in place for software releases?
4. What is the relative maturity / skill in the areas you are seeking sourcing for (H/M/L)?

Download the Select a Sourcing Partner Presentation Template

Assess your process factors

Step 1.3

Review your current culture

Activities

1.3.1 Assess your communications factors

1.3.2 Assess your conflict resolution factors

This step involves the following participants:

Technical leaders

Product owners

Project managers

Outcomes of this step

Details of key culture factors that will drive the selection of the right partner.

Cultural factors

Organization culture fit is a driver of collaboration between the teams, which drives success.

• In their study of country attractiveness for sourcing development, Kotlarsky and Oshri point to the ability of the client and their sourcing partner to work as one team as a key to success.
• This requires synergies in many cultural factors to avoid costly miscommunications and misinterpretations that damage collaboration.
• Key factors in achieving this are:
  • Communications methodology and frequency; managing and communicating to the teams as one team vs two, and communicating at all levels, vs top down.
  • Managing the team as one integrated team, with collaboration enabled between all resources, rather than the more adversarial client vs partner approach.
  • Conflict resolution strategies must align so all members of the extended team work together to resolve conflict vs the traditional “Blame the Contractors”.
  • Strong change management is required to keep all team members aligned.

Info-Tech Insight

Synergy of culture is what enables a good partner selection to become a long-term relationship of value.

1.3.1 Assess your communications factors

30 min

1. List all the methods you use to communicate with your development team – face to face, email, conference call, written.
2. For each form of communication confirm frequency, medium, and audience (team vs one-on-one)
3. Confirm if these communications take into account External vs Internal resources and different time zones, languages, and cultures.
4. Is your development team broken up into teams by function, by location, by skill, etc., or do you operate as one team?

Download the Select a Sourcing Partner Presentation Template

Assess your communications strategy

1.3.2 Assess your conflict resolution factors

30 min

1. How does your organization handle the following types of conflict? Rate from 1-5, with 1 being hierarchical and 5 being openly collaborative.
   1. Developers on a team disagree.
   2. Development team disagrees with manager.
   3. Development team disagrees with product owner.
   4. Development team disagrees with line of business.
2. Rate each conflict resolution strategy based on effectiveness.
3. Confirm if this type of strategy is used for internal and external resources, or internal only.

Download the Select a Sourcing Partner Presentation Template

Assess your conflict resolution strategy

Step 1.4

Document your technical factors

Activities

1.4.1 Document your product / platform factors

1.4.2 Document your environment details

This step involves the following participants:

Technical leaders

Product owners

Outcomes of this step

Details of key technical factors that will drive the selection of the right partner.

Technical factors

Technical factors are still the foundation for a Development sourcing relationship.

• While there are many organizational factors to consider, the matching of technological factors is still the root on which the sourcing relationship is built; the end goal is to build better software.
• Key technical Items that need to be aligned based on the research are:
  • Technical infrastructure
  • Development environments
  • Development methodology and tools
  • Deployment methodology and tools
  • Lack of/poor-quality technical documentation
• Most RFPs focus purely on skills, but without alignment on the above items, work becomes impossible to move forward quickly, limiting the chances of success.

Info-Tech Insight

Technical factors are the glue that enables teams to function together. Ensuring that they are fully integrated is what enables team integration; seams in that integration represent failure points.

1.4.1 Document your product / platform factors

30 mins

1. How many environments does each software release go through from the start of development through release to production?
2. What is the infrastructure and development platform?

Download the Select a Sourcing Partner Presentation Template

Document your product / platform

1.4.2 Document your environment details

30 min

For each environment detail the following:

1. Environment on premises or in cloud
2. Access allowed to external parties
3. Production data present and unmasked
4. Deployment process: automated or manual
5. Tools used for automated deployment
6. Can the environment be restored to last known state automatically?
7. Does documentation exist on the environment, processes and procedures?

Download the Select a Sourcing Partner Presentation Template

Document Your Environment Details

Phase 2

This phase will help you to build a profile of the partner you should target in your search for a sourcing partner.

This phase involves the following participants:

Technology leaders

Procurement leaders

Product owners

Project managers

Build a profile for the right partner

• Finding the perfect partner is a puzzle to solve, an exercise between the firm and the partners.
• It is necessary to be able to prioritize and to identify opportunities where you can adapt to create a fit.
• You must also bring forward the sourcing model you are seeking and prioritize factors based on that; for example, if you are seeking a nearshore partner, language may be less of a factor.

Review factors based on sourcing choice

Different factors are more important depending on whether you are insourcing or outsourcing.

Key risks for insourcing

• Alignment on communication strategy and method
• Ability to align culturally
• Need for face-to-face relationship building
• Need for coaching skills

Key risks for outsourcing