In part 1 of this series I looked at some "relationship rules" that can help make living with Lync more rewarding: Think beyond voice, consider you are calling a person, not a device, and select the right endpoint for your different user types.
In this second part, I explore three items that can cause "irreconcilable differences" between your organization and Lync.
Network Issues
Real-time communications relies on a solid network foundation. This means ensuring your network is up to the challenge--a common area where some organizations stumble.
Many organizations initially deploy Lync primarily for instant messaging and presence. However, when you choose to make use of Lync voice, video or voice conferencing services, you may need to upgrade your network.
All voice over IP systems (VoIP) require that your network treat voice packets as "special". This is typically referred to as QoS (quality of service) or CoS (class of service). The intent is to ensure that voice packets are forwarded reliably through the network so that voice quality does not degrade. Real-time communications, such as voice and video, are much more impacted by slight delays in packet delivery, as compared to other application services such as email and instant messaging.
Older switches and routers may not support QoS and as such, in order to deploy any VoIP solution, including Lync, you may need to upgrade your network hardware. In addition, you may need to ensure that your WAN network provider is also able to prioritize traffic between your branch offices; this might require paying more for "real-time traffic prioritization".
If you are choosing to deploy Lync desktop phones, it is most convenient if these devices receive power from the network connection; however, this requires that your network switches support power over Ethernet (PoE). Supporting PoE may require you to upgrade some or all of your existing network gear.
Underestimating the Complexity of Voice
Setting up a Lync environment to provide instant messaging and presence can be a straightforward, one day, one server project. This one server can provide IM and presence services to thousands of people within an organization and also provide (internal) peer-to-peer voice and video services without too much effort.
Ironically, it is the ease with which Lync can first be installed that sometimes causes IT groups to underestimate the complexity of deploying Lync as a full UC solution.
I previously explored this dual nature in the two articles "Is Lync Really that Complicated?" and "Is Lync Really that Simple?"
As noted above, just because voice services are easy to install, this does not guarantee that your network is properly connected or engineered to deliver reliable voice services under all circumstances (i.e., when congested with other data traffic).
Allowing users to receive calls from and place calls to the PSTN requires some connection to the PSTN, whether this be a SIP trunk, PRIs or 1FLs. This will require a conversation with a telco and some familiarity with telco jargon. If you are going to use a PRI or 1FL connection, you will require a gateway hardware device; depending on resiliency requirements you may choose to make your gateway an SBA (survivable branch appliance). If you use a SIP trunk you may choose, for security reasons, to implement an SBC (session border controller).
To provide conferencing services (audio, video, web), you will need to setup the MCU (multipoint control unit) roles within Lync. These server roles have more complicated scaling restrictions and as such require more planning compared to the basic IM and presence functions.
Next Page: The importance of training and communications
Underappreciating Training and Communications
Many times IT staff pilot Lync within the IT group before rolling it out to the rest of the organization. This is a good idea. (A pilot that includes typical end-users is an even better idea.)
Often by the time the IT staff is ready to rollout Lync to the organization, they have been using it themselves for many months. Both because IT staff is typically more familiar and comfortable with technology and also because they have been using it for a while, I have seen many IT-centric Lync projects underappreciate the importance and value of communications, change management and training. This is especially true when Lync is being deployed as a voice system replacement.
Of course, training is especially important for specialized roles, such as the person(s) operating the switchboard or administrative assistants who answer and place calls on behalf of others; however, it is also extremely valuable for "standard" users.
Your communication and training plan should at a minimum address three items:
1. Why--Why is the organization switching to Lync or adding Lync as a tool; what are the expected benefits.
2. What is in it for them--How will Lync make the individual's life better; typical "crowd pleasers" include: tag for status change alerts; voice mail and missed call notifications in the email inbox (although technically this is provided by Exchange UM); improved ability to work effectively from home or when traveling; and simultaneously ringing a mobile phone.
3. How--How will the transition be managed, how will specific functions operate in the "new mode of operations".
Living with Lync can be a rewarding experience. Avoiding common pitfalls will be discussed in depth by a customer panel during the Living with Lync session I am leading at Enterprise Connect. If you are attending Enterprise Connect please join in.
Each week between now and my March 19th session I intend to address a new topic related to living with Lync. Next week: "Living with Lync: Reception and Switchboard".
Do you have stories to share related to your experience living with Lync? Do you have any specific topics you think I should cover at the Living with Lync session? Please comment below or share your insight with me via twitter @kkieller.
Follow Kevin Kieller on Twitter and Google+!
@kkieller
Kevin Kieller on Google+
