How IT Service and Support Skills Overlap with Surviving a Zombie Apocalypse

This article was originally published in 2014, but good advice on IT service and support always rings true, no matter how the technology has evolved. We're resurfacing this article as part of our "From the Vaults" series.

Zombies attack! It’s a zombie apocalypse, and the dead have come to life. They’re hungry, and they’re looking for food. Where are you going to go? What’s your escape route? What have you stockpiled? Will you make it in this brave new world?

Poorly planned, an IT transformation can bring about its own apocalyptic realities seemingly overnight: new processes, new technologies, and new operational behaviors. IT transformations also bring forth people who are confident and competent in the new world, and people who are not. These are the IT zombies, and their very existence jeopardizes the success of the change.

When transformation happens, survival hinges on a good plan, the right gear, and practice—a lot of practice!

A Good Plan

It isn’t enough to simply survive a catastrophe. Survival isn’t the end game. It’s about thriving in the new environment where the rules have changed, the tools are different, and nothing is familiar. Thriving, and not just surviving, requires planning, and a good plan starts with people.

Identify Your Stakeholders

In a catastrophe, your stakeholders might be family, friends, supporters in the community, or men and women who know specific trades. In an IT transformation, your stakeholder universe includes:

• The core team that’s been tasked with developing the change
• Program and project leadership charged with directing the change
• The extended core team that houses the all-critical, make-it-or-break-it subject matter experts who understand the mechanics and fine details of the process, technology, and people
• Change champions or key influencers who are willing to apply their reputations and enthusiasm to the coming change
• Participants in pilots and early release activities (immediate stakeholders)
• End users that are directly affected by the change when it goes live (extended stakeholders)

Motivating people to change starts with knowing who they are, and there are usually more stakeholders than you think.

Understand Your Stakeholders

Each stakeholder in the community has specific skills and influence he or she can leverage in service of the change. In a catastrophe, some of your stakeholders will have skills that are best leveraged in the early days following the event, like building fires and erecting shelters. Other stakeholders may have skills that are more helpful later, like hunting and farming. You may have stakeholders that are resistant to change but critical to prospering in the new world. Through stakeholder analysis, you can determine how best to leverage your team members’ skills to ensure success.

Stakeholder analysis is a qualitative exercise designed to:

• Plot stakeholder groups (or individuals) based on their level of support for the change and their influence within the organization
• Identify hierarchical relationships between communities (or individuals)
• Identify influential relationships between communities (or individuals)

Move Your Stakeholders

Once your stakeholders have been plotted, focus your attention on any pockets of resistance in the organization. Highly influential dissenters negatively affect change programs. They must be swayed. Develop targeted change strategies to leverage highly engaged individuals with influence in the organizational hierarchy to convince critical dissenters to become more accepting of the change.

A change strategy is a set of three to five tasks, each of which has an owner and a timeline for execution. A task may involve meeting with an individual to have a one-on-one conversation, or meeting with a group of stakeholders for a discussion. Depending on how individual stakeholders best receive and/or provide information, the discussion may be on-site or off-site, formal or informal, in-person or virtual. An effective change strategy requires knowing how your stakeholders are motivated and using the motivational language and approach that will garner the best results.

Deming Was Onto Something

Like a true Deming cycle of plan-do-check-act, stakeholder analysis is not a one-time-use technique. Rather, it’s repeated throughout the life of the program to tell you where stakeholders are in terms of acceptance, where they need to be to realize the benefits, how to get them where they need to be to best serve the change, and whether they’ve arrived where they are needed.

The Right Gear

In a zombie apocalypse, the right gear includes water, food, a bug-out bag containing the survival essentials, running shoes, a defensible position, and a plan to get to that position with all limbs—and your brain—intact. An IT transformation isn’t so very different. In an IT change, the gear you need includes:

A Comprehensive Plan

Transforming an IT organization requires more than the tactical execution of requirements (design, build, test, and deploy). It requires an integrative plan that addresses the design and acceptance of new process and technology, and builds confidence and competence in the people who must change in order to realize the benefits identified in the business case. A comprehensive plan accounts for the essential activities across the dimensions of people, process, and technology.

Proven-Practice Processes

IT processes are the glue that binds the IT organization together. Processes define how IT groups interact and how services are conceptualized, prioritized, requested, developed, delivered, and improved. The components of a good process include activities, descriptions of what’s happening in each activity, and the roles responsible for performing them. Defining the purpose or objective, as well as the policies governing the process and metrics to measure the compliance, is required to ensure the desired behavior drives the target benefits.

A Map of Who’s Doing What

Designing a new process based on proven practices is an important first step. Gaining acceptance for the process requires that the process practitioners have a thorough understanding of how their responsibilities will change in the new world. Through the process of role mapping, job positions that will be affected by the change are identified, along with the degree of impact. Collectively, this informs:

• Communication efforts
• Learning and development efforts
• Work queue definition and assignment
• System roles and permissions

It also tells you where change champion support is required, advised, or optional, and where to deploy go-live and early life-support resources. When done well, role mapping also contributes to building competence and confidence in people who will be relied upon to act differently (and think differently) following the change.

This technique uses HR data that describes the current organization in terms of job positions. In small-group meetings of similarly affected individuals, the new process should be reviewed in detail. In many cases, this will be the first time the process has been seen by people outside of the process design team. The participants should discuss how their roles and responsibilities will change as a result of operationalizing the process, and the discussion should focus on why the change is positive.

Brand Recognition

Program branding is highly effective in distinguishing competing initiatives. Branding builds a sense of community of people in-the-know and helps filter the constant messaging presented to employees through meetings, email, and media. A prominently placed logo or slogan can entice the recipient to read a communication or watch a video.

Communication

Program communication must be derived from the business case, and the messages must be consistently shared across a variety of channels, venues, media, and vehicles. Communications must be integrated into the lifecycle of the change. They must tell a story.

Develop a Communication Plan

When determining who, when, and what kind of communication to leverage, a solid plan will help you manage the flow of communications and guarantee that the right communication gets to the right people at the right time. The communication plan should be built around the program’s milestones. Using the results of your stakeholder analysis, draft audience-specific messages focused on continuing education about the change. This type of messaging could include:

• “What’s in it for me?” (WIIFM)
• Business benefits
• “Meet Your Process Owners”
• Process fact sheets

Establish a Change Champion Network

Change champions are communication conduits whose influence and reputations are leveraged to dispel myths and promote the positive effects of the change. In many cases, candidates for change champions are obvious: they’re the people to whom others gravitate for work-related and non-work-related information. However, establishing a change champion network sometimes requires quantitative analysis. In these cases, survey your staff:

• Whom do you choose to communicate with regularly, regardless of project assignment?
• When you’re looking for a sounding board, to whom do you turn?
• Who has gone out of their way to help you professionally?

Plotting this data will help you identify centers of influence and map the flow of communication (and tribal knowledge) in the organization. You’ll also be able to identify arbiters of knowledge and bottlenecks; people on the fringe, and people on the inside; and people who span groups or broker information.

Practice!

With your plan defined, your team assembled, and the right gear on-hand, this is no time to sit back and wait for the event. As any prepper knows, you have to practice executing the plan to ensure that when zombies strike (or shamble), you’re able to react confidently and competently. In prepping for an IT apocalypse, practice, in the form of a learning continuum, is part of the integrated plan. A learning continuum creates learning opportunities throughout the life of the change, targeting different audiences in different ways while communicating consistent, audience-specific messages. Some of the techniques used in a learning continuum include simulation, learning, and development.

Simulation

Simulating a change and having affected teams react to it is an empowering and informing exercise. Simulation is one of the core principles in Agile development, wherein technology changes are made quickly for review and assessment by key stakeholders. Simulation can also be a form of gamification, where a gaming engine is used to demonstrate the request, deployment, and performance of services while tracking dollars earned or lost. In a lower-tech simulation, real-life use cases can form the basis of a practice round of process execution, performed by individuals serving in assigned process roles.

Learning and Development

Build confidence and competence by identifying and providing audience-specific training through vehicles that are easy to use and resonate with each audience. Stakeholder analysis answers key questions about your learning community, such as:

• Who is affected, and what is the level of training they require?
• What is the population (i.e., number of people to train)?
• Where are they located?

Determine whether a culture of e-learning exists and which audiences are candidates for computer-based training (e.g., managers, business users, and occasional users) and which audiences require instructor-led training (e.g., process practitioners and daily users). If audiences are geographically dispersed, virtual training may be an option.

*    *    *    *    * 

Getting to the other side of an IT apocalypse requires comprehensive planning and the recognition that the most significant risk to change is the very people your program depends on to change. Even programs with great processes and world-class technologies can fail, and that failure often has little to do with either the processes or the technology. Preparing for change is not as difficult as reacting to change after it has occurred. You learn from life experiences. The second we stop learning, we die—or worse, we become zombies!

Jennifer Martin is a service management consultant at Maryville Technologies. With more than fifteen years of experience in enterprise service management implementation and IT process optimization, Jennifer has helped many customers successfully design, deploy, and manage ITSM solutions. She received her MBA in executive leadership from Wesley College, and she’s a certified ITIL v3 Expert.

Heather McSherry is an ITIL v3 Expert with more than fifteen years of experience in software application development, enterprise service management implementation, and IT process optimization. Over the course of her career, she has experienced nearly every role in ITSM solution deployment, including process architect, technical architect, developer, tester, trainer, project manager, organizational change advocate, user, and cleaning lady (as the need presented itself).