Section 8.4. Implementation Plan


8.4. Implementation Plan

Your 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:



Time

To assess the network, understand users' needs, and provision equipment



Manpower

To program and deploy IP phones and servers and to provide project leadership



Training

For the end users of the system



Standards basis

To ensure proper interoperability with old and new voice systems

8.4.1. Knowledge Foundation

Your 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. Time

How 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 VARs

Your 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 platform

Selecting 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
 

Cisco Call Manager Express

Avaya S8300 Media Servers

Asterisk in-house w/Cisco phones

Asterisk hosted w/Cisco phones

Message-waiting indicator on phone

Yes

Yes

Yes

Yes

Forwarding of messages to email

Yes

Yes

Yes

Yes

Flash firmware updates to other vendors' phones

No

Yes

Yes (TFTP)

Yes (TFTP)

Flash firmware updates without interrupting calls in progress

Yes

Yes

No

No

Automatic hardware failover on softswitch cluster

Yes

Yes

No

Yes

Ability to use SIP endpoints without closet gateways

No

Yes

Yes

Yes

Use MS Outlook to play back voice mail on endpoint speaker

Yes

No

No

No

Runs on Linux

No

Yes

Yes

N/A


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 VAR

Choosing 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 RFP

Unless 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 :

  • Your stated objective in seeking IP telephony solutions

  • The general scope of your project (are you setting up an IP trunk to link two PBXs, or are you giving IP phones to 1,000 users?)

  • What features and applications are required, and by which users

  • The user count and departmental structure of your organization

  • The structure of your current network

  • Your standards preferences

  • Which pieces of legacy equipment need to be integrated into the VoIP network

  • A realistic time frame for completion based on your own technical knowledge and business requirements

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

Long or Short RFP?

Short. Writing a long, laboriously detailed RFP may be a good exercise to flex your mental VoIP muscles and refamiliarize yourself with voice terminology. Writing a 200-page RFP might be a minimum requirement at the Internal Revenue Service, but it isn't going to get you a better VoIP proposal. Keep in mind, even if you've become a VoIP expert and you've got a pretty detailed plan about how to proceed, it's still the RFP responders' job to fill in the blanks, offer their advice, and prove their knowledge.


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. Training

How 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?



Switching to VoIP
Switching to VoIP
ISBN: 0596008686
EAN: 2147483647
Year: 2005
Pages: 172

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net