Unified Communications - Why so hard?

Some general thoughts on deploying UC technologies.

====
Quite a while ago I wrote an article on why I like working in the Unified Communications field - you can see it here:

Why UC?

It was an interesting conversation at the time going through the reasons that the technology kept me interesed. There is also of course a flip side to this - why is deploying a Unified Communications platform so hard? Or rather, why do so many organisations deploy UC platforms and have trouble with the process.

It’s an interesting question, and one with many answers. In my working life I typically get involved with two types of organisations and deployments, with these being:

  • Organisations who want to deploy the technology, but are not quite sure how to approach as it’s not really in their internal skill set.
  • Organisations that give the technology to existing technology teams and ask them to get on with it.

(Obviously there’s many other scenarios, usually somewhere between the two mentioned above).

In effect, you’re either there at the start, or engaged later to pick up the pieces. From a technology perspective, you can understand why organisations take both of these approaches. Some are either a little more risk averse, or simply don’t have the internal time bandwidth for such projects - this tends to be the key feeder for the first scenario in my experience. The second scenario has a more varied set of drivers - the more common one is where an organisation does have a great internal team, and that team is keen to get involved in the newer technologies.

So why is deploying Unified Communications technologies so hard…? Ask that question from 20 people in the field and you’ll likely get at least 27 different answers. For me, I think the answers seem to be different depending on who is actually answering the questions. Technology type people see it as a learning curve - and an enjoyable one, for much the reasons I highlighted in my article
Why UC? The problem is with this approach is that while the needs of the technical teams are being met, the needs of the users are not. You’re deploying front-line tools often using people who are learning on the way.

Deploying UC stuff requires an understanding of the technology at a far deeper level than a lot of other user-facing platforms. Let me put it another way - when deploying stuff like Exchange the platform can be a bit more tolerant of configuration issues than a lot of UC platforms. This tolerance is not really a technical one, it’s more around the impact on the users. Get Exchange not quite right and you’ll have some annoyances and feedback from the users about those issues, but in general the platform will operate.

Get a UC platform wrong (I.e. Telephony etc.) and my, you’ll be in a world of hurt as those users make their frustrations known to you.

I think the ‘why so hard’ question is an interesting one, and it’s not one specifically answered by the technology itself. The real reason it’s so hard to deploy well is out there in some of reasons to deploy the technology in the first place: Enabling a user to change how they work.

That may take some explanation. You want to give your workforce modern and enabling tools to get their job done, get it done well, and to, well, enable them to be more successful. The way you do that is implement technologies that enable change the way they work. The problem with this is of course is that if you give them tools that ‘don’t quite work’ you’re not enabling them, you’re putting them at a disadvantage. The next thing you know you’ve got unhappy users that for whatever reason can’t get their screen sharing, or their conference calls (for example), working.

Some of the elements of UC platforms that make it great for working on, can also make it difficult to deploy, and to deploy well. Getting the tools out to the users in a way that’s functional, and works well every single time, is absolutely key to a great deployment. A deployment that your user estate will genuinely thank you for deploying. How often does that happen? Going back to the two scenarios I mentioned earlier:

  • Organisations who want to deploy the technology, but are not quite sure how to approach as it’s not really in their internal skill set.
  • Organisations that give the technology to existing technology teams and ask them to get on with it.

Using the above scenarios, typically I’ll see that one line of engagement results in a positive experience where the users are effectively bought on the journey of the new ways of working. The other one often involves climbing a mountain as the user’s perception of the platform is already tainted.

UC stuff can be challenging to deploy. Make it work across multiple devices, from anywhere, and in a consistent and repeatable manner requires attention to detail on how platforms are designed to operate. It requires experience - experience such as knowing which certificate providers can cause you issues with other organisations, experience on providing media quality over congested networks for example. Getting input from people that do this as their day job can only be a good thing in my opinion.

Having to work back through existing deployments that ‘don’t
quite work as expected’ is probably around a third of my day job. What’s interesting is it’s always similar problems you see on such sites - similar ones that could be avoided. What kind of things? Well, like misunderstanding how cores work on Lync/Skype is quite a common one. Firewall rules are another. As is not really understanding the roles of QoS and Admission Control.The most common? Probably certificate misconfigurations.

I’ll finish up by saying that user experience is absolutely at the centre of UC deployments. Lose the users early on, you’ll have an uphill battle on your hands. How do you ensure consistency of the user experience? My best advice would be to have resources at hand who have been there, and understand the underlying technology you’re working on, whether that be Cisco/Microsoft etc.

Get it right, and your users will love you for it.


blog comments powered by Disqus