• 11/15/2013
    8:00 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Unified Communications Is Much More Than IT

A successful unified communications project needs a modern approach, one in which user needs are evaluated and UC metrics are defined before technology is considered.

Most technologists agree that unified communications (UC) is about unifying real-time and non-real-time communication services with the goal of providing users with a consistent experience -- regardless of the device or medium. Yet when IT leaders start considering a UC strategy, many head straight for the technology, with a view toward speeds and feeds. As a consulting practice leader that puts the needs of people (rather than technology) first, when I hear this, I get nervous. 

If the role of IT is really changing to meet with the times and evolving needs of users, why is the approach to new technology still following the "same old" every time?  

Why unified communications?
I was recently at a client meeting to discuss a new UC project. Like many other organizations, the client was approaching its needs strictly from a technological perspective. 

After listening quietly to their lengthy list of technology requirements and infrastructure limitations, I asked the group, "Imagine we're sitting here one year from now, and you've deployed your UC solution. How would you measure the success?" You could hear a pin drop! 

In addition to the sound of silence, I was met with blank stares. My question forced them to pause and reflect. One of the attendees raised his hand and said that to him, success meant having the project roll out on time and on budget. This was another very traditional IT response -- and a tradition I believe we must modernize.  

In my experience, most IT leaders focus much more on the "hows" and "whats" of technology, versus the "why." They evaluate which technology is right for voice, and which technology works best for instant messaging. They don't start by asking what users actually want or need -- for example, their motivations for using the technology and what's driving their desire to collaborate more as a team. 

Without fundamentally understanding the why of UC before moving on to the how, IT creates organizational waste in the form of time, energy, and money.

IT enables the business
As their roles continue to evolve, IT leaders must accept they're fast becoming enablers of technology in the enterprise, not just implementers of the technology. In the case of UC, this means IT needs to regularly reach out to business users and understand why UC is necessary to meet their goals and objectives. What does success look like to them? 

I believe this is one of the greatest skill gaps in IT today: the ability to broker a conversation with the business that is truly focused on its needs from a business user perspective.  

Define UC metrics
Defining the measures of success for a UC project does not come easy. There is a tendency to call out softer, more subjective measures, such as "improved collaboration" and "better customer satisfaction." But unless you are measuring these metrics today in a very specific way, it's unlikely you'll be able to properly quantify success in these areas in the future.

My advice is to come up with a short list of highly objective measures that all stakeholders (primarily your business users) understand. Measure your results and report on how you're performing today, before the project starts. Then once your UC project goes live, report back on those same metrics. This way everyone -- users, business leaders, and IT -- will feel confident in the impact your new UC solution is having. 


Links to social collaboration?

Interesting that your working definition includes non-realtime communications -- I usually think of unified communications as being the unification of different realtime modes, like voice, video, and chat/IM. I guess email is the exception, since things like voicemail/email integration have been part of unified communications solutions for some time.

As the author of a Social Collaboration for Dummies book, I've been interested in the fact that it isn't usually part of the "unified" comms scheme. Cisco's social collaboration platform would be the most prominent exception, bridging the asynchronous discussions and profiles with the option to open up realtime communications like a phone or video call. But for whatever reason, that concept has not caught on to any great extent.

Re: Links to social collaboration?

Social tools are typically web-based, correct? So that my be why sometimes they don't get factored into the infrastructure planning UC integrators may focus on. They may figure if you can get your videoconferecing to work, the web-based stuff will be fine. But linking it together just makes sense, and I think we will see more of that going forward. Right now companies are a bit unsure of social platforms, in my experience. And a lot of them have built huge intranets they are kind of stuck with.

Measures of Success

This is the crux of the issue, in my opinion, and definitely the most challenging.  What is a good metric for UC? And how do you develop something that tracks to some relevent goal. For example, how do you define succesful video conferences. From a purely technical perspetive that would mean everything worked. But in terms of actual productivity. the outcomes might be more broadly defined and related to a specific work product.

Very interested to hear some examples of the metrics others use to define UC success!

Re: Measures of Success

Great article. Unified communication is a main part of IT since it allows an individual to send a message on one medium, and receive the same communication on another medium. Instant messaging is one of the main component.

Re: Measures of Success

"In my experience, most IT leaders focus much more on the "hows" and "whats" of technology, versus the "why." Very true. I would like to share my personnel experience here, where we were working hard towards launching mobile banking concept, where we only considered "how" and "what" instead of "why "  and ended up in "Do we really need this?" after finishing the implementation.

Re: Measures of Success

I think your experience is probably very typical, Shamika. And the after-the-fact "Do we really need this?" question is something that should definitely be part of the front-end discussion. Curious, though. What was the concept that you initially thought was essential, but later decided otherwise. Was it because the concept was flawed, or the implementation was too difficult?