Melissa Swartz | No Jitter | September 12, 2013
Documentation, project management, testing, and training are among the elements that must be handled properly for the installation to go smoothly.
While deciding which new telephony solution to acquire can be a daunting task (see my previous article 10 Mistakes to Avoid When Replacing Your Telephone System), getting it installed properly is a different challenge. During the sales process, our clients are often told that the vendor will take care of everything and the installation process will be easy. If only…
As consultants, we have acted as project managers on behalf of our clients and have been involved in hundreds of installation projects. While each project is unique, here are some tips for avoiding issues that we see most often.
1. Include critical documents as part of the final contract. A lot of information is lost in the transition between the vendor’s sales team and installation team. Typically during the sales process, a lot of information is exchanged between the vendor and the purchasing organization, including how some features will be used, requirements of particular departments, and contractual requirements. More often than not, this information is not passed on to the installation team. This can result in sub-optimal configuration of the new system.
The best way to combat this is to insist that the customer’s RFP (Request for Proposal), the vendor’s response to the RFP, and any other critical correspondence, are included in the final contract. If a dispute develops later, you will have the proof you need to make the situation right. I have a client who videotaped vendor presentations and was later able to use the recording to prove that the vendor had promised certain capabilities that were not initially delivered.
2. Assign a project manager to represent you. The vendor’s project manager has narrow responsibilities. For example, if you are installing a new on-premise system, the system will be connected to local and long distance services of some type (PRIs, SIP trunks, etc.). There may be legacy third-party systems (paging, for example) that the new system must work with. All of these legacy services and interfaces must be organized to work with the new system.
Typically the vendor’s project manager is not responsible for coordinating any of this; they are focused strictly on the equipment/solution that their company has sold. Often we find that what the vendors call a “Project Manager” is nothing more of an “order tracker” who is primarily responsible for tracking parts and shipments and not for the overall success of the project.
Coordination is required with local and long distance service providers at a minimum; many projects have even more players involved (especially contact center projects). Someone must provide the oversight to ensure that all of the players will work together and that there are no last minute “oops” moments; that person is usually not the vendor’s project manager. Be sure that someone has been assigned that role on the client side.
3. Enforce the database freeze date. Most projects have a cutoff date when no more changes are to be made to the database for the new solution. Most customers make changes (adding or deleting new people, changes in coverage, etc.) after the cutoff date and want these changes reflected in the new system immediately when it goes live.
Best practice is to track all changes made after the cutoff date and program the changes after the system is tested, cut over, and all break/fix issues are resolved. However, customers want the changes “Now” and many install teams want to make the customer happy, so they agree to make the changes. This can lead to database corruption (worst case), or at minimum can keep the team from doing other necessary work, thus putting them behind schedule. While a few simple changes are not usually a problem, it is always wiser to set expectations that no database changes will be made after the cutoff date.
4. Create a thorough test plan and then follow it. When we work as project managers for our clients, we create a test plan that includes testing every phone (each phone must make, answer, and transfer a call), all paths for entry to the system (all main listed numbers, all toll free numbers, representative DID numbers, and specific executive numbers), call flows for call centers, and night treatments. We test ancillary systems such as paging and voice mail, as well as all voice mail menus.
The test plan must be customized for each organization, and some scenarios may have to be coordinated with the installation team, especially if call treatments change by time of day. It takes a thorough understanding of the system as well as discipline to create a comprehensive test plan, and it often takes tenacity to complete the testing. However, it is always better to find problems during testing, rather than having users report them and create the perception that the new system is no good.
5. Create a customized user training plan, and require end users to attend training. We have seen a trend lately toward a “Train the Trainer” format, where the vendor trains a few key users who are then tasked with training the remainder of the organization. This results in savings for the vendor, but often the end users receive inadequate training. We prefer classroom-style training with live phones for best results. Even then, there are challenges. Most vendors have a standard training curriculum that they have provided in the past. Typically, it is marginally adequate.
We believe that effective end user training is vital to the success of a new telephony solution. As project managers, we require the trainers to provide the training materials to us in advance and to deliver a sample training class for the client prior to training any of the users. Typically, we make adjustments to the class so that it better reflects the needs of our clients. Sometimes we have them remove material that is irrelevant to the way we plan to use the system; other times we have them add information (why we are making the change, how to reach the help desk, etc.) or cover a specific scenario where we plan to utilize new capabilities.
Often we find that there is no training for capabilities such as a desktop client, IM, Presence, Outlook integration, conferencing (audio, video, web); frequently these are the very capabilities for which the new solution was purchased. We work with the training team to ensure that all important system capabilities are covered during class. We then work with our client to ensure that the maximum number of users attend training.
In part 2 of this series, we cover issues that can occur with configuration and failover of SIP trunking.
We would be well-served to learn from lessons of the past and include an evaluation of a provider's financial stability during the buying process for hosted services.
User organizations often require help when implementing cloud services – a gap begging to be filled.
An RFP that is issued at the proper time in the process, is supported by a thorough needs analysis, and clearly articulates the requirements of the organization, is an effective tool.