Avoiding the pitfalls of Unified Communications

You know that when you need to make a journey and you open a map, you first get hit with hundreds of names, symbols and squiggles and it takes a few seconds for your eyes to pick out what you want. You can see your destination, you know where you want to get to but that’s only half the information you need. Your journey is between two points, your current location and your destination. That old adage springs to mind “How do you know where you’re going, if you don’t know where you are?” So on that map, you look at your location, your destination and you plan your route.

Of course, today, most people just use their SatNav! Sadly, there is the problem, how many times have we seen 38 tonnes articulated lorries going up narrow country lanes where they can’t turn around and little bridges just can’t take the weight!

So what has this got to do with the process of moving to a fully functioning Unified Communications system, to the utopia of UC, to arriving at that glorious meadow and strolling bare-foot through the grass, with the sun on your face from the clear blue skies above?

The simple answer is: you need that map, you need to understand the SatNav and not follow it blindly or that utopia will turn out to be a scorched earth, with thunderous skies and voices forever wailing in despair.You would not believe the number of times I’ve sat in a meeting discussion the “UC options”, “where do we go?”, “how do we get there?”, “what will it cost?”, “what’s my ROI?” and I can create silence by asking, quite simply, “OK, can you tell me what PBX/voice infrastructure you have got right now?”. Please note old adage above!

Too many times, I’ve seen the concept of UC wrongly, seen as just a new phone on the desk. Too many times, I’ve seen UC treat as a single standalone project. Too many times, I’ve seen the voice team not talking to the data team and internal politics dictating all.

UC is more than all these, it is a fundamental change in the work ethic. In order for UC to work properly and, just as importantly, to be used properly, there are numerous underlying processes and systems that must be in place to support it. I was once, with a customer discussing about UC, only to find they had two separate AD forests with plans in place to merge them at a later date. The customer wanted to roll out UC with users logging in to phones in one AD and those same users (duplicated accounts) logging in to their PC’s in another forest and wondered why I looked shell-shocked. Finally, I persuaded them to look at the underlying AD, before pushing UC out over the top.

Another wanted to roll out Unified Messaging only four months before migrating their whole Exchange platform which would have forced a rebuild of the voice messaging server, luckily after a short meeting, common sense prevailed.

So what are the pitfalls of migrating to UC? The first and most commonly overlooked, is to treat your systems and services as a whole. UC is an encompassing service, that’s the whole point of it, so you need to address all the services that it requires and look at all currently running or planned projects.

Some of the other areas that should be looked in to:

Microsoft AD: you’ll probably need to extend your schema, do you have the ability to do this, and sometimes the Schema Master is in another continent controlled by another corporate team.

Exchange: if you’re using UC, you’ll need service accounts with access to mailboxes, what are the ramifications of this. All team members looking after the Exchange must know that there are other services now reliant upon it so the change process must be updated.

LAN: Simple thing, its Ethernet so no problems with bandwidth or QoS! Wrong, its is far more complex and QoS must be maintained end to end, resilience, convergence time (Spanning-Tree?) and that little thing – PoE (do the switches support it, for all ports, UPS now spread over buildings in switch cabinets);

WAN: QoS, bandwidth are always thought of, but often overlooked is CAC (call admission control) – should we allow those calls, how do we control it, what is the overflow method;

PBX: Trunk connectivity, IP, software upgrades can significantly increase project costs, signalling interoperability (lets not talk about Cisco and DPNSS!)

Dial-plan: please stop and think about this, then think some more, then bring in users who really need this, the PA’s, the secretaries, receptionists and operators. Changing a dial-plan half-way through a roll-out, because something was overlooked, can be a recipe for disaster.

Training and awareness: You spend a large amount on migrating to UC, but it’s wasted if your users don’t know how to use it and to make it work for them. One of the things I’ve also seen is the roll-out of a highly complex, fully functional, all whistles and bells UC project and when I then train the users, they don’t use it, they’ll never use it, because all they ever wanted was dial tone at the desk and no one stopped to ask them. The vast majority of staff never move from their desk and the only advantage they see is this “click to dial thingy” from their Outlook contacts. Sadly, that is an all too common occurrence, that the team running the project do not talk to the people who will ultimately use UC and it is they who, in the end, will determine the success or failure of the project.

If you’re thinking of progressing to a UC platform you need to first stop and think, why are we doing this, what will it give us, what will it cost us and remember the adage above … plan your journey, get a map, get a SatNav and never be afraid to stop and think or you’ll end up being that lorry driver up a country lane!

So now when you’re thinking about UC, can I be bold and ask you the simple question: “Can you read a map or do you rely on your SatNav?” Have you had similar experiences?