This Goes to 11: 4 More Skype for Business Deployment Gotchas to Avoid

Standing on the Shoulders Of A UC Editor and Calling Myself Tall

Today, I was reading Beth Shultz’s recent No Jitter article, 7 Skype for Business Deployment Gotchas to Avoid. I believe that Beth and the panelists she cited were spot on with their assessment of some key areas overlooked in UC deployments. Here is my synopsis of the 7 Gotchas.

1. Maintenance Minder – You cannot just remove an end-of-life PBX and insert a UC deployment and expect it to work. You have to plan for the additional impact of voice, video, and collaboration on your infrastructure.
2. Operational Outlook – You have to plan beyond deployment. If you want to realize the full return on your UC investment, you must invest in driving users to adopt and analytics that effectively measure adoption and identify gaps.
3. Network Readiness – With UC comes voice, video, and collaboration over your IP network. Is your network ready? It is important to do an assessment to validate its readiness.
4. Border Basics – Resist the temptation to trust your SIP trunks without a Session Border Controller (SBC). SBCs prevent attacks at the edge, handle encryption for mobile users, facilitate a migration from legacy trunks and PBX’s, and support dial-plan management.
5. Staffing for Success –  It takes resources to maintain and operate a UC environment. And, typically, these resources are different than the siloed voice and network resources supporting a traditional deployment. Make sure you structure your organization and build the expertise of your resources to maximize their effectiveness.
6. Pilot Prowess –  An effective pilot includes a representative cross section of the future user base, not just key executives and IT.
7. Know Your Users –  A move to UC can represent a significant change in user interface. If users are not properly accounted for and properly prepared, the overall experience will suffer. Complaints that are actually caused by user error or user frustration are often blamed on the platform. Do not overlook the users and unnecessarily submarine your UC initiative.

That’s All Fine and Good, Now What?

So, I’ve read Beth’s article and fairly effectively paraphrased it. Please read the article yourself to verify my interpretation and summary. So, what do I do now? As I see it, I have a couple of options:

  1. I could stop there, submit my summary of someone else’s quality work and call it a day.
    1. That seems lazy and irresponsible.
  2. I could be provocative and generate a contrasting blog that counterpunches each of the 7 gotchas
    1. That seems like I am unnecessarily picking a fight.
    2. Plus, I fundamentally agree with the gotchas
  3. I could speak to how I agree with each gotcha and how Nectar’s solutions address each of them. (I do; and they do)
    1. That seems self-serving and most potential channels for this blog don’t appreciate product proselytization.
  4. I could acknowledge the 7 gotchas, but point out I believe there a few more.
    1. That seems like a great way to springboard of Beth’s content into my own thoughts.
    2. But how many more?
      1. Another 7 seems like too much; makes for a long blog and I would honestly be stretching toward the end
      2. Another 3 would bring the total to 10. 10 is a good round number and pays homage to David Letterman
      3. In the end, I could not pass up the opportunity to . . .

 Quote “This Is Spinal Tap”, in My Blog

This list goes to 11.
Although I agree with the 7 gotchas, they seem to focus on planning for the deployment and accounting for the people involved. These are very key factors, but a perfectly planned deployment will quickly go off the rails if you do not plan to operationalize it day 2 of deployment and beyond. So, here are 4 more gotchas to consider:

 8. You Maintained Your PBX, Plan to Operate Your UC Deployment–  So many enterprises seem to believe they can simply deploy Lync/Skype for Business and it will run smoothly, unmanaged for the foreseeable future. I think an expectation has been set that UC will eliminate the maintenance costs you needed for your legacy voice infrastructure. This expectation is a bit oversimplified. Some components like moves, adds, and changes can definitely be eliminated or reduced. At the same time, UC is a much more complex environment, especially than traditional TDM systems.  Invest in the tooling and the partners (or internal resources) to monitor, diagnose, and report on your UC deployment. This will ensure more up time, a better user experience, and a more positive reflection on UC your initiative.

 9. You Assessed your Network, Now Proactively Monitor It –  I cannot overstate the importance of a pre-deployment network assessment. UC traffic is different than even VoIP traffic. Make sure your network infrastructure can handle the new load of UC voice, video, and collaboration. Also, make sure your network properly flags UC traffic so those packets get the priority they deserve throughout the entire conversation path.  But don’t stop there. Your network is by no means static. There are constant updates, upgrades, and changes. In order to protect against the unintended impact of network configuration drift on your UC deployment, maintain a constant stream of single synthetic sessions that ensure network connectivity, path integrity, and QoS integrity.

10. Beyond Border Basics –  I agree that an SBC can be a critical component of your UC deployment. It helps protect your edge. It helps make the migration from a legacy environment much smoother and more predictable. It also marks a key border: between your enterprise and your SIP provider.  You need to defend that border. In my experience, one of the biggest points of contention in a UC deployment is the interface point between the enterprise environment and the outside world (SIP-provider, cloud provider, etc.). In order to defend your border and properly hold your SIP trunking or cloud provider accountable, you should bracket that SBC with software that can analyze the traffic coming from your internal environment and compare it to traffic from the external provider. If there is an issue with call quality, you can quickly discern which network (internal or external) needs to be looked at. Further, this software can provide signaling information that you could provide to your carrier to help them troubleshoot, which will reduce downtime and frustration as well.

 11. Pilot the Portfolio– I agree that a pilot group of users should include a representative cross section of your broader user base. I would take that one step further and contend that your pilot should include a representative cross section of management and operational tools. Is monitoring less important for 10% of your population than 100%? What if you could uncover some small anomalies you can address before they become widespread? What if you could properly isolate UC-product related issues in your pilot from network or infrastructure issues that are platform independent? What if reporting could accurately capture pilot usage and give you a sense of early patterns?
Proper tools can help your pilot be an accurate representation of what life would look like as a system wide deployment.

It is critically important to plan for your deployment and for the needs of all people involved. Just don’t forget to also think about Day 2 and the future of that same deployment and those people involved.