Collaboration Solutions

2 Posts authored by: johndal

It is becoming more usual for customers to have a “Bake Off” of sorts and pin Cisco against competitors to win the business.  In some cases, we lose what we thought we had won; but in others we win business that is rare to win.


Regardless of the outcome, we often build robust, customized and complex environments to show off our stuff.  Everything from utilizing video on iPads, to implementing wireless TelePresence.  Regardless of what we develop, we always deliver the best and most innovative solution we can. The confusion amongst customers, and even some of our own in Cisco or AS, comes when we win the business and want to deploy our solution to the greater organization.


Many customers have the impression that we have built the solution withinthe POC, and therefore can simply expand the existing POC infrastructure to meet the demands of the global enterprise.  While on the surface this seems logical, Cisco’s methodology, experience and best practice states otherwise.  A POC (even when it is used in Pilot form) is simply built to show what is possible if chosen to undertake a greater effort. The greater effort which is to deliver that solution to each and every employee within the customer's organization.


The question begs to be asked; Why can’t we simply scale it?  The answer comes in several parts:


1.     Requirements – While the POC has likely captured requirements from a particular Line of Business (LOB),or potentially even technical requirements given from an RFP, we have yet to discover what is truly required from an end-user perspective globally.  It is necessary to capture the requirements from the global organization to properly design a complete solution.  For example: Are there particular call coverage requirements for various LOBs? Will this dictate different phone models? Are there requirements such as call reporting or call recording? Are there 3rd party devices we need to integrate with such as paging systems, speaker boxes or voice recognition systems? Does contact center functionality exist? Etc…  Failure to capture all the requirements of the solution will leave you redesigning throughout the deployment along with delays and a flurry of upset end-users.


2.     Design – In order to properly scale to capacity and ensure the solution is supportable; documenting the High-Level and Low-Level designs is required.  These designs also lead to the ability to create a final BOM.  These design documents are additionally instrumental in your ability to test the solution and work out any of the kinks... I mean features


3.     Testing – By now you have gathered many more requirements and you solution has evolved. You have more phone models, integration with 3rd parties and many more changes from your original POC.  Ensuring you build proper test labs and validate your design and solution is critical to the success of your rollout.  If the customer doesn’t plan to build their own labs, utilizing Cisco services such as CE Test is essential.


4.     Support – Now that we know what we’re building, it’s time to setup a proper support organization to operate it.  While the processes may already exist in the customer’s organization; it is very unlikely that the tools and resources do. Ensuring you have the right UC specific tools and skilled resources is critical to support your solution.  And as you can guess, they both take months to establish and put into place.


5.     Training – You can perform every single function and task perfectly, but if your end-user doesn’t know how to use the solution, they hate it.  Avoid running into this issue and stop thinking, “It’s just a phone.”  You are fundamentally changing the way an employee communicates with other internal employees as well as with customers.  Build a proper training strategy, plan and content to ensure they have all the information they need to make the best use of the new solution.


While there are more reasons to ensure you segregate a POC vs the future production solution, I hope you see the major reasons why they are dissimilar.  In following Cisco’s PPDIOO model and utilizing our own best practices regarding UC deployments, you are sure to make your rollout, and more importantly the customer, more successful with your new solution.

I remember not to long ago where we focused on technology first, and presenting it to solve a particular business need. For example TelePresence being put into a room, and the customer using that to solve appropriate business issues or needs (ie traveling, saving travel costs). This view of technology still exists in most industries today.

We’ve transitioned to a solutions based approach and now look at the business need first, and seeing what technologies we can offer (or even modify) to resolve that business problem. Take Cisco’s own implementation for example. We wanted to make our employees healthier and have better access to health personnel. While historical solutions may have been to open a series of clinics or have Doctors on-site, we took advanced technology and put it to work. Soon after, we used Cisco TelePresence technology to connect employees with remote medical personnel with the ability to see and interact with them and even integrating medical devices  for a real-time medical diagnosis for many issues.

There are certainly hurdles in this type of thinking and a required strategy to overcome them. For example:

  • Obtaining buy-in to different uses for technology – Many people, especially those who do not like technology, may resist change and not embrace the different uses of technology. We must understand, and help them understand, that this solution may not be for everyone, but can benefit many.  There are many people that are not comfortable with using TelePresence to see medical personnel, but there are probably an equal amount of people that prefer it to going to a doctors office and waiting in a waiting room (then a smaller waiting room) for what seems like forever. (Those Home and Garden magazines are only so interesting)
  • Being able to think about out of scope applications – We often think of a specific technology as “fit-for-purpose” appliance. We need to get ourselves away from that and think about what else can we use that technology for. Or even, how can we enhance this technology to use it for a business problem.

If we can see doctors remotely using technology, imagine what applications TelePresence and other Cisco technologies can be used for.  I strongly believe changing the way we interpret technology vs business problems can create unthinkable opportunities. This out of the box thinking can certainly challenge us, and even make us feel that some things are too far fetched, but presenting the impossible leads to true innovation. As Albert Einstein said, “If at first an idea is not absurd, there is no hope for it.”  I feel it is today that some absurd ideas can become fascinating realities with the use of advanced technologies that exist today.

Filter Blog

By date:
By tag: