Good planning can help you to move at a quick pace while still delivering business value.
Good planning can help you to move at a quick pace while still delivering business value.
Look up “hasty” and you will find synonyms that convey speed and quickness next to others with less flattering connotations: injudicious, thoughtless, impulsive and rash. The latter will not earn you kudos from corporate leadership.
In this fast-paced era, doing things right doesn’t have to mean slow. In fact, a little planning can help you move at a good pace while still delivering business value. After all, that’s why you are investing in something new, right?! Whether it’s a technology upgrade, rip and replace, or specific new capabilities, we’ve got some tips to help you succeed.
Start with a Little Planning
A typical project charter will identify the stakeholders and project team, the roles and responsibilities of each, and the scope and objectives. As you target the “big three” goals of service improvements, cost reductions (or containment) and sales/revenue increases, use outcomes such as improved self-service, reduced volume, faster handle time, cSat gains and higher close rate to make those platitudes tangible.
It’s easy to get bogged down in the details of a project plan. Yet it’s important to consider not just how you’re going to implement this new thing, but what you are going to do differently this time, and what you will achieve (and/or what business problem(s) you are solving). It is very tempting to take the “replicate for now… pursue changes later” approach because it is often what the team, as well as vendors and their partners, prefer. (It’s fast and easy, leading to cutover and billing sooner!) But, it inevitably leads to your center being stuck in the old ways as it is hard to get around to making changes later. “As-is” is a dangerous path that can turn technology excitement and promise into disappointment and cynicism. It’s no wonder many leaders distrust technology investment!
So what do you do instead? Define changes to processes, new workflows and call flows, new/improved user interfaces, etc. Establish success metrics that enable you to monitor progress toward goals after implementation. Then you can report to executives that there was value in the implementation, increasing your credibility and potentially simplifying approvals in the future.
Part of achieving success is avoiding problems that could compromise it. So, the initial planning should also proactively address some of the “typical” problems implementations face, including use of internal resources, vendor roles, project timing, and functional plans. The two tables give you common approaches to avoid in project execution (Table 1) and functionality (Table 2), and some “must-do” alternatives to deliver positive results.
Define Phases
With speed as a driver, phasing can help you get something done sooner, while not losing sight of the overall goals. A manageable first phase lets you get an early win, ideally having a noticeable impact. You may slice phasing by groups, customer subsets, application areas, channels, phone numbers, etc. Look at what you can readily carve out without overcomplicating the rest of the implementation. Keep in mind that the lack of a “big bang” cutover of everyone and everything at once can have ripple effects into routing segmentation, network requirements, integration, functionality offered to customers, etc. Decide what level of design and integration you will tackle early. See if you can make an impact on the customer experience as well as the agent experience, building goodwill for the additional changes to come, and gaining important insights to tuning as you roll out.
Subsequent phases should then follow quickly so you can maintain momentum and keep resources assigned and focused—both internally and with your vendor/VAR. The whole implementation is one plan defined by milestones which are accomplished before moving on to the next step, not many projects strung out over years. And keep in mind that phased implementation can affect licensing, so you should understand how your vendor structures licensing by function, channel, users, etc., and plan accordingly.
Test—Yes, Test!
Testing is a dreaded step for implementation teams. It’s tedious work, and many wonder if all that effort will result in an earth-shattering discovery. With cloud solutions, it seems even less important as the system is in, up and running already. But a little testing can go a long way to ensuring a successful cutover—whether premise or cloud. And while it may be more important for premise, it is still important for cloud solutions to address the things unique to your environment and configuration.
Define a targeted set of test cases that address the main changes and ensure the users (internal and external) will have a good experience day one. Testing is particularly important for things like menus and call routing, but its importance extends to anything that is important to your operation (e.g., reports and recordings).
Depending on the source of your network and how much is changing, verifying connectivity and performance can be critical as well. Examples of where it may be important include multisite, new connectivity to a cloud solution or big changes to load burden, and therefore, capacity demands on your existing LAN andor WAN (e.g., first migration to VoIP, changing overall architecture). SIP is another example of an impactful network change that warrants testing. If you are pursuing that migration, testing (andor pilots) are important. (For more on SIP, see our January 2018 Tech Line column, “SIP in the Contact Center,” where we highlight configuration as perhaps the most vulnerable element—and a great argument for testing!)
Recognize that the majority of the burden for testing, and for User Acceptance Testing (UAT), in particular, is on the buyer, not the vendor. UAT is extremely important as it shows whether or not the solution as implemented and configured is meeting the defined requirements. VendorsVARs often do little in the way of UAT, although partners are more likely to help through (fee-based) professional services. They may also offer guidance to you on user acceptance testing you perform. Tap their expertise, if possible, but don’t assume they will be involved. Unless it is specifically outlined in an SOW, assume the testing the vendorsVARs do is just to confirm the system is “working.”
Define appropriate test types: UAT and System Integration Testing (SIT) at a minimum, with the possibilities of load andor failurerecovery testing (depending on your situationapplicationindustry), and usability if you are doing something dramatically new for your customer interface (such as speech recognition or bots).
One of the dread-inducing tasks is developing test plans. That means crafting appropriate test cases, with associated inputs, expected outputs, tester instructions, and the tools and database to capture outcomes. These plans should equip the team to conduct the tests, capture results in a formal manner, validate issues, troubleshoot and resolve (hopefully!). Then, retesting must ensure all issues are resolved and that no new issues have surfaced as a function of changes made.
What About “Modern” Approaches?
Some IT departments pursue “agile,” “scrum” or “waterfall” approaches to technology projects or application development, taking a different view of how to use a team. The underlying goals generally include moving faster, in increments. Others talk about “fail fast” with a willingness to try things and, if they don’t work, yank them out. This mindset might migrate into contact center technology projects.
While these modern approaches have their place, approach with caution for the contact center. Not to say that the center is more complex than any other business operation, but it is still risky because of the impacts on people—customers and agents—and processes. Assessing an implementation as a failure too quickly can lead to a dangerously dynamic environment. You don’t want to create an erratic customer experience, or a bad one! You also don’t want to subject agents to relentless technology change as it always has process implications (and ripple effects to training, at least).
With good planning, you can try things. You need a well-defined scope and a good back-out plan (with criteria for determining success or failure), along with good measures of success. If it isn’t working based on established criteria, assess why. Then decide if you fix it, providing a chance to succeed and avoiding too much change and back and forth for your employees and customers. If you decide to undo it, it’s time to redo or try something else.
Speedy Success
In today’s world, we recognize centers need to be agile and move fast. Cloud technology reinforces—and enables—this message. People want to implement contact center technology relatively quickly, but they also want positive outcomes with tangible benefits for customers, the center and/or the company. You can find rapid success, but don’t ignore the goals and metrics, the realities of technology complexity, and the critical role people and process changes play in making that new technology shine.
When Do Pilots Make Sense?
Phasing is more likely than a pilot, although pilots still have their place. For example, they are a great fit when you are doing something you are not sure you will roll out, or that has high risk. They also help with “nichey” applications or ones that are relatively new, such as those that target security and fraud prevention. We like to differentiate a pilot as a “try it out” situation (when you are not committed to rollout of pilot solution or approach), rather than implementing a first phase and then optimizing as you roll out (when you are committed to going forward). You may even pilot a cloud solution, as some vendors offer “free trials” or easy contract cancellation terms.