What makes for a “Successful” UC deployment?

By Irwin Lazar
On Dec 13, 2013
Friday, December 13, 2013

As I finished writing our latest benchmark report on UC success earlier this week, my review of the data and the interviewee comments made one point crystal clear: UC success isn’t necessarily viewed from a technology perspective.

First, a bit of background: Each year, in support of our annual enterprise technology benchmark, we interview IT leaders representing around 200 companies, asking them a variety of questions to help us carry out our mission of quantifying the impact of emerging technologies. At the end of each technology portion of the interview we ask “how do you measure the success (of that particular technology)?,” “by that measure, how do you rate the success (on a 1-10 scale with 10 being the most successful)?,” and “what would you do to improve that rating?”

When I reviewed the results for UC-related areas, I found two interesting trends: First, the majority of participants rated their UC initiatives as either unsuccessful or somewhat successful; and second, that their reasons often had less to do with technology than with business case and user adoption. Building a business case for UC has always been somewhat difficult because the most often cited measure of business benefit is “improved productivity.” We’ve developed our own methodology at Nemertes called “Just in Time, Fetch the Expert” that attempts to quantify the business value of faster access to information (be it people or documentation). This model works well when you can apply it to business process improvement (e.g. more closed sales because field representatives have faster access to subject matter experts). However, if the end result is that the identified business benefit is "improved productivity" then it fails because there’s no guarantee that the time eliminated hunting for resources is put to good use. For instance, I've seen examples of calculators that measure the value of web conferencing investment by the time saved taking attendance and trying to track down who fell off of a call. In this example the value calculation was "time saved x average salary = ROI." But that approach assumes the time saved provides business value. What if time saved = more time to shop on-line or play angry birds?

And therein lies the crux of the problem: Deployment success doesn’t come from meeting project plan timeline goals, delivering a working solution that meets up-time goals, enabling integration of disparate systems, or coming in at or under budget (though all of those metrics are important), it comes from delivering business process improvement with tangible, quantifiable results

IT folks tell us they often struggle with marketing the benefits of the solution that they are delivering. All too often I saw in our interview notes comments along the lines of “we deployed xxx, but nobody is using it, and I’m not even sure if people know it exists.” Thus, it’s not enough to simply deploy the latest and greatest collaboration technology – success, true measurable success, comes from identifying the tangible impact that investment has on business processes, in conveying that potential benefit, and in providing training, end-user awareness, and in educating those with LoB P&L responsibilities on how investments in collaboration translate to bottom line improvements.

Note that Nemertes is now scheduling interviews for our 2014-15 benchmark. If you are able to participate in a one-hour confidential interview in exchange for access to the resulting benchmark reports, please contact us


You only need to be part of the UC sales process to understand why post deployment uptake is poor - and here I am excluding the possibilities that the technology if difficult to use, its functionality is meaningless or that using it slows down processes without adding commensurate benefits.

The key to adopting new technology - assuming it is relevant, easy to use etc. - is to get people using it enough that they learn how to use it and embed it in their daily processes.

And this needs to be acknowledged up front as an issue - moreover it costs money and works best when the technology is targeted to the people who will benefit from it.

Historically UC has been developed by people who are in love with technology and disconnected from "relevance and ease of use" - although this is rapidly changing - or should I say companies are now claiming that this is their focus - since the recent success of companies like ShoreTel who have been selling on this claim . Cisco and Avaya have now joined the "product simplification, ease of use and relevance to business process club". - lets see if they can actually transform words into something tangible.

Now back to a competitive sales process - if you are not selling Cisco to an IT department wedded to Cisco and don't have the $250m that Cisco is throwing at the mid-market to buy share - or you aren't Microsoft selling to the C-Suite who can easily see how Lync seamlessly fits into their existing work processes - what do you do?

My observation is that unless you are selling to someone who will be at the company for a while and therefore be around to harvest the consequence of the purchase - price often becomes a driver. And where is an easy place to cut cost without cutting the perceived offering - training and adoption services.

When you are selling a dream it isn't very smart to say - look at all this cool stuff we have that will transform your business, make you look like a superstar ... but it will all come to naught if you try and push it on everyone and don't have a good adoption strategy which by the way will cost this huge amount of money.

As an aside, Vidyo has a very nice 7 week adoption process to address this very issue. I wonder what sort of demand they are finding for this service? Microsoft has very good processes for identifying user needs and providing the relevant training - again I wonder what proportion of deployments end up utilizing these tools and processes?

One of the biggest mistakes I see UC companies make is to fall into the trap of dividing their businesses into separate profit centers in the belief that this is the best way to increase profitability. This is especially true when implementation and training are separated out - the last thing a company needs is to self sabotage itself.

Microsoft has been the latest victim of this as exampled by “retiring” the Microsoft Certified Master (MCM), Microsoft Certified Solutions Master (MCSM), and Microsoft Certified Architect (MCA) certifications. I am sure there are Business School case studies that have been written about using strategies such as Microsoft's Master certifications as a way to create a community that champions the product for free etc. If the response from the "UC Architects" podcast is reflective of the larger Microsoft Communities response, there will soon be Case Studies about how short term cost cutting, or turning a part of your business into a profit center, can destroy the "intangibles" that are the glue that holds the business together.

What kills it usually is having to go with a single vendor for really unified communicaitons -- and no vendor having the whole package for each company's diverse use cases.