Section 8.4. Implementation Plan
8.4. Implementation PlanYour project timeline, the labor resources required to complete the project, and the training plan comprise your implementation plan. Even with a truckload of top-of-the-line gear and all the technical knowledge you can absorb , your VoIP implementation can fail if you don't ensure that there's enough:
8.4.1. Knowledge FoundationYour technical know-how will prepare you to project the size , scope, and commitments of time and money that will be required to complete your VoIP rollout. Learn the technical nuances of IP telephony, and you'll be much better prepared to qualify, delegate, and prioritize the tasks involved in the rollout. Technical depth also gives you a better foundation for dealing with your telephony system salespeople and contracted engineers . 8.4.2. TimeHow long will it take to assess your network? Assess your voice applications? Think about the way your organization uses voice systemsdo you have a receptionist who handles all calls? A small office or a large, multilingual call center? How will the size and scope of your user base affect the completion date you, as an integrator, are willing to commit to? A good way to get a realistic grasp on just how big your voice project will ultimately be is to interview the end users who are most familiar with the usage of current voice systems in your office. The receptionist, if you have one, probably has a special wish list of features, while the salespeople or dispatcher has a totally different list of "nice-to-haves." In the end, it's these end user desires, and the desires of the organization, that will measure your success. How much time will it take to program each phone? Each server? Each Ethernet switch and router? How long will it take to provision equipment, train administrators, convert or consolidate phone lines? How much of this can be performed by a third-party vendor versus internal staff? Get as good a grasp on these matters as you can. 8.4.3. Manpower, Vendors , and VARsYour project-management style will vary depending on the size and scope of your VoIP project. Some VoIP adopters prefer to manage the project internally along with other projects; others may have a dedicated project manager lead the implementation full-time . That project manager may be an in-house employee or an outside contractor. Who is going to provide leadership for the overall system conversion to VoIP? Will regional or departmental leadership be necessary? Will the implementation team be small enough for one project manager to lead, or will it be a large team? Now, telephony system vendors may be able to assist you in making these manpower decisions. They may also be able to help you size your implementation team or provide supplemental support to your internal systems group . 8.4.3.1 Selecting a VoIP platformSelecting a commercial VoIP equipment platform is probably easier than selecting a VAR or consultant to implement that platform. Equipment makers usually provide spec sheets that outline the technical capabilities of their solutions. Signaling standards, codecs, network compatibility, and capacity are usually worn on the sleeve, so deciding between Avaya, Cisco, Alcatel, Siemens, Shoretel, Nortel, Polycom, or SNOM is usually a deductive, feature-comparing affair. A pretty painless way of comparing and contrasting all those equipment makers is to compare their support of the features needed by your organization, point-for-point. To do this, consult your user community and develop a list of all of the features and standards that are desired. Include any feature that is currently in use on the existing legacy voice components that are being replaced . Don't leave out anything just because it is taken for granted on your current system. Really dig in to your users' workflow in order to assemble this list. You'll probably find that it's at least a few pages long. Next, assign a priority score, which we'll call a weight, to each feature on the list. Assign 3 to those items that are absolute must-haves. Assign 2 to the items that are very important but not showstoppers if they don't exist on the new system. Assign 1 to the items which are merely nice-to-haves. Now, organize the features on the list in groups that make sense. Put call-handling features like conferencing and music-on-hold together. Put messaging features like email notification and all-points bulletin together. Once all the features are grouped and weighted, examine each vendor's ability to provide each feature on the list. If the vendor provides the feature, add its weight to the weight of the other features that the vendor supports. As you examine each feature, you'll begin to develop a cumulative score of this vendor's ability to support your needs. Use this technique for each vendor that you're considering, and you can compare their scores head-to-head. Using weighted scoring will result in an emphasis on the features you really need. Add up the scores by group and by vendor, and it should be pretty obvious which vendor you should select. Use Microsoft Excel or your favorite spreadsheet to automate the tally using formulas. Table 8-5 shows an illustration of this concept from an actual telephony feature comparison study. Table 8-5. A partial feature comparison worksheet
When creating a feature comparison worksheet, use your own feature requirements, not those that appear on one vendor's spec sheet. Think about individual features you or your users have used. Do the phones need LCD displays? Do they need backlit keypads? Do they need a speakerphone? What about inline powerdoes each vendor provide a solution that meets your needs? Does each vendor allow analog or T1 interfacing to your current PBX systems so that you can do a staged migration? 8.4.3.2 Choosing a VARChoosing a manufacturer's representative can be a daunting task. Corporate politics often play a role. If you're the sole decision-maker, then more power to youbut make sure you select (or recommend) a VAR for the right reasons. Chief among these reasons is a willingness to support published standards, and a standards-friendly attitude isn't always politically correct. If you're not the sole decision-maker, then the information that follows could be very valuable to you. The people in the boardroom don't care about technical capabilities or geeky religious fascination with one brand or another. They care about productivity, efficiency, minimizing costs, and the potential for system growth. It's up to you as an integrator of VoIP to convince decision-makers who aren't savvy to the technology that a basis in standards is the best way to achieve these goals. What makes it tough is that VARs tend to claim just the opposite : that the standards "aren't good enough yet" and will cost the organization more than their own, possibly proprietary, solution. You may be totally sold on building your VoIP network with a certain vendor's platform. But because of a political connection that's out of your control, you're forced to deal with a VAR who doesn't handle that vendor's equipment. Keep standards-compliance in mind from day one, and you'll have a better chance of avoiding this situation. 8.4.3.3 Creating an RFPUnless you have a well-trained team of people who implement VoIP networks all the time (not likely unless you're a VoIP integration consultant), don't make the mistake of thinking you can implement the whole thing by yourself. Voices from outside your organization are very importantand accurately communicating your intentions and requirements to them is equally important. Hence, if your VoIP project is larger than a dozen phones or so, you should draft a Request for Proposals to define the scope of your implementation and qualify interested resellers and consultants . Your RFP should clearly indicate :
Design your RFP so that standardsnot brand names , makes, and models, are the prescription for success. Instead of selecting a particular manufacturer's platform ("We're standardizing on Siemens"), select a set of published standards upon which to build your platform ("We're standardizing on SIP, DiffServ, and 802.3af"), and then write your Request for Proposals so that standards-compliance is required. Require each RFP responder to explain how she will support the standards you need. This way, if you prefer a different vendor than your senior-level management does, your argument doesn't need to be, "I just like Nortel better." Instead, it can be, " ABC system adheres to the standards that our company requires, while XYZ system does not." Your quarrel with the status quo will sound a lot better if you back it up with published standards. Your RFP's basis in standards allows you to put dollars behind your preferences. If a particular vendor doesn't support a certain required standard, you can calculate the additional cost imposed on the project associated with that lack of compliance. For
example, if you can't use SIP-only endpoints, which are fairly cheap and interoperable, you could demonstrate how much more it will cost to implement the solution using SCCP endpoints instead. 8.4.4. TrainingHow will your end users be trained? How will your system administratorsyourself includedbecome familiar with the quirks of a VoIP network? Who will do the trainingan outside vendor or an internal expert? How much time will it take, and how much will it cost?  |
EAN: 2147483647
Pages: 172