Technology Implementation Challenges And Best Practices

Momentum and excitement builds around new contact center technology as you make a vendor and product selection and set forth on your journey with exciting possibilities ahead. Unfortunately, a variety of implementation challenges can arise that knock the wind out of your sails. To optimize results, invest the time up front to plan and prepare. The Statement of Work (SOW) with your vendor is a key to success. Get the details right to make your implementation smooth sailing.

Closing the Deal

Closing a purchase deal with a vendor is not just about signing a contract. Contact center technology implementation depends heavily on a good SOW. The SOW describes the professional services the vendor and/or their partner(s) will provide. It covers all activities from detailed requirements and design through configuration, development, integration, testing and training, to cutover and acceptance, and maybe even some post-implementation services. The SOW builds on any Request for Proposal (RFP) or other requirements you’ve written and the discussions you’ve had through the evaluation process. Ideally, you’ve invested time in deep- dive presentations and demonstrations, with a focus on your specific needs. The vendor may need to do some additional discovery  before finalizing, or request the option to adjust after they take the first steps. You’ll see in the rest of this article that many of the typical issues people face in implementation rely on careful definition of roles and responsibilities up front so the investment of time in the SOW pays strong dividends.
Perhaps the most important reason for getting the details clear is to define the price. Nobody likes surprises after the contract value is approved! Good documentation of assumptions—and review and validation of them—is a fundamental underpinning. Clarity on who is responsible for what (including integration, hardware, network connectivity and services, testing and training) is another key element to look for. If it isn’t in there, don’t assume the vendor will do it! Roles can vary based on the sourcing strategy (see “Cloud Implementation Considerations,” on page 26), vendor and solution, as well as the resources you are putting on the project (IT, training, support functions, etc.).

Planning the Timeline and Resources

The two main factors that define a project beyond the price are the timeline to which you are held, and the resources available (internal and external) to make it happen. Both can present challenges to a successful implementation.

We frequently see project teams under time pressure, and executives are often the ones driving speed. Educate them on the risks and the value of a more methodical approach. Speed often leads to cutting corners and may compromise performance in terms of functionality delivered at cutover and/or how well it works. It’s better to define a realistic timeline that you can achieve, rather than agree to an unrealistic one that you will push out. The vendor may like speed as well, but make sure that the timelines they are driving for are realistic on both sides. You risk loss of their resources when your project hits delays.

Speaking of resources, make sure that you have enough, at the right time, to support the proposed timeline. Clarify vendor resources that will be on the project and their availability (especially to start) and commitment to the project. Make sure someone will be dedicated to oversee the entire project from beginning to end and provide continuity in key roles like design engineers. Define when and how people need to be involved on your side—contact center and IT leaders are the obvious ones and have bigger roles, but don’t forget legal, HR, training, change management, testing or others. Let staff know that inability to commit proper time to the project could have negative consequences to the overall project, including financial impacts. A good resource plan that continues to be updated as the project evolves is a key to success, and that occurs when you have a strong project manager who secures and retains resource commitments.

Ready, Set, Go! Implementation Under Way

Once the agreements are in place with project and resource plans defined, it’s time to really get started. Here are the most common issues we see, with a common theme of clarity in the SOW as a “silver bullet.”

Getting everyone to design for business value instead of duplicating the current state is a ubiquitous challenge. If you don’t get it right during implementation, it is highly unlikely that you’ll make the necessary changes later. Internal resources must have the time, energy and vision to redesign. The vendor must have the same mindset and the appropriate SOW to achieve it. A key enabler to proper design is for everyone to understand the new system and its capabilities, which is achieved through those deep-dive presentations and demos and discussions specific to the requirements mentioned above. Help the team understand the new solution’s lingo, how it’s different from what you have and can support your business goals. And don’t forget to address how it will change operations and the implications for staff (frontline, leadership, support); change management starts here. Integration of the new system is often critical to achieving the value the new system offers. Integration is typically a shared responsibility between the vendor and IT, and it’s not just about an application programming interface (API). The vendor needs to work with your team to leverage that API. IT will address what needs to happen on your side (e.g., Web Services, changes to the desktop, etc.).

Managing new hardware that will be in the customer environment varies with the sourcing strategy (premise or hosted/cloud—see sidebar) and solution chosen, but can’t be overlooked. In many cases, the vendor is providing software and the customer is responsible for some hardware. Ensure clarity on who is ordering what, and when, based on specifications from the vendor and the timeline. Know your lead time with your suppliers to make sure that hardware and software delivery align. Make sure you know who is responsible for implementing the hardware and loading the software, and where it will reside (e.g., whose data center).

Provisioning network services (e.g., MPLS, SIP) faces the same issues on clarity of who is responsible and when things are needed. Sometimes MPLS is the slowest part of a project so can have a big timeline impact. Get dates from suppliers up front as managing the carriers can be a BIG issue. Many don’t feel the urgency and don’t have enough competition to feel pressure to meet your timeline. Part of your vendor agreement is whether you pursue network services directly and separately, or whether you are relying on the solution vendor to do it (especially if using a hosted/cloud solution).

Getting enough onsite time can be a real point of contention. In many situations, the vendors are trying to minimize it, and you might like to maximize it. SOW details are critical here, and you may want to define options to invoke if needed. Consider these targets:

Design. If you are redesigning for business value, our view is you need some onsite face time to do white board activity and really dive into how to apply the new technology. If it’s all remote, chances are it will be very basic and/or replicate the current state.

Training. Many vendors like to use web-based training, have you go to their training sites for system/admin training, and do some initial “train-the-trainer” training. It is no longer typical for them to come on your site and train people face-to-face. Define what will work in your culture and fit with your training style, and be prepared to pay extra for more onsite time. One other key to success in training that often gets overlooked is the training environment, so make sure that is on your project plan as well.

Cutover support. Consider how many days you want a vendor presence during and after cutover. If it’s a multisite or phased rollout, define if you need them for subsequent cutover stages.

Testing is one of the biggest keys to success and one that has plenty of opportunity for things to fall through the cracks. Remember, if it’s not in the SOW, the vendor is not doing it. Define your requirements for the types of testing you want done, and then define who is doing what. Typically the vendor performs some level of system testing, and possibly some system integration testing (SIT), working with your IT team. Determine if you specifically need network testing or a network assessment (which is likely if you are putting in a VoIP system, for example). Determine if load or failure/recovery (BC/DR) testing is important to your environment (e.g., you have big peaks, you are putting in a new resilient architecture), and if so, recognize that it is likely out of scope and requires additional services and/or internal resources. You may want to consider outside companies (such as IQ Services or Enterprise Integration Group) for load, function or usability testing.

Define how you will test, including the test numbers you will dial and test data you will use. This sounds simple, but it’s not always so, depending on systems, lines and numbers available. All too often, the test system does not match the production system, but it should, if possible! Don’t forget about defining the testing environment and setting that up as part of implementation, and defining clear criteria for determining that the system passes testing. An issue that combines training and testing is clarity on what training is needed, for whom, to support user acceptance testing (UAT), keeping in mind that UAT is generally not a vendor responsibility. Differentiate training those that will perform UAT from end-user training.

Transitioning to Support and Optimization

You must understand and manage the transition from implementation to support because the game changes when you lose the resources involved in your design, testing, training and cutover, and move into a general support queue if something isn’t right. Make sure it’s clear if acceptance occurs based on a defined time period (e.g., X days) after cutover (this could literally be at cutover!) or when you achieve a defined state of operation. If the latter, what criteria does it consider? For example, X days of issue-free operation? All tickets from cutover closed (or all tickets of a certain level)? All licenses in production?

What if you have a phased rollout (by site, groups, functions, etc.)? Ultimately, you want the transition to happen when both you and the vendor agree it’s time, but you should have a strong hand to “approve” that transition. The vendor may have a standard approach but you also want to know that they can provide special support if things are not going well.

Optimization afterward isn’t a given; build it into the services you procure if it’s important to you. Once you really get to know the system in production, you may want to do some tuning (think about routing, skills, reports, etc.). You may also want some followup training, knowledge transfer or general consulting services from people who know the system, your environment and your staff. That means you want resources that were involved in your project to come back later, so make sure that is the vendor’s expectation as well. For example, some vendors offer a 90-day performance check that can help you get more out of your system when you’ve got some experience under your belt.

Prepare Well

While implementing contact center technology may not be akin to exploring the Polar Regions, a quote from Roald Amundsen seems applicable: “Victory awaits him who has everything in order—luck, people call it. Defeat is certain for him who has neglected to take the necessary precautions in time; this is called bad luck.” Ultimately, while you must be agile to address issues that inevitably arise, luck—good or bad—will play no role in implementation if you prepare well with a solid SOW and an eye toward best practices.

– Reprinted with permission from Contact Center Pipeline, www.contactcenterpipeline.com