Why Organizational Change Management is Essential to Successful Technology Platform Migration

Table of Contents

Why Organizational Change Management Is Essential for Your Successful Migration to a New Platform

The Big Migration

Let’s begin with ITIL 4

How the Four Dimensions of Service Management Can Support OCM

How The Guiding Principles Can Support OCM

ITIL and OCM

Key Inputs for a ServiceNow Migration

ITIL’s OCM Lifecycle Management

Key Outputs

New organizational structure

New behavior in a system

New roles

New capabilities

Role descriptions

Guidance Materials

Change review reports

Lessons Learned

OCM Practice Success Factors

Conclusion

Technology platform migration is so much more than identifying your platform of choice, procuring licenses, and embarking on an implementation project; it’s about orchestrating a harmonious symphony of change across the entire enterprise.

While there is certainly no shortage of factors that come into play here with respect to technology and licenses, the truly successful migrations – those that transform organizations – are the ones that bring our people along for the ride. The call for Organizational Change Management (OCM) in these moments is resoundingly clear, as whether you’re consolidating the enterprise onto a single existing platform or bringing on net new solution, one thing is guaranteed: someone is going to have to migrate – someone’s job is going to change.

In this article, we’re exploring the people side of change as it relates to these sometimes-fraught migration efforts. Specifically, how to inform, educate, and otherwise prepare each individual impacted by the migration for the journey ahead.

The Big Migration

As we walk through OCM best practices for platform migrations, I’ll be referring to an example we at Beyond20 know intimately as a ServiceNow partner: migrating from legacy tool(s) to the ServiceNow Platform.

Just like any other major implementation project, migrating to ServiceNow is an undertaking not to be considered lightly. It’s a cultural shift just as much as it is technological, and it is possible for an implementation to go poorly with insufficient or uncomprehensive planning. A poor implementation can lead to technical debt, rework, and most importantly for our purposes here: failure of adoption. Plainly put, a successful ServiceNow implementation considers factors beyond the tech, incorporating the people and organization writ large to ensure impacted teams are just as excited about the change as leadership.

A Typical Scenario

A major enterprise is struggling to consolidate services and coordinate cross-functional teams that support them. Teams are working without any type of coordination, as completely independent entities. It is time to rethink these offerings, coordinate the effort that goes into them, streamline the provider groups to make them more efficient and effective. Imagine your organization has HR Services provided by an Enterprise Resource Planning () Platform, IT services and basic practices being supported ineffectively by a middle-of-the-road ticketing tool, and facilities services being supported by something like Maximo. Wouldn’t it be nice to rationalize these platforms into ServiceNow? At this point, platform consolidation becomes the goal, and collaboration is the way to get there.

When asked about the challenges, everyone is in favor of consolidating to a single platform, controlling costs, and improving the services until they realize how much change they themselves will need to endure to get there. (Change is really easy when everyone else has to do the changing but you get to stay the same.) Suddenly, everyone’s distinct tool and platform choices become sacrosanct, and they believe there is no way they will be able to do their jobs without their chosen array of tools. The other teams will have to make the sacrifices so my team can keep on keeping on. Now what little cooperation we may have fostered begins to flake away because of the realization that there will be winners and losers in this contest. Even if ServiceNow was already an incumbent tool in your inventory, its “owners” are getting resentful over the fact that they will soon be losing control of this implementation. They will lose the full decision-making power over the platform that they currently enjoy and have to share it with everyone else. The other teams now face not only losing the tools and platforms they have depended on but the freedom to decide how to use these tools. After all, everything was up to them.

And this is just the tip of the iceberg. There is an awful lot going on here, and only a small percentage of it is technical. Next, let’s discuss some of the tools that ITIL 4 natively brings to the table and then how a formal OCM process can help to solidify this substantial change in your organization.

Organizational Change Management with ITIL 4

Do not worry, I am going to dive pretty deeply into OCM. But before that, we are going to talk about some common-sense guidance that ITIL 4 is dying to share with us. Since I found ITIL back in its early days of Version 2, it has been on a steady path of evolution from a datacenter-obsessed, best-practices collection of processes and procedures to today’s ITIL 4 with its macro view of how we co-create value with our stakeholders through the provisioning of services. ITIL 4 is at its best when it helps us recognize, understand, and support our stakeholders – especially our users and customers. The insight we can gain from these tools provides fuel for our OCM efforts.

How the Four Dimensions of Service Management Can Support OCM

I like to use the Four Dimensions of Service Management the way pilots use their pre-flight checklist. Before takeoff, pilots have a ritual they follow, checking the aircraft:

• Externally for the status of
  • the engine(s), landing gear, and tires
  • the wings, empennage, and fuselage
• Internally for the status of
  • Instruments
  • Fuel
  • Radio and communications gear
  • Electronics
  • Interior
  • Weather conditions
  • And so on…

While the checklists differ based on aircraft type, the methodology is the same. Even though they have memorized these checklists, they still follow them manually, either on paper or electronically because they do not want to miss a single step. The Four Dimensions are the same for us – even though each project is different (for us it is a ServiceNow migration) the methodology will be consistent. While our work probably does not have the life-and-death connotations of air travel, it is still critical that we get our steps right, as well.

The Four Dimensions of Service Management are the four big buckets that we need to be concerned about to be an effective service provider. If I am going to create a new product or service, alter or change and existing one, or retire an obsolete one, I want to consult the Four Dimensions to be certain that I am not overlooking anything. Again, the information this activity uncovers is priceless for your OCM planning and execution. Think of it as the pan a prospector uses to search for gold.

Fig. 1 – Four Dimensions of Service Management

Here’s how I would use the Four Dimensions to manage the transition in our running example scenario of migrating to ServiceNow: First and foremost comes the Organizations & People dimension. I am convinced the ITIL 4 writers put this one first because this is the one that most of us in IT would cross the street to avoid. Consequently, this is the one that provides some of the greatest opportunities for project failure. This is also why I decided to make OCM my other specialty; I have just seen too many perfectly fine solutions crash into the rocks because we did not take the organization and the people into account. More on that in a bit.

They kind of Organizations & People information am I interested would be:

• Roles & Responsibilities: what is the break down of jobs, titles, and skills?
• The Org Chart: how are these roles organized?
• Communication styles: who do we communicate as a organization? Are we open

I want to collect this kind of information from all teams involved. This is how we will begin to understand their requirements for the current toolset and identify advantages to moving to ServiceNow, but I do not want to get too far ahead of myself with the OCM content.

As you have already guessed, there is quite some overlap with the other Dimensions in this line of research. When we ask them about the tools and technologies they are using, this is a direct reference to the Information & Technology dimension. As we query them on process, procedure, and value streams, that comes under the heading of Value Streams & Processes. And finally, if they are using any outside vendors or partnering with any other entities, we will capture these relationships under the category of Partners & Suppliers. This insight will inform planning and execution for both Project Management and OCM. Again, the goal of the Four Dimensions of Service Management is to give us the framework to capture this 360° view of what goes into our project, namely the ServiceNow migration.

As you can see, this approach will help us to identity:

• Stakeholders involved.
• What technologies do they currently use?
• How they use their current technology.
• Are they satisfied?
• What is the state of their processes, procedures, and value streams?
• Are they any outside stakeholders or participants that we must involve?

Here is what, in particular, we want to find out: who uses what and how. We will survey and interview the various teams that will be impacted, even tangentially, by this migration to ServiceNow. One of the key reasons to practice OCM is to have ready answers and responses to resistance to the change. If we can identify and understand what might make our stakeholders uncomfortable or even unwilling to make this change, then we can respond with the larger benefits and advantages. To just decide that this migration is a done deal and that our stakeholders only have two items on the menu to choose from, take or leave it, is inviting a conflict that does not need to happen.

I never cease to be surprised by the fact that, many times, those resistors/holdouts simply desire to be heard. So long as they know their concerns have been listened to and taken seriously, they will reluctantly but willingly fall in line with the larger project. On the other side of this scenario, I have seen various stakeholders engage in passive resistance (slow walking, learned helplessness, continuing to use the old systems) so effective that management simply abandons the project. It dies the death of a thousand paper cuts.

One of your most important sources of both insight and leverage will be your line/people managers. Use them to both take the temperature of the teams and to convince them of the eventual benefits of the change. But beware, if you cannot convince the people managers of the benefits, their negative attitudes will poison the well for their teams. Their enthusiasm and collaboration are critical.

Clearly, you will want to meet with your internal stakeholders, but you may also need to involve external customers as well. Please note that the questions I begin with here are not segregated by the individual dimension; I blend all four dimensions together to form a coherent flow of questions. In this scenario I might pose them questions beginning with:

• Please describe your part of the Value Stream in detail.
• Some of these we should already know:
  • What tool(s) are you currently using?
  • How do you use the tool(s)?

• Is this the sole tool for this purpose or do you have others?
• Do you have any dependencies of other teams for your process or tool(s)?
• Are any other teams dependent on you for their process or tool(s)?
• Are you working with any third-party vendors or suppliers?
• What is the reason you chose this tool? Did you have other choices?
  • Does this current tool lack functionality that you would want to have?

How The Guiding Principles Can Support OCM

The ITIL Guiding Principles were introduced late in ITIL v3, then refined in ITIL 4. They are, in short, a set of recommendations that help keep organizations from losing track of who they are and what they do in the face of constant change. They serve as a compass to help an organization to find its way. ITIL 4 presents these seven Guiding Principles:

• Focus on value
• Start where you are
• Progress iteratively with feedback
• Collaborate and promote visibility
• Think and work holistically
• Keep it simple and practical
• Optimize and automate

While we should always consider them as a set of seven, a handful of these principles will always stand out as more important than the rest based on the details of the particular situation. Here are those that rise to the top for me from an OCM + platform migration perspective:

These four Guiding Principles will help us keep our focus on the project at hand, the ServiceNow migration, and not get distracted. Again, we want to simplify the processes such that multiple teams work together and share the same focus. This mindset will help guide both project management and OCM throughout the migration process.

ITIL and OCM

Everything we have been talking about so far leads up this all-too-critical and all-too-underutilized resource – OCM. For an activity as intricate as a ServiceNow migration to be successful, we need OCM engagement from the very beginning, not as an afterthought bolted on later in the process. This is because OCM is there to identify potential sources of resistance to a project as early as possible, ameliorate the conditions causing this resistance with information, training, and education or sometimes even to bring the underlying causes of the resistance back to the project team for them to reconsider their solutions. I tend to overuse this phrase because it is so prescient: while project management prepares the solution for the organization, OCM prepares the organization for the solution.

Key OCM Inputs for Platform Migration

We require some key inputs to form and execute our OCM plan. The guidance laid out in the Four Dimensions of Service Management and the use of the Guiding Principles will contribute greatly here as the organization gathers requirements and applies business and IT strategy principles to the migration. At the beginning, these inputs might look something like:

• The ServiceNow migration change proposal and subsequent requests for change (RFCs)
• Our enterprise’s vision and strategy
• Financial guidelines and any constraints
• Risk management information
• Any policy and regulatory requirements

To create an effective OCM plan for the migration, we must understand the need and scope of the change. To do this, we’ll start by identifying key stakeholders, stakeholder groups, project sponsors, change advocates and even super users. Next, we’ll create the change team that will lead the OCM efforts (Note: I find the ADKAR methodology to be indispensable for this component). The change team creates the change vision for the migration and builds out the Change Plan, which is developed in coordination with the larger migration project plan. In order to create and maintain momentum and to sustain morale, we should include strategically placed quick wins.

As part of the Change Plan, we will construct a Communications Plan. Communications Plans come in a variety of formats, from a lightweight framework documenting the basic outline of what messages to communicate to which stakeholder groups all the way to a detailed moment-by-moment schedule of all messaging by type, channel, and audience. The goal is to find that just-right amount of planning to meet the needs of the task. These are decisions to be made based on your own organizational requirements –  as with most everything in OCM, there is not a one-size-fits-all solution.

With your various plans created and ready for use, now it is time to implement, to lead the change. Here the old adage, “No plan survives first contact” rings especially true. Be ready to adjust and adapt your plans based on the on-the-ground realities. This means that your Change Team must be keenly aware of unexpected outcomes and ready to make in-flight course corrections and manage a great deal of two-way communications. Sometimes expected resistance never congeals or on the other hand, resistance pops up from unanticipated sources. Sometimes the issues causing delay are technical or due to market conditions – in other words it comes from sources well out of the Change Team’s control. Being nimble and flexible are key requirements for a good Change Team. The ultimate goal is to establish this migration as a completed fact. This is anchoring the new state of the system. Once anchored, we will sustain the new system, ServiceNow, as the new normal.

The below diagram depicts the activities discussed here, with the ADKAR guidance seeded within.

Fig 2 – ITIL Workflow for Organizational Change Lifecycle Management

Key OCM Outputs for Platform Migration

At the end of the day, the reason OCM exists is to to enter into operations. Once we have the anchor in place, we must sustain the system as the new normal. For this new normal to solidify, we must bring in a number of new conditions, our key outputs.

New organizational structure

Dropping in a new technology solution without OCM support is a recipe for failure. Such a change will have ramifications across the organization, even in those units that will never directly touch a ServiceNow menu.

As project management and OCM go about identifying the organizational structures of the stakeholders and stakeholder groups as they currently exist, these will become the raw materials for the new ServiceNow-enabled organizational structure for the future. Who are these groups? What how do they work now? How will ServiceNow impact them in the future?

The reasons for the migration may go beyond the need for streamlined costs, this may pertain to the enterprise’s offerings of products and services. In other words, this project has the potential to initiate major changes with the organization. Again, we will rely heavily on Prosci’s ADKAR methodology to bring our workers and individual contributors along for the ride.

Fig. 3 – ADKAR Methodology

One of the key constituents that we must have on our side is the group of people/line managers who oversee the workforce. If they do not see this value in the migration, their lack of enthusiasm will transfer directly to the people they supervise; the people who do the work.

New behavior in a system

Few things can be as unsettling for workers than basic changes in the way they do their jobs. The very goal of OCM in our example here is to prepare our people for ServiceNow and how to use it. Without a doubt, it will be different from the tool(s) they have been using, and not just at the menu and keystroke level. Odds are against this being a simple tool substitution project – this migration will most likely require teams to approach their tasks differently. Without the proper Awareness of why we as an organization must make these changes and how this will empower them, there will be little or no Desire to participate. When understood in the larger context, the reasons for changes in behavior will become clear, allowing our teams to Think and Work Holistically as expressed in the Guiding Principles.

New roles

With a substantial change, such as our migration, while many roles may remain mostly intact, some old roles may be retired and entirely new roles created. Unifying our creation, delivery, and support of products and services through ServiceNow could present us with the opportunity to address multiple inefficiencies and redundancies. OCM will work with the project team to identify the new, changed, and retired roles as well as those that remain mostly untouched. This will direct a great deal of activity around the:

• OCM Change Plan
• Communications Plan
• Training Plan

Identifying the changes to the roles and responsibilities leads us to our next key output.

New capabilities

To go back to the ADKAR model, this is where we must concentrate on the Knowledge and Ability elements. The Training and the Communications plans will feature heavily in this output. After we have defined the new roles, we must construct our training regime to bring them up to speed at the right time: not too early and not too late. Below are two common challenges you may encounter here (I mention both of the ADKAR elements below because at some point we have all had to learn to be productive while missing one or the other):

Enough Knowledge but insufficient Ability: This indicates the presence of a formal training program, what we might call book learning without the street smarts (the actual Ability to put that training to use). We do not want to set people down at a ServiceNow console without the understanding of how to take the training theory and put it into practice for their daily tasks.

• To take something of a digression: In many cases, people want ServiceNow to bake in best practice without adjusting processes or training. And, to some extent, it does this. But no platform can take the place of training or process improvement. Hoping that a new tool will solve all of our process issues is setting yourself up for disappointment.

Insufficient Knowledge but learned Ability: This is the opposite condition. This is the condition of learning how to swim because someone threw you in the lake. Our training was inadequate but still we learned how to use ServiceNow through some mentoring, shadowing, and sheer determination. While yes, we may be effective using the tool, we may be grossly inefficient.

Neither of these conditions does anything to improve morale around the larger migration and either/both can create needless pools of resistance where none should have existed. As part of the process of defining these new capabilities for the needed roles, we will focus on identifying those new skills that will be crucial to the success of both the larger migration project and the individual team members.

Role descriptions

We have successfully pinpointed the roles central to the migration, along with their requisite capabilities. To culminate this effort and round out this phase of the Change Plan, we’ll now provide comprehensive formal descriptions for these roles. These descriptions should outline the roles’ specific responsibilities. As mentioned above, certain existing roles will remain largely unaffected by the migration, some roles will be newly formed as a result. Simultaneously, some roles will become obsolete and phased out of the program. This is where the newly crafted role descriptions play a key role in solidifying the Reinforcement component of the ADKAR model. By formalizing these roles, we usher in the era of the “new normal.”

Guidance materials

These materials will consist of our various plans (Change, Training, and Communications) plus any other documentation we will create, either in advance or on the fly, for the migration project. For smaller, less complex projects, this could be a rather light-weight collection. For substantial projects, like our ServiceNow migration, this could be large and growing list of guidance documents.

Change review reports

Just like a good project manager maintains records during the course of a project, so too should the OCM Change Team. The team will generate regular and ad hoc reports for our sponsors and key stakeholders based on our plans and any other required management reporting obligations. These will include status and risk reports, project/OCM change requests and other similar documentation.

Lessons Learned

Again like project management, OCM good practice requires a formal Lessons Learned session as part of closeout activities. This can be done in conjunction with project management or as a standalone readout. The motivation behind this is to create an ongoing OCM team of Change Managers that will continually improve as they move forward with more projects.

OCM Practice Success Factors

Practice Success Factors (PSFs) will help you get your metrics and management reporting underway. ITIL defines a PSF as “a complex function of a practice that is required for the practice to fulfil its purpose” and breaks down each one while describing the rationale. PSFs are more than tasks or activities; they include components from all four dimensions of service management. The nature of the activities and resources of PSFs within various practices may differ, but together they ensure that the practice is effective.

OCM has three PSFs for us to use to measure our success. Not only will these give us the scoresheet to calculate our success and the initial input for our Lessons Learned discussions, but tracking these metrics will help us to make critical corrections throughout the process.

Change is a very frightening subject. With insufficient change, our enterprise will soon wither and die. But inadequate change management will break the enterprise just as surely. Installing a new platform never leads to success on its own; we need to bring along the entire organization and its people. OCM is the is the compass you will need to help you find your way to success.