Rethinking Implementation Planning for the UC World
Best practices must evolve, as the proven old ways of doing things are not good enough anymore.
Implementation planning for communications technology solutions has evolved over recent years, although vendor methodologies lack consistency. Still, what used to pass for acceptable procedure or even best practice is no longer the right way to optimize the opportunity for successful installation.
A legacy PBX vendor often still uses the same approach that worked for years with telephony cutovers. Most every industry veteran can recall the long weekends of a large flash cut to a completely new PBX, replete with copious amounts of coffee, cross-connects, and cold pizza. Many a telephony tech made more money in overtime on cutovers than regular pay, albeit at a cost to family time.
A vendor with an IT background is more likely to recall a cutover as a rolling process that usually required long periods of overlapping solutions. In many cases, scheduling was fluid and communications with users was often vague to provide the needed flexibility. The technical team was often engrossed in dealing with the application or configuration problems that surfaced after the latest round of go-live cutovers, especially during the early stages.
Today's communications solutions inevitably require both telephony and IT elements, and implementation planners should learn from the experiences of each group. However, neither approach is sufficient without acknowledging the deficiencies in old practices and the impact on the organization. The lessons learned should include analysis of the strategies, not merely the efficiencies of the tactics used.
One of the first implementation planning discussions usually covers the best night for undertaking cutovers that might affect service. Perhaps not surprising, many (formerly PBX) vendors still push for Friday night/weekend cuts -- supposedly to give them more time to deploy sets and fix problems. However, avoiding Fridays is a good idea for many reasons.
First of all, external personnel are more difficult to locate on weekends if any issues develop; this includes experts at both the manufacturers and the carriers. Second, Monday mornings are often a peak time for many companies, and the added pressure of a new system and process are an unwelcome burden for employees. What's more, training from the week before is often forgotten (more on this later). Departments or clients that are 24x7 will appreciate avoiding Friday night cuts, too. Of course, Monday must be a first day of service in some cases, such as when a client moves between locations over a weekend.
The other early discussion about scheduling is how to roll out the new capabilities/features of a unified communications system. We often review the following three options:
- Slash cut everyone and everything. This is like the old PBX days: Activate all features and all users as part of one big cutover. With large quantities of users, the cuts get more chaotic and risky. First day of service can be a zoo. Even if the pilot went well, a problem that carries massive impact could surface. In many cases, the emphasis on quantity leads to a drop in both quality and attention to the enhanced capabilities. Only the basics seem to be critical and many fingers are crossed. The recommended solution to these challenges is a phased rollout, dividing users in manageable quantities for each cutover and first day of service -- even if they are on consecutive days in a rolling implementation plan. This leads to the next two options.
- Staged feature rollout, regardless of phasing of user cutovers. This philosophy is based on the idea that users can only learn so much at one time and/or the support team is not prepared to deal with maintaining all the new capabilities. Generally, the challenge is determining which features to roll out when, in terms of both sequencing and timing. Although some groups may like the concept of steady productivity gains as users learn new features, they must also consider how disruptive the cycle of constant adaptation might be for their companies.
- Complete solution cutover, but phased user installs. With most systems today, UC features are so embedded in new user tools and processes that holding back on some capabilities could actually cause much more work, cost more money, and add to user confusion. Doing so may also delay promised business benefits, assuming that business requirements helped drive the justification for a new UC system. With adequate time between cutovers to enable both pre-cut training and post-cut adjustments and follow-up, the users can become more productive sooner. As long as the support team gets adequate technical training, the business will get more total value faster.
Click to the next page for more guidance, including on pilot testing and training