In this post to the UC Podcast, Skip Chilcott discusses the importance of the planning phase in Unified Communications projects. Like any good building, if the foundations aren't solid, then things are likely to fall over. However, in many cases, organizations are rushed to implement projects and the lack of up-front planning can come back to bite down the track.
Subscribe to our Podcast on SoundCloud and iTunes.
Transcript
Scott: When it comes to communication transformation, planning is everything. Skip Chilcott with IR joins us here to explain why.
Skip: So planning is the probably the biggest single most important aspect of a unified communications deployment or conversion from a legacy system or, you know, whatever you're going to do. Planning is so important because it's—the needs of the solution in the new world of all IP based communications, the needs start to push demands in the infrastructure of an organization in a new way and planning is critical for all the way from how the end users are going to interact with the system all the way though the infrastructure that says 'do we have the bandwidth and infrastructure to support what we want to do here?' You know, that's the biggest critical thing. If you think you can just go and take a new unified communications solution and make it work on the same infrastructure you've been using for the last five to ten years, that's probably a fairly shortsighted conclusion. So planning is critical to understand—to avoid the costs and pain down the road. We see it time and time again. Customers go, they start deploying a UC solution. It works well for the first 500 users in their pilot and then as they grow to 1,000, 2,000, 5,000, things start to fall apart. It's not working anymore. Something's causing a problem and so what they typically find is that they didn't spend enough time in planning and they missed a whole bunch of aspects of the effect that it's going to have and so, spending more time upfront planning and less time dealing with this situation down the road, is really what customers need to think about.
Scott: In your experience, is it a lack of planning or is it sometimes people just don't plan deep enough? They have a cursory, they put together a just sort of a generic plan but they don't test it to all the potential conclusions?
Skip: Depth of planning is probably a better way to say it. I think you're right. I think what it is, is planning seems to take a long time, it needs to be very deep, and it can be very expensive and so oftentimes customers say; 'well, I understand we need to plan everything but let's keep moving forward and we'll get to that later' or 'we'll get back to that but we got to get this solution in place'. I think it's probably the depth aspect of it.
One of the things we see is that customers don't test the solution they've put into place to the extent they need to before they start using it and so if they stand up a new UC solution with a whole bunch of, session border controllers and they designed it out based on how many people they have and the complexity they have and their needs or requirements. They actually—there's really no way that they have available to test it under its full load. So if you're going to operate in a normal basis with everybody using it, how do you test for that in advance? So testing is another super critical part of planning or the pre-deployment phase that a lot of customers kind of skirt around. We actually recommend that everything be fully tested upfront. After your deployment is complete, you test it out, and then you test it on an ongoing basis. Every day, every hour, every week, you know, just to make sure the phones are going to answer when you expect them to. Every day of the week, every morning. So, you load test it all. Make sure it can handle the volume and the stress that you think you need, that you're going to have, and then test for it and test higher than that and then do something every day, every hour, and test critical components to make sure they're going to work when people expect them to because the last thing any user wants is to go into an online meeting or an important call on a contract and they find out they can't make a call.
Scott: I would imagine testing is important not only for the reliability issues that you're talking about, but just determining if the solution is as good or it's the answer that you're expecting it to be.
Skip: Yeah, technically, I mean, the technology could be functioning absolutely as planned. It's working, they look at the monitoring software, everything looks green, there's no problems to report, but at the end of the day, the user experience or the customer satisfaction isn't there so you're right with that question, which is is this system operating with the intended result you had? And that's something has to be—you got to look at that all the time and get that constant feedback from the users whether those are internal employees or if it's a contact center, is the external—is the customer experience as you intended it to be even though the technology's working fine? You know, those are some kind of critical things companies always have to be watching out for and oftentimes they're nontechnical.
Scott: To have an effective UC system, you need to have a plan and you need to test. IR can help. Learn more at IR.com.
