Planning the Cisco CallManager Implementation

Establish a Rollout Plan

A rollout plan represents the method you will use to enter phones into the CallManager database and distribute the actual phones to users' desks. A rollout plan should include

• Time of day of phone placement

• How users will be notified of the technician's visit to their offices

• How phones will be connected to the network

The rollout plan is critical to the success of any installation. Without a solid plan, your visits to users' desks will be haphazard, you might forget some users, or you might place the wrong phone models on the wrong desks. Without a plan to keep you on track, you might not finish the rollout on time, which is probably one of the worst things that can happen, especially for a large cutover. On top of that, without the plan, you could find yourself running around the building at 3 A.M. on a Sunday morning looking for someone's office because you didn't have the right floor plan, didn't know that a user moved his or her desk, or couldn't get security personnel to open the necessary doors.

Determine How to Add Phones to the System

Depending on the size of your rollout, the most labor-intensive job might be placing the phones on users' desks. There are two basic approaches: Use BAT in concert with the Tool for Auto-Registered Phones Support (TAPS) with dummy MAC addresses generated by BAT, or configure all the phones in the system with the actual MAC address and extensions.

To decide between these two approaches, you have to consider the following factors:

• Number of phones

• Amount of time to cutover

• Quality of end-user logistics

Consideration: Number of Phones

If you are rolling out a large number of phones (more than 200 to 300), it's probably best to use TAPS. With TAPS, you can add the phones to CallManager using dummy MAC addresses, which means you don't have to enter every MAC address for all the phones and associate them with a directory number. Instead, TAPS assigns dummy addresses that are later updated with the phone's actual MAC address when a user dials a specific directory number to download the phone's configuration. Using TAPS means that technicians can simply place the phones and an instruction sheet on users' desks. The instructions should explain how to plug in the phone (if the technicians do not install the phones), dial a specific directory number, and follow the steps to use TAPS. By the time the user hangs up, the phone will have downloaded its specific configuration and will be ready to use.

The TAPS method is relatively low-risk and works well. The downside is that the users must perform some actions to make the phones work; they don't just arrive at work on Monday and find a working phone. TAPS is deployed as part of an IVR through Cisco Extended Services. Extended Services Customer Response Solution (CRS) ships with two ports only, so the maximum number of simultaneous calls that TAPS can accept is two. On a full CRS deployment, the number of simultaneous calls into TAPS depends on the number of licenses you purchase and the number of computer telephony integration (CTI) ports you configure for TAPS. Consult the CRS and TAPS documentation on Cisco.com for installation and configuration information.

• TAPS is documented as part of the Bulk Administration Tool documentation at http://www.cisco.com/univercd/cc/td/doc/product/
  voice/sw_ap_to/admin/bulk_adm/index.htm.

• CRS documentation is available at http://www.cisco.com/en/US/products/sw/custcosw/ps1846/
  prod_software_versions_home.html.

TAPS is a great tool when used in combination with a single, standard phone model for all users because you don't have to spend a lot of time on the logistics of where specific users sit. When you're installing a system, location is by far the hardest information to gather accurately, especially in a green field installation. The information almost always changes, resulting in people having the wrong phone models.

A middle-ground approach involves gathering as much user information as possible and having the installer do the TAPS login at install time. The issue with this approach is the uncertainty involved with getting the correct user information.

If you are a Cisco Certified AVVID partner, be sure to have several company employees available on site to help you locate users' offices and cubicles and to open doors. It's also critical to have the support of the security officers at the site. Ask for additional security officers to be on hand to help unlock doors.

Consideration: Amount of Time to Cutover

When you're working on a tight schedule, you might not have time to unbox all the phones, enter their MAC addresses in CallManager Administration, and rebox the phones for placement on desks. Using TAPS means you can simply dispatch the phones to the proper locations for placement and have end users dial TAPS to configure their phones. When you have more time during the cutover, you have the luxury of adding the phones' actual MAC addresses into CallManager Administration.

Consideration: Quality of End-User Logistics

When you are working in an environment in which you don't have good floor plans for the buildings, you have almost no idea where specific users sit. For that reason, using TAPS in combination with a single, standard phone model for all users (such as Cisco IP Phone 7960) allows you to put phones in every occupied cubicle or office, and people can dial the TAPS number and enter their extensions to download the phone configuration. In addition, there are delicate situations in which getting information about extension numbers can be challenging. Again TAPS helps, because users can enter their own information. If you encounter such a situation during the planning process, it's generally a good idea to make the rollout easier by using a standard phone model for most or all users.

If you have up-to-date floor plans with up-to-date usernames, adding the phones using the real MAC addresses is quite feasible, because you know where people sit, you can count on security to open the doors, and you can plan certain floors for certain nights.

Migrating from PBX or Green Field

TAPS is generally very good for green field deployments, because no existing information needs to be converted on a user-by-user basis. However, in certain PBX migration scenarios, especially when direct inward dial (DID) numbers are changed or when phone migrations are happening in small groups (rather than in large batches), using the Bulk Administration Tool (BAT) or manually entering the phones in CallManager Administration is probably a better method.

Determine the Cutover Method

When planning the system's rollout, you must decide how to migrate from the existing system (if applicable) to the new system. If you're working in a new environment or green field, no cutover choice needs to be made, so you can skip this section.

The following sections discuss the three different ways to migrate a system:

• Flash cut

• PBX migration

• Dual phone

Flash Cut

A flash cut is a clean break from one system to the other. It often occurs over a weekend. Users go home on Friday and come in on Monday to a new phone system. All original phones are removed, and users begin using the new system immediately.

Flash cuts are best for small organizations and for small remote sites attaching to a larger cluster in a centralized CallManager deployment.

One of the most significant factors in a flash cut is user training and second-day support, which was discussed earlier in this chapter. Without good training before the cutover, there's no way for users to become familiar with the phone until it is on their desks in full production.

Testing the system is critical when doing a flash cut. After the system is installed and configured, it must be thoroughly tested in what is generally a short time frame. Flash cuts require a great deal of precision in the planning phase to ensure readiness.

Most often, the servers are preinstalled and configured in a staging environment before being brought onsite, which makes a flash cut a little more manageable. Instead of a staging environment, you might have had the system running in pilot mode with select users for a few weeks (known as an alpha cluster). Even with either of these pre-deployment testing phases in place, second-day support is critical because there are always unforeseen configuration tasks that get missed with high-pressure flash cuts. Users have no alternative phone system after the new system is installed, so having good user support in the first week after the cutover is highly recommended.

For more information about installation, refer to Chapter 3, "Installing CallManager."

PBX Migration

PBX migration is the type of cutover that involves connecting tie-lines between CallManager and the existing PBX. Tie-lines are simply lines that connect CallManager and the PBX. This method is often used in larger deployments because there is simply no other way.

In general terms, these kinds of cutovers are used especially when new buildings are put up or remote sites are added to the network. There are groups of users using CallManager, and groups of users using the PBX, and they need to talk to each other.

This method is quite viable, but there are some key best practices you should adhere to:

• Use Primary Rate Interface (PRI) or Q.SIG when integrating—These protocols provide the most functionality between the two systems. Things such as calling and called party name display are supported.

• Have enough tie-line trunks available—It's better to overprovision the trunking between systems than have too few channels between systems. When integrating systems, you must choose whether the CallManager phones will have their own Public Switched Telephone Network (PSTN) trunks. If the CallManager phones are on a campus, it's recommended that you have them act as extensions off the PBX and use the PBX for inbound and outbound PSTN connectivity. Because of cost and PBX space constraints, you might not be able to overprovision trunks. You might have to migrate tie-lines one at a time, which requires some level of accuracy. One way to get an idea of how many trunks you need between systems is to do a traffic study on the PBX for the groups of users you intend to migrate. For example, say you intend to migrate Building A. If you have the capability, check the call detail records on the PBX to see how much calling the users of Building A actually do. Using this information ensures that you have enough trunks between CallManager and the PBX when you migrate the users. If the CallManager phones are at a remote site, it's best to provision PSTN connectivity directly on CallManager.

For more information about traffic analysis, refer to the "Traffic Analysis for Voice over IP" document at the following link or search Cisco.com for "traffic analysis for VoIP."

http://www.cisco.com/en/US/tech/tk652/tk701/
technologies_white_paper09186a00800d6b74.shtml

• Understand the impact on the attendant operator—During your migration, you will have some users on the PBX and some on CallManager, which means that any attendant operators need visibility into the busy status of all the phones on the system. If maintaining visibility status of all phones is important to you during the migration, you have to use a console application that supports both platforms. It's impossible to give a recommendation because of the number of variables involved, such as PBX type and supported features. Check with your PBX vendor for supported third-party console applications, and cross-reference them with Cisco's Find a Partner list at http://www.cisco.com/pcgi-bin/ecoa/Search.

• Establish the voice mail integration method early on, and test—A difficult and critical decision involves voice mail integration. There are many options. If you decide to use your existing PBX voice mail, you can use a Cisco VG248 gateway and Simplified Message Desk Interface (SMDI) to integrate CallManager. If you have an Octel system with digital interfaces, you can use a Cisco Digital Phone Adapter (DPA).

If you decide to use Cisco Unity with CallManager and integrate Unity with your existing voice mail system, you can use either the VPIM or AMIS-A protocols. If your PBX voice mail system is an Octel system, you can integrate using Analog Octelnet with the Cisco Unity Bridge. Refer to the "Cisco Unity Interoperability Features and Functionality Comparison" document at the following link or search Cisco.com for "Cisco Unity Interoperability."

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/
products_data_sheet0900aecd800fe15f.html

Migrating your existing PBX voice mail to Unity is supported by Unity's dual-switch integration feature. For PBX compatibility with Unity, check the Cisco Unity Bridge System Requirements, and Supported Hardware and Software documentation at the following link or check the "Supported Phone System Integrations" section of the "Cisco Unity System Requirements and Supported Hardware and Software" document.

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/
prod_pre_installation_guide09186a008020aaf0.html

Dual Phone and Then Flash Cut

Some people managing deployments migrating from a PBX decide to place both CallManager and PBX phones on the users' desks but do not integrate the systems at all. This lets you configure and test CallManager completely and then flash cut the system in one evening.

This approach provides the greatest amount of time to actually roll out the phones, perform the training, complete all the needed testing, and answer all the users' questions and concerns before cutting over to the new system.

At the time of cutover, you have to move the components that CallManager will use from the PBX to CallManager. These components include PSTN trunks, analog stations, and voice mail connections. You also need to power off the PBX.

In addition, this approach provides a degree of safety in that you can simply power on the PBX and move the components back over if a catastrophic event occurs.

The dual phone and then flash cut option is recommended for large campus installations that leave their PBX behind and do not call for integration of CallManager. The sheer number of phones that have to be placed means that a simple flash cut won't work. In some cases you don't want to integrate with the PBX because of a lack of tie-line trunk ports on the PBX or a lack of license for the PRI and/or Q.SIG protocols.

Create User Information Packets

A best practice that is too frequently ignored is providing information to the user. Without a list of instructions, second-day support is made much harder because the Help Desk gets overwhelmed with calls.

Be sure to distribute user information packets (leave-behind materials) that give the user the following information:

• Extension (for example, 1000)

• Full DID number (for example, 214-555-1000)

• Voice mail number (internal access number, such as 5000, and external access number, such as 214-555-5000)

• Voice mail password

• Voice mail quick reference

• Phone PIN

• Help Desk number

• Phone user guide

• Name of installation technician

• Date, time, and contact information for phone training

One often-used technique is to print simple business cards with the name of the installer and the Help Desk number. These can be left on the users' chairs or stuck in their keyboards, where they will not be missed.

Without this information, users roam the halls looking for information and are generally not in a good mood on the first day of production. Users who can't acquire the information they need feel that the change from the previous phone system to the new one is a bad idea and that the new system is much harder to use. This significantly reduces satisfaction with the deployment and makes training the users on the new system more difficult.

Establish a Second-Day Support Plan

Most second-day support centers around the following items:

• Moves, adds, and changes—Be sure to have a plan to cover the inevitable changes that must occur during the first and second days of production. Have a handful of CallManager configuration people at the ready. The most common changes are the addition of shared lines, fixing incorrect extension numbers, and configuring intercom groups.

• Additional training—Users invariably need one-on-one training for certain features and functions. Some of this happens informally within workgroups, but it's important to be ready to do some handholding.

• Establish a "war room"—Reserve a dedicated conference room (sometimes called a "war room" during IP telephony deployments) where support staff can all work together to field questions as they arise and make any needed modifications to the system. Having the support team close to each other gives a sense of camaraderie and provides a way for everyone to learn from the problems and solutions that invariably occur during the first week of an installation.

• Addressing complaints about the process—This is one of those touchy subjects that always causes consternation among users. Sometimes users just need to vent their frustration with the process and the differences with the new phone system. Be sure to have a sympathetic ear, and be ready to help the user adjust.

• Broken or missing items in offices—Installing phones in people's offices sometimes results in damage. Be sure that you have some kind of formal grievance process for users to lodge their complaints and concerns. Sometimes personal items are misplaced or damaged as a result of installing the phone. In general, the network cable from the user's PC is plugged into the back of the phone, and a cable from the back of the phone is plugged back into the computer. This means that the technician installing the phone needs to get at the back of the PC. People have a habit of burying their PCs under lots of personal effects or in hard-to-reach corners of their desks. Be sure to instruct your installation technicians to report any damage. Institute a policy that allows for direct communication with the affected user, and replace damaged items. Being candid about any damage is always the best policy.

Institute a Problem Reporting and Escalation Plan

During the rollout period, it's important for the system administrator to understand how to get help. In addition, it's important to have the proper staff to address issues in a timely fashion.

The best approach if you need extra help is to use Cisco Advanced Services (shown in Figure 1-5; search Cisco.com for "advanced services"). You also can arrange for a Cisco Certified Partner to supply onsite resources up to two weeks after implementation to handle the influx of issues any new phone system can bring.

Figure 1-5 Cisco Advanced Services Page on Cisco.com

Companies often are caught short of resources, and customer service levels suffer. Regardless of resource constraints, be sure to set the right expectation with your users during training sessions so that they are not caught by surprise, waiting for problem resolution.

It's also important to have an escalation plan for employees who have critical needs. Be sure to have all Cisco Technical Support contracts and support numbers handy, and be ready to prioritize your users' needs. Again, increasing the size of your staff is highly recommended in the first two weeks of implementation.

Establish Operations Procedures

It's extremely important to synchronize the network operations team with the telephony operations team to ensure that network connectivity is not spontaneously interrupted. One of the biggest problems you'll face is that your phones are up and working, but you don't have an operations and management infrastructure in place. One of the first things you should do is create an e-mail/voice mail distribution list that includes either the heads of all departments or all users so that you can keep the relevant personnel informed when changes will occur.

Operations tasks include the following:

• Scheduled network upgrades—One of the biggest issues you could face is that random network engineer who constantly reboots switches and routers in the middle of the day because there's a problem or because a switch needs to be upgraded. Each time this happens, phone service or supplementary services such as conferencing might go down for some or all of your users.

It's critical to establish a regular outage window in which to perform upgrades. In addition, it's important to establish an e-mail or voice mail distribution list to alert all involved parties to any planned or unplanned outages.

Voice is one of the most critical applications you can put on a network. You need to ensure that the telephony operations personnel are aware of any network maintenance activity. Many unplanned phone outages are caused by simple lack of communication.

• Scheduled application server upgrades—It's important that you avoid taking down your voice systems every time a new patch or software version is released. You need to have a schedule and a procedure that alerts people that an upgrade is taking place. Be sure to document and send e-mail to your users if any changes in phone behavior occur. No one likes to be surprised when something as seemingly simple and basic as phone operation suddenly changes without warning.

• Scheduled dial plan changes—Sometimes making changes to the dial plan necessitates the restarting of CallManager services. Do not make major changes to the dial plan in the middle of the day and start resetting services, which causes calls to terminate without warning. Bring up new circuits and connect to other systems during a scheduled maintenance window using a standard change control procedure, not during regular production hours when a large number of users are affected.

• Scheduled new application deployment—When bringing new applications online, whether call center applications, Emergency Responder, Cisco MeetingPlace, and so on, it's important to use a scheduled outage window to perform these installations. Even with proper testing before deployment, you can't be 100 percent certain of the impact the application will have on the network until you deploy it, and it's best to not affect production users.

• Scheduled media resource moves, adds, and changes—If you intend to change conference, MOH, or media termination point (MTP) configurations, do so during a standard change control window, not during production hours.

• Scheduled gateway moves, adds, and changes—If you need to make changes to gateways, do so during a scheduled change control window. In almost every case, gateways need to be reset for the changes to take effect. Resetting a gateway during production hours most likely results in dropped calls, so it's best to make necessary changes when they least affect users (nonproduction hours).

• Established change management procedures—This is where some companies fall flat: They let their staff make fundamental changes to the system without following a change management procedure. In one real-life example, a company changed the name of its gateway routers during business hours, causing a major outage, but no one on the voice team knew anything about the changes. Because the voice team didn't know about the change, they didn't change the Media Gateway Control Protocol (MGCP) name in CallManager Administration. Therefore, the company suffered an outage while troubleshooting the issue. Establishing a change management and control procedure that includes everyone involved is important. See the "Change Management: Best Practices White Paper" at the following link or search Cisco.com for "Document ID 22852."

http://www.cisco.com/en/US/tech/tk869/tk769/technologies_
white_paper09186a008014f932.shtml