Pilot or Prototype Implementation

A pilot or prototype of your proposed internetwork may be necessary to prove that your design actually meets the customer’s requirements. The data produced by a pilot or prototype can be a powerful tool as you present your design and (hopefully) win the customer’s business. The saying that “talk is cheap” certainly applies here. Anyone can claim that their design will work; here is where you prove that your design actually works.

The idea behind a pilot or prototype is that you do not need to build the entire internetwork to prove that your design works. Many times that simply isn’t feasible. Instead, you can select key components of the internetwork, implement them, and then test them under simulated real-world conditions. The difference between a pilot and prototype is largely one of scale. These differences can be summarized as follows:

• A pilot is smaller in scale, and thus requires less money and time to implement. It is useful to prove small portions of your design.

• A prototype is larger than a pilot in scale, but smaller than the finished internetwork; you don’t just order the internetwork and set it up, complete in a warehouse somewhere. A prototype can be used to prove sections or entire modules of your design.

Your customer will likely drive the choice between implementing a pilot or prototype. There are costs involved in completing either one. Your customer should be involved in deciding just how extensive your testing needs to be. The following sections describe the steps you need to take to implement either a pilot or prototype.

Steps Required for a Pilot Implementation

As mentioned, a pilot is simply a small test. It is useful for a small network design, or if only a small component of a larger design needs to be demonstrated. At a minimum, Cisco recommends the following steps for implementing a pilot:

Test the design. You should test your design and verify that it will work before proceeding with the pilot. A pilot is not an ad-lib, preliminary test in front of the customer. You do not want any surprises when you go in front of the customer with your pilot, so verify your design with actual testing before proceeding with the pilot. If your design fails at this point, re-evaluate your design and retest it.

Investigate what the competitors will be proposing. Cisco recommends you be aware of what the competition will propose. If you know what the competition is doing, you can prepare to present reasons why your design is superior. You may wish to outline the features of your design that are not supported by other vendors and demonstrate these as part of your pilot. For example, if you are aware of specific IOS features that are useful to the customer, but not available in products proposed by other vendors, use this time to demonstrate those features.

Note

Remember, the focus is still on the customer’s needs.

Write a script for the demonstration. Prepare a script of your presentation before you actually give it. This will keep you focused as you present. Your script should focus on several issues. First and foremost, your test should prove that your design will satisfy the customer’s requirements. Your test is also an opportunity to showcase your company’s technical expertise and the power and scalability of Cisco’s solutions. Don’t be afraid to demonstrate any potential problems with the competition’s solutions at this point. As mentioned earlier, talk is cheap. However, if you script side-by-side comparisons, be able to demonstrate both the acceptability of your solution and any problems with the competition’s solutions.

Practice the demonstration. As mentioned, a pilot is not a first shot. It is a scripted, practiced, real-time demonstration of a solution. Make sure to practice the demonstration ahead of time. Of course, this is no guarantee that nothing will go wrong. However, your confidence level will be significantly higher if you are not wondering how your demonstration will turn out.

Schedule time with the customer and present the pilot. Finally, set up a time and present the pilot to the customer. If you have prepared well, your confidence level should be high and your presentation should go smoothly. Be courteous of the customer’s time and be prepared to answer any questions the customer may have after you complete your demonstrations.

Steps Required for a Prototype Implementation

A prototype is larger in scale than a pilot, so there is more work to do to prepare for a prototype. Cisco recommends the following steps for a prototype implementation:

Review the customer requirements. To complete this step, go back to the customer requirements that you extracted at the end of Chapter 4. Armed with those requirements, note which of the customer’s concerns are most likely to be met by a prototype. Make sure to consider any aspects of your design that the customer may be uncomfortable or unfamiliar with.

Define the scale of the prototype. Decide just how extensive the test needs to be. For example, you do not need to purchase 1,000 PCs to test the load that 1,000 PCs would cause on an Ethernet switch. There is testing software available for this purpose. In this example, you may only need a few PCs and the switch. Identify any available tools that would allow you to simplify your prototype.

Investigate what the competitors will be proposing. As with a pilot, you can better tailor your demonstrations if you know your competition. For example, if you believe that your competition is going to critique some aspect of your design, that is an excellent item to demonstrate as part of your prototype (assuming your competition is wrong, of course!).

Develop a test plan. Be thorough in developing a test plan. First of all, develop a list of tests you intend to run. This list should focus on demonstrating how your solutions meet the customer’s requirements. Next, prepare a topology map of your test environment, including any specialized testing equipment that you will be using. Finally, prepare (as with the pilot) a script for each demonstration you will be performing.

Purchase and configure all the necessary equipment. Once you know exactly what you intend to demonstrate, you can go about acquiring the necessary equipment.

Practice the prototype demonstration. No one likes surprises during a presentation. Make sure to practice your prototype demonstration so that everything will (hopefully) go smoothly.

Conduct final tests and demonstrations. Be sure to gather all relevant data during your tests. For example, you may use a protocol analyzer to place a load on a network segment and then gather buffer or utilization statistics from the networking equipment on that segment. Be thorough in gathering information about all aspects of your prototype. Use the guidelines from the section “Overall Health of Existing Network” in Chapter 4 on the current network to show how your prototype has resolved these issues. Those guidelines are:

• Ethernet segments should not exceed 40 percent network utilization.

• Token Ring segments should not exceed 70 percent network utilization.

• WAN links should not exceed 70 percent network utilization.

• Response time should be less than 1/10 of a second, or 100 milliseconds.

• Broadcasts/multicasts should not be more than 20 percent of overall traffic.

• On Ethernet, there should be no more than one CRC error per one million bytes of data on any network segment.

• No Cisco router CPU utilization should exceed 75 percent.