Entropy is defined as a lack of order or predictability, or, in this context, the natural tendency of things to go from a state of order to a state of disorder.

The exponential growth of technology has companies scrambling to move to new services with the hope that VOIP, or UC, or WebRTC, or the latest flavor of BYOD will solve their communications problems. In the old days the scramble had companies moving from Centrex to PBX, to private networks, to remote modules, to TEM packages ... well, you get the idea.

Voice services have, historically, had a high level of reliability. This has led many who are not familiar with the technology to assume that because voice services are reliable, they must therefore be simple. This leads to a further assumption: Because it's simple, anyone can do it.

Well, maybe not.

While deciding which new telephony solution to acquire can be a daunting task (see my previous article 10 Mistakes to Avoid When Replacing Your Telephone System), getting it installed properly is a different challenge. During the sales process, our clients are often told that the vendor will take care of everything and the installation process will be easy. If only...

As consultants, we have acted as project managers on behalf of our clients and have been involved in hundreds of installation projects. While each project is unique, here are some tips for avoiding issues that we see most often.

It's true--a Request For Proposal (RFP) process can take a lot of time and effort. So when does it make sense to go through the effort?

1. When you are making a complex purchase, an RFP will help you organize both yourself and the vendors who are bidding the products and/or services you plan to obtain. Putting your requirements in writing up front helps you to decide what capabilities are essential and what is optional.

Many organizations use a Request for Proposal (RFP) process for procuring goods and services. As an independent consultant, I have written many RFPs and evaluated even more responses (see "Do You Really Need an RFP? Because It's Really a Pain..."). The process offers a mechanism for providing large amounts of information that, when done properly, helps the buyers to evaluate and compare options. It is, in effect, a job interview.

Responding to an RFP can require a significant amount of effort from a vendor; sadly, we see proposals in response to RFPs that guarantee immediate elimination from consideration. Here are some of the biggest mistakes to avoid when responding to an RFP:

Many managers rate managing and negotiating contracts on the same level as getting a root canal or walking barefoot over hot embers. I don't remember meeting anyone who has said "Contracts--my favorite thing!" But they are a definite fact of life, so here are a few thoughts on things to be aware of when dealing with contracts.

Part 1: Managing Existing Contracts
You should have a way of tracking your existing contracts so that you are not caught by surprise when they expire. Contracts for services can have murky start dates. Sometimes they are based on when the vendor countersigns the contract; other times they may begin when service is delivered or when it is first billed. Often, vendors can't produce a copy of your contract, so if you don't have a copy of the countersigned document, the contract expiration date can't always be determined. Sometimes vendors tell customers what the expiration date is, but when pressed for documentation they have no way to prove the accuracy of their assertions.

Selecting a new product or service and its supplier can be a long process: A lot of information is exchanged, items are negotiated, and promises are made. The agreement is finalized through a contract, and this is a time where there is a relatively high risk that these customizations may be lost.

Almost every contract contains a phrase that says, in effect, "The only language that is legally binding is contained within this agreement. Previous discussions, writings, and promises are void." If you sign the vendor's standard contract, without making changes, you may give up a lot of leverage and a lot of previous effort.

As a consultant, I am often asked, "Which system is the best?"

That's kind of like asking "Which automobile is the best?" The answer, of course, depends on what you need it to do. Do you need great gas mileage, or to carry a lot of stuff (covered or uncovered?), or hold a lot of people? Will you be driving off-road? Do you need speed? The list goes on.

Any organization that is considering a change in technology takes into account the cost of the new solution in comparison to the cost of the current solution. It is easy to identify the costs associated with the new technology (either the upfront purchase cost or the monthly cost of the service). But there are other costs that are often not recognized up front. Here are some areas that you should consider when deploying a new solution:

Communications technology goes way beyond the desk phone.
As you deploy new capabilities, you may be supporting mobile devices--both phones and tablets. You may have to provide resources to address security issues and support for these devices, as well as the billing for them. Unified messaging (voice mails in email) can impact the storage of your email application. In addition, voice mail messages that reside in email could become part of legal discovery and must be addressed by a message retention policy. New applications such as presence must be supported, which may involve additional training for users. Collaboration tools such as conferencing and document sharing must be managed and supported like any other resource. Video is moving to the individual devices such as desktops and tablets; as this traffic increases, it could impact LAN capacity.

The growth predictions and enthusiasm of today's hosted services marketplace reminds me of the CLEC (Competitive Local Exchange Carrier) environment in the late 1990s. New companies were springing up everywhere, offering local and long distance services as a result of the deregulation mandated by the Telecommunications Act of 1996. The legislation had the goal "... to let anyone enter any communications business -- to let any communications business compete in any market against any other."

New offerings hit the market, and the landscape became cluttered as new and existing companies competed for customers. Many companies began putting fiber in the ground and hardware in Central Offices to build their own networks. Sound familiar? Today I did a Google search on "Hosted VOIP" and there were over 9 million results.

It's easy to complain about the phone companies. And it's ironic that, as "communications" companies, it's so darn hard to communicate with them.

In all fairness, they are struggling to address changes in technology and in behavior while still meeting their obligations to make a profit for their shareholders. Networks are migrating away from copper to fiber, from wired to wireless, and from circuit switching to packet (IP) switching. ILECs (Incumbent Local Exchange Carriers) are caught between requirements to support legacy networks and the need to invest in new technology.

Many times, the project plan created by the vendor’s project managers is not complete in scope. It does not address all of the tasks required of all the involved parties.

When I work on a project that involves replacement of an existing telephony system, the equipment vendor typically assigns a project manager to the installation. In most proposals, there is a section that covers the installation process and how the vendor's project manager will ensure that the system is installed successfully. Rainbows and butterflies will abound.

What impact do the ongoing Mitel/ShoreTel acquisition developments have on an organization’s communications systems procurement?

I'm working on a project in which the client will be acquiring a new UC system. It's done the due diligence and narrowed the field to three contenders, one of which is ShoreTel. Last Monday it hears the news that Mitel made an offer to buy ShoreTel and even though the company's board has since refused the bid, the looming question remains: What impact does this news have for organizations that are considering the purchase of a ShoreTel system?

Our office building is comprised mostly of small businesses. Recently, I encountered two employees of the insurance company across the hall wandering aimlessly in the hallway with lost expressions on their faces. As soon as they saw me, they eagerly inquired, "Is your Internet working?" Ours was, theirs was not. They said they weren't able to do any work when their Internet was down, and they remained in the hallway apparently hoping that somehow the connection would magically be repaired.

This week, I was on a three hour flight on a plane without Wi-Fi. A lady sitting in my row complained that she was unable to get any work done on the plane due to the lack of an Internet connection.

As consultants, we see a lot of demonstrations as we work with our clients to find the best solution for their needs. Most of these are not at an Executive Briefing Center; they are done "out in the field". Typically the system is presented at a location that is local for the client by people whose jobs are not centered solely on system demonstrations.

Here is a true story of three demonstrations that were given to our client. The client had a committee of 8 people (a combination of IT staff and business users) who were tasked with making the decision. After issuing an RFP and evaluating responses, they had narrowed the field down to the top three contenders who were asked to present their systems. Each company was provided with the same agenda outlining the topics that the committee wanted to cover, along with a time frame for each topic indicating the relative importance to the committee.

In my No Jitter post last week, I talked about the importance of the product demonstration from the vendor perspective, explaining how a demo can make, or break, a deal. Today I'm flipping the table, taking a look at the production demonstration from the enterprise perspective.

As part of a product selection process, many organizations ask top contenders to demonstrate their systems. Should you happen to attend such a demonstration for communications technology, do you know for what you need to look? It's best to be prepared so as not to get lost in any fluff.

A recent article by Kevin Kieller took a look at problems that can emerge with an RFP (Request for Proposal) that is not well thought out in advance. He advises that before issuing an RFP, organizations should make some key decisions and have specific requirements agreed upon.

This is excellent advice.

I was recently on a call with a client and an industry analyst, and the client asked if end user training would be necessary when the new communications technology system was implemented. To my surprise, the analyst said, "No." The theory was essentially that the new system should have a user interface that is easy to use and, like a smart phone, users should be able to figure out how to use it on their own, without training.

While I certainly agree that systems should be easy to use, I think that the smart phone analogy is faulty. Smart phones are an individual tool; they are not necessarily part of an eco-system. Yes, you can install apps that increase interaction with a selected group of your BFFs, but that doesn't make it the equivalent of a corporate communication system.