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.