The Teleconvergence Process

The Teleconvergence Process refers both to our perspective and our methodology. It differentiates Teleconvergence from other consulting firms, even other independent consulting firms.  This section carefully articulates the Teleconvergence difference. We expect you to select your professional advisors carefully.  This will help you decide whether to include us among them.

Section Content

Selecting a System – and Getting it Backward provides insight into how most businesses go about making technological decisions – and why things don’t always go according to plan. It is also the introduction to:

The Teleconvergence Approach to System Selection is the same whether it involves a telecommunications system, an international WAN, CRM or supply chain software, or a VoIP hosted service. You should know what we do and how we do it so you can feel comfortable with our results. This is the place to read all about it. Thirdly, in case you were wondering, there’s also….

How Teleconvergence Keeps Up With Developments A solid slice of our approach to technology and our philosophy about change and remaining client-centered.

 

Selecting a System Backward

The Usual Approach is Wrong, Unfortunately

When most organizations begin selecting systems, services, or software to satisfy business objectives, they generally go about it backward.

They begin by researching different vendors and systems. They collect physical brochures or download PDFs.  They read reviews and user comments. They contact multiple vendors who schedule multiple visits or host multiple conference calls and steer the prospective buyer to multiple on-line demos and possibly webinars.

If vendors are local and the prospect is important enough, each vendor will conduct multiple interviews of management and staff.  Each vendor then ultimately submits a bid or proposal, none of which is really comparable to the others.

The prospective buyer, now fully saturated if not precariously overloaded with facts and figures, attempts to make a rational and informed decision and finds he or she simply can't. Why not? Why can't the prospective customer get it right?

The reason is that it's the prospective buyer's process that's at fault, not the buyer. And the reason the process is faulty is because it's been conducted backward.

By beginning with available solutions, the prospective buyer unknowingly omits adequate consideration of actual needs, issues, and conflicts, regardless of whether any immediately gratifying solution adequately addreses the situation.

It's the buyer's fault only when he or she insistently repeats the same process over and over again and expects different results. Feel free to re-read the foregoing to fix the usual process in your mind, then pledge you’ll never do it again. Unless you simply enjoy beating your head against the wall.

Question: How do I avoid these problems in the usual process?
Answer: You can’t avoid them. Instead, you prevent them from happening by changing the process.

Why The Usual process Doesn't Produce the Desired Results

Because different products and services have different capabilities, each vendor asks different questions, the answers to which naturally play to that vendor's strengths. (You may not believe this, but some vital questions may actually go unasked to avoid exposing product weaknesses.)

Similarly, all vendors won't be able to ask their different questions and interview the same employees in the same exact order and encounter the same moods. As a result, the questions asked and the responses given, and especially the information gained by the prospective buyer, will not be consistent from vendor to vendor, from interview to interview, or from day to day.  How could it not be confusing for the buyer?

Further, each potential vendor deliberately monopolizes as much of management and employee interview and on-line time as possible to discourage equally comprehensive attention from being paid to other vendors.  It works.  Most managers and their staff increasingly (and justifiably) come to regard the questionnaires and demos and interviews and rest of the process as intrusive time-wasters.  Employees, especially, spend less time and respond more superficially as each successive session creates greater fatigue. The obvious result is that, again, the information given and received by vendors, employees, and management will not be consistent from vendor to vendor nor from day to day.

Worse, if some requirements cannot be met by the first vendor or two evaluated, then client management, consciously or not, inevitably begins rewording the requirements to make them more easily satisfied. This is not only unfair to the initial vendors, it also prejudices the entire situation because the original requirements become redefined in the later vendors' favor.

So what happens?

The Usual Results From the Usual Process (Again, Unfortunately)

Result 1. The most common result is that the prospect receives great quantities of material and proposals offering widely differing alternatives that may nor may not constitute an acceptable solution because the requirements themselves have become a shifting target.

Result 1A.  At the same time, the prospective customer remembers his or her oft-repeated history of receiving overinflated promises and underwhelming results and doesn’t know what to believe, even when it is understandable.

Result 2. Equally commonly, the prospective buyer ends up with incompatible and non-comparable proposals. It's apples and oranges, yes, but there's also an electric motor and some clothing and... Modern technology indeed presents many, many alternative ways to achieve virtually anything. The prospective buyer just wants to make an informed decision, and is dismayed to realize that he or she has no way to get to there from here

Result 3. And so, being unable to make a valid decision, the prospect (a) does nothing or (b) settles for the least expensive option (and you know what happens then), or (c) goes with the proposal that he or she understands the best, even though it is inadequate and unsatisfactory and clearly doesn't meet the organization's needs.

Result 4. Almost any system decision becomes theoretically acceptable if one lowers one's expectations enough.  However, justifying an unacceptable or inadequate alternative by calling it marginally OK makes it neither acceptable nor OK and the organization will suffer the consequences of that decision for years to come. Or at least until the process is repeated.

Result 5. Each vendor has its own technology and its own evolution strategy that calls for replacing whatever it offers today with something else in a few years, whether it's broken or obsolete or not.  To some degree, most business executives realize that to follow a vendor's strategy, they must also agree to to proceed on the same  route in the same direction, endure delays caused by vendor errors, and agree throughout to head for the same destination.

Always Remember: The probability that any vendor -- even a so-called valuable strategic partner -- has the exact same business priorities, objectives, strategies, and direction as you is precisely zero.

What Can Be Salvaged From the Process? Not Much.

Unfortunately, once a prospect has obtained such a stack of non-comparable proposals, there is very little useful that can be done with them. Teleconvergence has been asked many times to evaluate such collections of mateiral. We've always refused, and for two good reasons.

First, we will doubtless find them more non-comparable than you.

Secondly, just from reading such biased information (which is what a vendor proposal really is and should be), how are we supposed to understand your real technical and operating needs, your financial situation, and your business and strategic opportunities? 

Since we obviously wouldn't know what you need, why should you act on anything we might say? Honestly, would you trust any doctor's second opinion without first undergoing a thorough examination?

At this point you're doubtless thinking, "Surely there must be a better way." There is, and we'd like to describe The Teleconvergence approach to System Selection to you now.

The Teleconvergence Approach to System Selection

Note: This is part 2 of The Teleconvergence Process. If you haven’t already done so, please begin by reading Part 1, Selecting a System – and Getting it Backward.

Introduction

When you see a doctor, it's because you have a specific problem. You don't expect the doctor to give you brochures or to be told about his favorite diseases or the details of her best operations. You really aren’t interested in everything the doctor can theoretically do for you if only you actually had a particular disease. You only care about your real symptoms and your diagnosis.

And that’s precisely what's wrong with the usual system selection process. You care about what you need, not about what the vendor has. The emphasis is clearly in the wrong place: on the vendor's solutions rather than on the buyer's problems. You aren't really -- or shouldn't really be -- interested in the technology, but instead in what the technology can do for you.

Teleconvergence focuses on understanding a client's needs, wants, limitations, time frames, financial constraints, and everything else that will or could play a part in your decision-making process. We want to know not only the business objectives supporting the technological effort, but equally the business processes and reasoning behind those objectives.

Perspective

Teleconvergence helps organizations solve business problems and issues arising from technological change or from the need to be responsive to the effects of such change.

A good deal of our systems practice touches on leveraging technology (including telecom) because the 21st century’s driving business needs are to communicate, cooperate, and collaborate. Our clients must exploit technology to reach their objectives while refusing to become subservient to it. When determining a client’s system requirements, we also note the full range of existing business and human factor issues that must be satisfied, future plans that must be accommodated into the system architecture, and so on.

The Teleconvergence consulting process results in the establishment of longer-term infrastructure at the same time that immediate issues are being addressed. Our perspective, a result of our having done this many, many times, is what adds depth and value to the business cases we make for our recommendations to our clients.

The Teleconvergence Process

It is important to point out that Teleconvergence initially mostly ignores available vendor, system, and technological alternatives, focusing instead on understanding a client's business, technical, and strategic needs. We pay as much attention to your business and strategic objectives as we do to your financial constraints and projected timelines.

In other words, we look at the business and operating requirements first, then the means to satisfy them second.

Teleconvergence has no bias toward or vested interest in any particular vendor or system solution, new or pre-owned, physical or hosted or virtual.  In fact, we have no bias toward any new solution at all. We may end up simply recommending that you keep what you have while showing you how to modify it to satisfy your needs for the foreseeable future.  That's why we work for you and only for you.

Vendors will tell you what you want to hear. Teleconvergence will assess your situation, discuss your alternatives, and then we'll tell you what you need to hear.

Conceptually, it’s really (almost) as simple as that. Practically, though, there’s a lot of work involved.  For the full description of our approach, please read The Teleconvergence System Selection Process in Detail.

Two Final thoughts Regarding System Selection

1. Avoid being locked into a vendor and especially, into a vendor's vision of the future. Each vendor has its own technology, its own evolution strategy that calls for replacing whatever it offers today with something else in a number of years, whether it's broken or not. Or even whether you need it or not.

  • As we say elsewhere, even if a vendor's vision or strategy is valid, that vision cannot and will not be the same as yours, and so it can't possibly take you where you need to go. If that vision is faulty or false, then it simply will not get you anywhere.
  • It's also worth repeating that the probability that any vendor, no matter how valuable a "strategic" partner, has the same business priorities, objectives, and strategies as you is exactly zero.

2. You may or may not need a consultant. You may decide not to retain a consultant whether you need one or not. But virtually every business can benefit from a consultant's perspective.

 

The Teleconvergence System Selection Process in Detail

Step 1. First, we attempt to ascertain and define your real needs in terms of your business objectives, budget, business plan, etc. During this step, we envision satisfying a client's needs as a desired system, software, and/or process that would be capable of achieving a certain set of objectives, if not initially, then in stages. We then determine what the infrastructure must consist of initially to support that system creation activity over the longer term.

This need definition process may or may not include our modified form of business analysis or business process review, called Procedural Strip Mining (PSM) Once we understand your business requirements, we may translate them into conceptual alternatives (independent of vendor or specific technology) that meet your business objectives in order to give you an early understanding of possible operating parameters and financial business benefits and tradeoffs. We may do this multiple times to fine-tune the process and expected results.

Step 2. We proceed in a very natural and practical manner. We identify your requirements as we understand them, prioritize them, place them in writing, and get your agreement that our understanding parallels yours. We will modify the documents until everyone is on board and heading for the same destination.

Step 3. Once the final details have been worked out and we have the client's approval, we then turn those business needs into technical requirements within the context of a business-oriented Request for Proposal (RFP) that we submit to an adequate and appropriate cross-section of potential suppliers. Naturally, the client must approve the RFP before it is submitted.

Why does Teleconvergence submit only RFPs (Requests for Proposal), and not RFBs (Requests for Bid) or RFQs (Requests for Quote)? In our opinion, there are both specific presumptions and inherent bias risk dangers with RFBs and RFQs. You can read about them in Why Teleconvergence submits only RFPs. The business-oriented RFPs that Teleconvergence submits has none of the limitations of RFBs or RFQs, which consist primarily of stipulations and specifications.

With Teleconvergence RFPs, specifications are just part of an entire information package in which we present a client's situation, issues, problems, objectives, and operating issues, and at minimum, an indication of budgetary constraints. We always ask all respondents to point out any area where Teleconvergence inadvertently limits the range of possible responses or alternatives. Finally, we invite each vendor to individually develop the best possible response to the client's requirements and to work with us to optimize it for presentation to the client.

Because identical RFPs are sent to all prospective vendors, they enable all vendors to compete equally to provide the most satisfying overall solution possible. This may involve a one-vendor solution or intermixing technologies, vendors, and systems to enable a best-of-breed approach for the client's specific application.

Teleconvergence inevitably submits one or more necessary rounds of RFC's (Requests for Clarification) to various vendors to eliminate ambiguities and make the submissions functionally comparable. Taking these steps at this point eliminates probability of noncompliance and serious misunderstandings later on.

Step 4. The responses from those vendors who satisfactorily respond to the RFPs and the RFCs constitute the range of realistic alternatives and solutions. Clients thus see one or more optimized approaches in which their needs can be completely or almost completely satisfied.

A client may opt to simplify a solution or to adopt it in stages, but at least the overall solution is known and can be accepted, modified, or declined by the client. Moreover, since multiple responses may adequately satisfy the client's needs, then the client can act on whatever additional "wants" or personal priorities or preferences that may exist.

Step 5. In order to help the client better understand the responses to the RFPs, we then prepare a series of worksheets (operating, strategic, financial, technical, etc.) which we submit to and discuss with the client. Note that we do not just create and submit a report and call that a job well done; some of the work is just starting.

Step 6. We work with the client to narrow the choices, adjust the situation or system parameters as appropriate, eliminate less desirable options, then more deeply investigate the remaining alternatives. We will also modify the original worksheets to show fewer alternatives but more details in order to help the client better weigh the variables and arrive at a decision. During this time, we may also prenegotiate financial terms or maintenance terms, delivery schedules, etc. with multiple vendors simultaneously in order to arrive at total package pricing and total Cost of Ownership (TCO).

Step 7. Once a tentative decision has been made, we work with client counsel to help negotiate agreements, stipulate desired modifications to offered proposals, work on implementation schedules, etc.

Note that Teleconvergence does not normally oversee the implementation of a system. Since one of our functions is to select a competent vendor, in our opinion, overseeing or being directly responsible for the implementation would not only question the competence of the vendor, but effectively require the client to pay twice for the same implementation.

We are, however, frequently retained to periodically monitor the progress of the implementation and verify its compliance with the content of the accepted proposal, as well as to verify the completion of the project before the final payment changes hands.

Why Teleconvergence Only Submits RFPs

  1. There is an inevitable presumption inherent in a RFB/RFQ that the writer both fully understands the company's requirements and knows the best way to meet them. Obviously, Teleconvergence feels we are competent to ascertain and communicate the client's needs. But that's where we draw a very important distinction.
  2. Teleconvergence realizes that each major vendor may have hundreds of engineers with incredible expertise and applications experience with that company's products. These engineers have resolved problems and issues similar to those of any potential customer many times and in many ways. For Teleconvergence to presume that we know any company's products as well as its engineers is a stretch we do not make and a statement of confidence we could not justify.

    On the other hand, Teleconvergence is completely capable of evaluating many companies' proposals in response to our client's RFPs, requesting clarifications of those proposals, and suggesting modifications to those proposals. Teleconvergence routinely engages each company's engineers in fruitful discussions designed to place each company's proposals in the best possible light.

  3. Since our RFPS initiate a dialogue as well as a response, each prospective vendor has ample opportunity to inform us if they believe our RFP unfairly favors a particular vendor. If the statement is valid, we immediately issue a correction to rebalance the playing field. RFBs and RFQs disinvite any dialogue or response other than to the specifications. Errors or inadequacies in the RFB/RFQ generally are not to be challenged.
  4. In a RFB or RFQ the author necessarily not only defines the requirements, but also frames the nature, terms, and parameters of the solution. In other words, the writer of the RFB/RFQ, by postulating the solution, replaces the potential combined knowledge of all the vendors' technical resources with his or her own. Such a tradeoff, in our opinion, is simply not in the best interests of the client.
  5. In any RFP/RFQ the author inevitably risks unwittingly precluding or excluding some responses by specifying the nature of the desired response based upon the author's view of the possible responses and the most desirable approach.
  6. Finally, there's also the risk that the author is biased for or against a particular solution or technology and manifests this bias, knowingly or otherwise, in the RFB or RFQ.

 

How Teleconvergence Keeps Up with Developments

Many Clients have wondered how we (or anyone) can possibly stay on top of all the developments and systems in a particular field or market. We don't know about anyone else, but for us, the answer is simple: we don't.

It’s neither reasonable nor practical to fully keep up with today’s outpouring of new technologies and system announcements. Why be concerned about services or products that may never exist or ever become supported in your local area -- or even anywhere -- by a trustworthy vendor?

Not only is it impossible to reliably distinguish among alternatives that are leading edge, bleeding edge, and falling off the ledge, but there’s usually no reason to climb out on the limb in the first place. Although the early bird risks a lot to get the worm, the second mouse doesn't risk much getting the cheese. Teleconvergence clients do not retain us as consultants to make martyrs out of them. There's no need for them to pay extra for the privilege.

The Teleconvergence approach focuses on a client’s specific needs as opposed to potential solutions to everyone's needs. For example, when possible, we try to determine the technical sophistication and actual needs of a client’s employees. New systems or methods may be a stretch for intended users, but they should never be out of reach.

Modern technology enables organizations to perform previously unthinkable activities, but it cannot determine by itself whether they should. That's why we initially spend much of our time helping clients identify driving requirements and isolate their real priorities. Most clients have a good idea what they want; we help them flesh out how to get where they want and what else they may need once they arrive.

Clients naturally focus on applications that get the job done. While we do that, too, we also strive to create an infrastructure that permits future growth without having to rip everything out and start afresh every five years or so.

Technology is always a means and never the end. If management doesn’t specifically know where it’s going or what it wishes to achieve, then there’s no reason for it to pay for extra baggage like an unquestioning and equally clueless consultant to keep it company.

Teleconvergence must be convinced we can be of help to a potential client before we will even discuss consulting arrangements. How else can we be sure to keep our clients’ business interests first?