10.3 New Vendors

< Day Day Up >

Some project requirements may dictate that you seek out a new vendor for those deliverables. This would likely be driven by one of two conditions:

An incumbent vendor may be unable to meet your dates or certain product or service specifications, including price and availability.
Incumbent vendors may not be technically qualified or experienced with a particular deliverable.

Before getting involved in a detailed look at bringing a new vendor into the fold, I must surface a very old IT axiom, which alleges, "No one ever got fired going with IBM." I do not interpret this as disrespectful toward Big Blue, by the way. Instead, the message is that reaching out to new vendors or products can introduce a series of challenges that may:

Require long lead times
Introduce risk not previously experienced
Take lots of patience to resolve

First, let us put a fence around this conversation by stipulating a few conditions:

You need to go to a new vendor because incumbent vendors cannot satisfy one or more of your project requirements.
The service you are trying to locate is more than a procurement scenario.
The potential deliverables are complex and largely customized.
Your company probably lacks the training and experience with the product one normally looks for in the aftermath of testing and implementation.
Let us also put aside the procurement process itself for the moment.

The level of risk associated with selecting a new vendor is directly proportional to the complexity of the goods or services you intend to procure from them. The uniqueness of the product or service should be considered as well. As an example, a few years ago, our engineers wanted to connect two storage area networks (SAN) located in sites that were ninety miles apart. These SANs are big disk arrays normally attached to servers using the Fibre Channel (FC) Protocol, which at the time could not span those 90 miles. The engineers came up with a product that converted the protocol from FC to Internet Protocol (IP), so the data packets could safely traverse the distance. At the other site, the IP datagrams were then converted back to Fibre Channel and stored on the alternate site SAN.

The somewhat frightening news was that only one vendor supplied such a product, and it was still in "beta" (i.e., preproduction) state. This, in essence, raises the risk to the next power, by sole sourcing a new technology not even in production and installing it in a huge wide area network (WAN) to provide site-to-site data mirroring for disaster recovery (DR). We insisted on pretty rigorous testing and kept a very close eye on the implementation before turning it into production.

< Day Day Up >