Disagreeing Takes Time
Disagreeing Takes Time by Kevin Kieller
Dismissing a product or service is quick. Disagreeing takes substantially more time. Unified Communications by its very nature is complicated, multi-faceted and requires the investment of a reasonable amount of time before you can agree or disagree effectively.
According to dictionary.com, one definition of agree is “to come to one opinion or mind; come to an arrangement or understanding”. To arrive at a common understanding implies that some work or effort was undertaken so that both parties came to share similar views. Accordingly, to disagree requires equal work or effort to conclude that you do not share similar views.
Unfortunately, in many assessments of unified communication solutions, I see more “dismissing” and very little true “disagreement”. Quick decisions made not on the basis of well-informed opinions; but rather, based on partial truths and generalizations. Perhaps ironically, I contend the world would be a better place if there was more disagreement, as this would at least imply that both parties spent time trying to understand the different options or solutions and, only after spending this time, they found they did not share the same view.
Here are some of the common quick dismissals that can lead you down the wrong path:
The Cost Dismissal
Solution X is much too expensive! I have been told this on many occasions, however, when I ask the follow-up question, “So, how much will it cost?”, I am then told “I don’t know but it is very expensive.” Is very expensive $1, $100,000, a million dollars, a billion dollars? You must to take the time to attach budgetary costs to all the viable options being considered.
In my experience performing an “apples to apples” cost comparison takes time and effort and this is likely why people choose to simply label an option as “too expensive”. Different vendors have different licensing models and it is important, and sometimes challenging, to make sure you are applying the same, reasonable, documented assumptions to each cost estimation.
Even after you determine the one-time and on-going costs for a solution, you need to ask yourself two important questions before dismissing a solution as too expensive:
-
Is the difference in cost between the solutions
material? (Materiality is an accounting concept representing whether the amount is significant in the current context.) Here’s an example: imagine solution A costs $1 million and solution B $2 million. If the solution happened to serve 10,000 users and was expected to last 5 years (amortization period), then the per user cost differential is only $20 per year. I’ve done comparisons where a CIO has told me that a $3 million difference was not material.
-
Is the cost of the solution eclipsed by the estimated benefit to the organization? Granted this gets a little tricky and many business cases over-estimate savings; however, spending $x million to save $y million where y > x, depending on the time frame and opportunity costs (could the $x million be invested some else to garner even better return?) could make this spend a good decision.
Security Dismissal
New solutions are often subjected to an increased, and sometimes unfair, security burden. When evaluating new solutions, involving the team responsible for corporate security is the right thing to do, however, it is important to understand the levels of security that current systems enforce when planning for a new system.
For instance, several times I have had people express concern related to Microsoft Lync’s remote security because it allows a VPN-less connection. (This objection was more prevalent before Cisco too adopted this approach with the newest Jabber clients.) The truth is Lync as a voice solution by default encrypts all media and signaling. This is a higher security standard than almost any existing voice implementation.
It is great when a new solution improves security. I would suggest that as part of evaluating any new UC solution, you also document the current security policies. Striving to raise the security “bar” is a good thing; striving to implement perfect security is both impossible and impractical. Dismissing a solution because its security is perceived as not perfect is simply wrong.
New solution dismissal
Just because a solution or technology is new does not mean it is unreliable or unsuitable.
If a solution is simply “new to you” or new to your organization, you should not simply dismiss it. And yet, this wrong-headed approach often pushes organizations to continuing to invest in existing platforms simply because they are existing, even when this is detrimental to the organization.
Being familiar with a platform increases the ability to support it and certainly reduces the on-going support costs. “Supportability”, the ability and cost to support, should definitely be a criterion when evaluating solutions; however, a solution should not be dismissed entirely simply because the “in-house” team is unfamiliar with the platform.
A new platform or new technology should be validated, perhaps through a pilot, certainly by identifying and talking in detail with references. Being on the “bleeding edge” or “leading edge” may be fine as long as you understand the risk and take the appropriate steps to mitigate these risks. In addition, the cultural of some organizations makes adoption of newer technology either encouraged or discouraged.
Properly evaluating options takes time and effort. “Pruning” options that do not meet true mandatory requirements is important however dismissing options too quickly, because of the above reasons or any other unsupported perceptions, increases the likelihood that you end up with the seemingly “safe” but wrong choice. Choosing wrong ends up penalizing the organization.
Please don’t dismiss me but do feel free to disagree in the comments section or through tweets to @kkieller.