Murphy must have been a miserable person, because his law – anything that can go wrong, will go wrong – is one of the biggest IT obstacles for businesses. While promising new technologies may effectively solve a problem in theory, there is always the risk that different applications may not actually work together.

We all know examples of projects that failed miserably due to a lack of interoperability. The company that assumed the latest version of a collaboration app would be compatible within its communications system, because previous versions worked just fine. Or that corporation that bought an expensive new video conferencing system that won’t integrate with email to schedule meetings.And the many businesses that mistakenly believed that any SIP trunking service would work with their PBX.

A former GM of HP Technology Consulting claimed 80 percent of all business communications projects do not reach their potential with only 10 percent being truly transformational. I’m not sure of those exact numbers, but we do know that a very high number of deployments do not live up to the full promise that businesses outline in their Request for Proposal (RFP). How can our industry accept such a high failure rate?

Speaking of RFPs, could they play a role in improving the industry’s low success rate? What if we could make some changes to that process to help ensure more effective deployments. Sometimes a little more upfront effort can pay off in multiples over the long run. Adding a requirement for independent testing of the solution could save businesses significant amounts of time and money while avoiding embarrassing tech failures. And it can be as simple as adding a question to the RFP that asks, “Has the solution been certified as interoperable by an independent test lab?”

It seems so easy and yet so few RFPs include this strategic requirement. That’s partly because testing in general is often seen as an end-of-lifecycle task meant to prove that a technology does indeed work as planned. By elevating testing to the forefront of the process — in the early planning stages –businesses can quickly weed out any solutions that are not compatible and focus on a better short list. They can increase their odds and accelerate their time-to-delivery.

And why shouldn’t a business require proof that a solution will actually work with its current system? That onus should be on the business selling you the solution. In fact, if interoperability testing is not a requirement spelled out in the RFP, businesses take on the risk and responsibility for the solution themselves.

Getting back to Murphy’s Law, the best way to avoid potential issues is to fully prepare ahead for pitfalls and worst-case scenarios. Adding an interoperability testing requirement into the RFP process is a simple way to increase your chances for successes and keeping that pesky Murphy at bay.

This article originally appeared on Telecom Reseller at http://bit.ly/1nGjJ8v

# # #