What not to include in your collaboration ecosystem

When organizations make the mistake of using a 'product-first' approach to UC&C, a number of mistakes can be made – with long-term consequences.

mobile devices tablet laptop computer hardware smartphone

Unified Communications and Collaboration – a term we first started using in the late 1990s – is the only technology I know that has been "launching" for 17 years. While the explanations for that phenomenon are plentiful, the sad reality is that many manufacturers actually like the market confusion. Without a completely agreed and established framework for UC&C, vendors can still release products with the claim that they fit within it.

I've explained many times before that the only way to implement a successful UC strategy is to look at and manage it from a holistic stance. As "technologists," we all have to put aside our tendency to become bogged down in the technology/features and instead focus on our people and their desired organizational outcomes. This bottom-up approach differs from technology "provide and pray" in that it establishes a specific blend of needs that is unique to every organization. This is then applied across the organization using whatever blend of technologies best match the now verified (not assumed) needs. The process also has the side benefit of driving adoption by engaging and "hearing" users and their needs, and creating end-user champions.

Regrettably, some manufacturers and vendors hate it when I say the above. Pausing to validate needs slows the sales cycle, and detailed examinations of how solutions meet or miss meeting those needs could cause organizations to realize that some products may not be as good as manufacturers say they are.

Unfortunately, the reality is that -- for political or other reasons -- some organizations are pressured to look at technology first instead of people first. When that happens, it is often difficult to separate the most valuable solutions from the least. Here are some simple guidelines that organizations can follow to help cut through the hype:

  • Is the product easy to use? Without a lot of fanfare, the collaboration space has moved from demanding that everything works to demanding that everything works simply. The days when users would have referred to instructions or attended detailed classes is over. Everyone can use a smartphone or tablet – and those products have set the bar for everything else. If an expensive room-interactive display or your desktop GUI requires more than the most cursory introduction then forget it – people won't use it, at least not in numbers high enough to produce a decent ROI.
  • Is the product compatible? Compare every potential hardware and software offering to your personal mobile phone. If a feature or requirement would be intolerable on your phone it should be intolerable on your organization's enterprise-grade device. "Can I call/interact with any other brand of system or just your brand?" "Does it cost me more to call other brands of systems or is every call treated interoperably and equally?" "Does your compatibility strategy require waiting on industry adoption of a new or siloed feature, or does it work with all other systems today?" "Do I have to change the design/implementation of my existing systems for them to be compatible with yours?" These are critical questions that immediately dismiss what is still sadly a large number of offerings.
  • Is the product scalable? As you go from buying 2...to 20...to 20,000, does the product offer management capabilities that will enable you or a partner to perform remote management and diagnostics? Is it compatible with AD or other standard schemas? Or does it require you to use a new one – or even worse, is enterprise management not even offered? Does it produce metrics on utilization, successful/failed connections, etc. When vendors promise "inexpensive, simple, self-service" but your management strategy requires you to dispatch someone for diagnostics, then you haven't gained very much.
  • Does the product really meet the application's need, or is it like using a screwdriver to hammer nails? One of the biggest problems of a technology-first approach is that it tends to make us want to use our selected square pegs in every hole, round or otherwise. The fact that the solution "works" doesn't mean it's the right one for the job. There's often a long road between just working in an application and truly meeting the need by creating an exceptional experience.

Until we technologists stop looking at products first, we'll always be susceptible to the hype-cycle of new entrants that claim to meet our enterprise's needs in a revolutionary manner. It is up to us, as the experts to look past the hype and really understand the value and limitations of each solution.

Copyright © 2015 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022