The UC RFP: The Devil You Know Vs. The Devil You Don't KnowThe UC RFP: The Devil You Know Vs. The Devil You Don't Know

When evaluating voice and UC project proposals, keep an open mind when weighing valued existing relationships against the potential of new ones.

When problems crop up with premises and cloud procurements and implementations, the issues often center on a mismatch of client expectations and a new or unknown vendor's execution (and obligations). That leads some to believe that dealing with an imperfect but familiar someone or something is wiser than aligning with someone or something that might be worse.

This "devil you know" principle can apply to almost any situation, but what does it mean for voice and UC projects? The answer lies in the responses to the following questions:

1. Has the client articulated and effectively communicated its requirements to the vendor? My consulting practice has been involved in a number of recovery projects where the original RFP (before we've gotten involved) has resulted in vendor responses that are impossible to normalize. In other words, the client can't make a decision because vendors have proposed solutions that represent their different interpretations of its specs (kind of like some protocol standards). I would categorize this situation as the client's fault. The recovery project requires a new RFP and, sometimes, input from a new batch of vendors that are more appropriate to the project goals.

2. Does the vendor have enough experience with projects of similar size and complexity? This one is interesting in that an inexperienced vendor may propose a solution and schedule that has little likelihood of success but seems to have cost or other advantages over other proposals. In my experience, an incumbent vendor rarely falls into this situation (the notable exception being carriers that churn their account teams frequently, thus losing tribal knowledge of the client). This situation is mostly the vendor's fault, though the client has some shared responsibility in not vetting the proposed solution sufficiently.

3. Are there dependencies that haven't been discovered or revealed? (This is perhaps a subset of #1 above.) I see this occur frequently, with both parties having some level of responsibility. Some examples include:

• Cabling and power issues (client responsibility)

• Networking issues, ranging from PoE to QoS support (client responsibility)

• Networking issues – multicast support (primarily vendor, secondarily client responsibility)

• Number porting (primarily vendor, secondarily client responsibility)

• Lead time (vendor responsibility)

• Personnel changes (both)

Some clients will assign more value to a strong, long-term personal relationship than to a competitive vendors' product portfolio. This may be the right way to go for a client that perceives great risk in going with other solutions and partners. On the other hand, if the existing relationship has problems, the RFP process will likely favor a new vendor. Likewise, if an existing vendor's current product offering is severely lacking in functionality and/or pricing value, building a new relationship may be the right course of action.

As with many of these situations, a decision often comes down to the relationship between client and vendor. Is there mutual trust and respect in the relationship? Does the client believe the vendor will take care of the issues that will undoubtedly arise? Is there an opportunity to establish a strong relationship with a new vendor? I've been fortunate in the past couple of years to work with several open-minded clients that have valued existing relationships as well as the potential of new ones.

In general, if the incumbent vendor has been taking care of business – investing in the relationship as well as product portfolio – then my clients tend to favor remaining with them. On the other hand, if the incumbent has failed to adequately invest, new vendors are sought.

Which devil is right for you?

"SCTC Perspectives" is written by members of the Society of Communications Technology Consultants (SCTC), an international organization of independent information and communication technology (ICT) professionals serving clients in all business sectors and government worldwide.