Resistance is Futile

Or...How to encourage UC adoption

The cybernetic drones, called Borg, on the Star Trek television series were often heard to say "Resistance is futile" as they went about overwhelming and assimilating all other (legacy) species. If only converting legacy voice users to unified communications were that easy.

Recently there has been an interesting discussion on LinkedIn that was spawned from the question "Legacy users and resistance to change: How do we keep them from killing the deal?" The specific question was posed in the context of Microsoft Lync, as it was posted in the Microsoft Lync Partner Connect forum, however the query and suggestions are equally important and applicable to other UC platform deployments.

Below I consolidate some of the suggestions on overcoming resistance to change along with my critique of the suggestions. My comments are based on adoption metrics from several different UC platform deployments across multiple customers trying different approaches.

Suggestions on how to best "assimilate" the legacy users:

1. Implement a UC Pilot

Pilots are a very good idea in general. However with most general strategies, it is more often the specifics supporting the strategy that determine the likelihood success.

One contributor suggested performing pilots with "tech-savvy users." In my experience this is exactly not the group to involve in your UC pilot, unless you are undertaking a technical pilot to ensure the technology works. If you know (or there are sufficient case studies to prove that) the technology works, what you likely need to conduct is a user acceptance and adoption pilot: you are looking to prove that a large number of people in your organization will frequently and effectively use the new solution.

Measuring, monitoring and promoting usage (quantity of use) and adoption (breadth of people using) is critically important in a UC pilot. To develop a valid understanding of challenges ahead and to position for wide-spread adoption, you should specifically target non-technical business users for your UC pilot. Choose an office, a group or any other collection of people that represent the different "use cases" and "user scenarios" within your organization.

A few years back I led 10 or so pilots of a new UC platform. Most organizations moved forward with larger UC deployments as a result of the pilot. One pilot was for a large drugstore chain. At the end of the pilot this organization chose not to move forward. The key reason, during the pilot period, due to restrictions imposed by the organization, almost no pilot users actually tried the new UC platform. Feedback, as expected, was neutral. There were neither strongly positive nor strongly negative comments, which was not surprising because no one had used any of the new features.

Pilots are a good idea in general; however, to be successful you need to ensure that the pilot users are representative of your deployment group and that they actually use the new UC features. Taking away legacy tools (e.g. the "old" phone) during a UC pilot is a good idea, if possible. Otherwise your pilot risks simply becoming a demo.

2. Get the "Big Boss" to support

Never a bad idea! Some contributors specifically called out the "big boss" as the CFO, focusing primarily on the money issue (see item 3 below).

My experience is that C-level executives support projects that have been proven to benefit the organization. Benefit could be dollars, either through cost reduction or revenue improvement, but it could also be connected to risk reduction, talent retention, customer/employee satisfaction or other factors. Getting executive support most importantly requires understanding what "success look likes" for the "big boss."

The disconnect I frequently see is that the technical staff, often the most vocal proponents of the proposed UC solution, build their argument based on a vague and poorly defined statement of benefits. Even the "big boss" often has a "bigger boss" (or "The Board") to whom they need to justify (investment) decisions. Help your boss champion your suggestion to their boss by creating a clear and concise summary of why UC is a good idea. I would suggest you are not done until you have one slide/page that states your case followed by three to five pages/slides of backup detail. When preparing your summary assume you will only get to present the first page or slide - make it count.

3. Show them the money!

Several people suggested that the UC business case would make resistance futile. One even went on to note that "It's a rather simple exercise to do the calculations." The problem I have found with simple calculations is that they are most often "simplistic" and seen as such.

Every vendor seems to have a tool that shows you the TCO (total cost of ownership) with their product is less than what you are currently spending on your legacy platform and lower than any other solution you are considering. And while the numbers may "add up" if the assumptions are not accepted, and endorsed as correct, the business case becomes valueless.

Creating a valid business case for your organization is a strong step to push along UC deployments and help overcome resistance. However, understanding, documenting and gaining acceptance of the key assumptions that drive the numbers in the business case is never simple. Do create a business case for UC but make sure you set aside sufficient time to do so, so that it includes sufficient detail specific to your organization.

4. New feature X

Highlighting specific new features was recommended as a way to promote the adoption of UC. And I agree that UC features, such as the ability to make and receive calls from anywhere using a softphone, presence, the ability to simultaneous ring multiple phones, unified messaging and federation, can drive adoption. But you must choose the features to promote wisely and specifically based on your organization.

Concrete example time. Take unified messaging (UM), the ability for users to receive voice mails in their email inbox (including on mobile phones when not in the office). This is a great feature that means no more missed messages and no more "forever flashing" message waiting indicators. At some organizations UM can certainly help encourage legacy users to adopt UC. And yet this same feature, in organizations such as financial institutions with strong compliance requirements, which allows voice mails to be more easily forwarded (internally and potentially externally) and retained, actually creates more problems than it solves. It turns out that some UC features if enabled slow, or can even halt, the ability to move more users to a new UC platform.

With any UC solution, planning for and managing change and the resistance to change is key. Change management is both important and difficult. Whatever approach you adopt, there will be no "short cut" or "magic bullet" and a successful transition will require that you:

a. Define and document real need;

b. Find a solution that addresses the need at a cost less than the benefits provided;

c. Prove that users in your organization will use the proposed solution (thus crystalizing the potential benefits);

d. Document proven adoption and project benefits; and,

e. Use the above to create enthusiasm and garner support for your implementation.

Do the above and then and only then will resistance to UC be truly futile.

Live long and prosper.

Have some resistance to what I suggest? Believe my arguments are futile? Share your thoughts with me by commenting below or via Twitter @kkieller.