Asking for an impossible combination of features in an RFP is a sure path to disappoint. And yet every week I see this in VOIP/UC RFPs.
Presence status = Busy (facing ethical debate – is it wrong to say "yes" to a question the asker doesn't understand?)
In my current role every week I receive UC/VOIP RFPs that ask for features and functions that are not available from any vendor!
Many times, the "ask" that is most problematic is from organizations looking to leverage Microsoft Office Communications Server (OCS) on the desktop as the soft phone and want all the features and functions that OCS Enterprise voice provides but want to combine these features with call control from a more "traditional" PBX.
Here's a recent example of two requested soft phone minimum requirements:
- "Integrate with Microsoft Office Communicator 2007 R2 (MOC) client to provide soft phone functionality. All calling functionality should be performed in OCS and not require the use of 3rd party interfaces."; and,
- "Remote soft phone operation must be equivalent to OCS Enterprise Voice mode".
The only way to meet these requirements is to actually use MOC as your soft phone!
Let's be clear once and for all, you only get all of the features of OCS Enterprise voice when OCS is providing the call control. You cannot use OCS as a full-functioned soft phone while using another PBX (Cisco, Nortel, Avaya, Mitel, etc.) as the primary call controller.
As much as people would like to choose two vendor solutions, put them together and get the superset of features, this is not how things work. See the Integration Myth for more details.
For further clarity:
- Cisco CuciMOC which integrates with Microsoft OCS only uses OCS for instant messaging and presence. Any of the OCS Enterprise voice features are not available when using Cisco CuciMOC.
- Avaya AES which integrates with Microsoft OCS only uses OCS for instant messaging and presence. Any of the OCS Enterprise voice features are not available when using the Avaya AES solution.
And neither Cisco CuciMOC nor Avaya AES solutions are supported by Microsoft.
Both CuciMoc and AES solutions are solutions created independently by Cisco and Avaya respectively using the publicly available APIs Microsoft provides to extend OCS. With both Cisco CuciMOC and Avaya AES, OCS is not participating at all in the call control so you get none of the OCS call control features. And while both Cisco CuciMOC and Avaya AES do work, neither the Cisco CuciMOC nor Avaya AES solutions are guaranteed to continue to work as OCS is upgraded; in fact, there are many signals that neither is likely to work with the release of OCS 2010, currently called Communication Server 14 (CS14) slated for Fall 2010 release.
Once again, because Microsoft neither supports Cisco CuciMOC nor Avaya AES integrations, Microsoft makes no attempt to test these solutions as new patches or releases are made available – and a more pessimistic person might even suggest Microsoft would like to "break" either of these two solutions.
Because Microsoft OCS 2007 R2 mostly provides the key voice functions of a PBX and because Microsoft CS14 provides all of the voice functions of a traditional PBX (plus lots of other UC functions), sharing call control between a Microsoft "PBX" and another PBX makes limited sense – it is either impossible or virtually impossible to get this to work in a "deeply" integrated fashion.
Would you put both a Cisco PBX and an Avaya PBX in the same office? (Likely not.) And if you did, some users would be connected to the Cisco PBX and would use Cisco IP sets while other users would be connected to the Avaya PBX and use Avaya IP phones. The two PBXs would be connected to each other via an internal SIP trunk so that a common dial plan could be used.
This, Direct SIP integration, is exactly the type of integration that Microsoft OCS R2 supports and CS14 will continue to support. With OCS integrated to another PBX via Direct SIP, some users use OCS endpoints (which can include OCS IP sets!) and some users use the other PBX vendor's IP sets. You do not try to give a user two "phones": an OCS phone and another IP set.
The specific integrations supported by Microsoft are always listed at the site http://www.technet.com/ucoip. Note that Cisco CuciMOC, a Cisco CUPS integration, an Avaya AES or Avaya SES integration are not on the list (and thus are not supported by Microsoft.)
The only PBX that Microsoft supports in a "deeper" integration manner is the Nortel CS1000 and this is only supported using Microsoft OCS 2007 R1 (released October 2007) not the OCS R2 release (released February 2009).
So, here we are then.
Customers would like to leverage their desktop investment in Microsoft OCS and their PBX investment and ask for integrated solutions between Microsoft OCS and other vendor PBXs that are not supported and do not provide the features customers think they do.
No Microsoft supported integration solution allows shared call control between the current version of Microsoft OCS and a Cisco or Avaya or Mitel or other PBX.
Of course, if you are a customer, you can ask for the impossible in your RFP. Or you can hire a consultant (who doesn't know any better) to help you write an RFP that asks for something impossible!
Just keep in mind that sales professionals are trained to say "Yes" or "Comply" to each and every RFP ask because customers have trained them that "telling the truth" is a quick way to disqualification. (This presupposes that sales professionals have enough experience to know the correct answer – which is often not the case.)
Instead, my advice to customers is to ask for what you really need based on having documented, prioritized business requirements. (For more thoughts on documenting your business requirements see Werewolves and UC.)
And perhaps while you are listing your requirements, consider only making "mandatory" the requirements that truly are mandatory for your business.
Presence status = Free (from guilt having said what others either don't know or choose not to say.)
Have you had to respond to RFPs asking for an impossible list of mandatory requirements? How did you handle your response?
If you are considering issuing a UC or VOIP RFP, do you really know what current UC solutions can deliver and what they can't?