Once Upon a Time…

The day had come, the auditors had approved the evaluation procedure, the team was assembled and the coffee was made. It all started with a click; a click as the padlock on the tender box was unlocked and the various tenders put on the table. Exactly as planned, they were distributed to the members of the team, each of whom read the summaries of one or two before the formal process of evaluation was to begin.

Coffee was poured, pages burned, a few notes were jotted on note pads and the clock could be heard to tick. Occasionally, a comment about one of the responses was made to the others. But what happened next was anything but scripted.

“Wow”, Mike, one of the evaluators, suddenly exclaimed, “has anyone else looked at the Widget proposal?” Seeing no nods, he continued, “quickly, everyone better have a look at this!” and all the others soon gathered around Mike. “Look, they have offices in 23 countries!” he exclaimed, pointing to the covering letter.

“They spend 9% of profits on R&D!” Alice said astoundingly.

“Yea, and they have 16% market share of the large system educational market in the American state of …” Colin almost shouted.

“But look at this! It’s open, web-based and non-proprietary!”

“Wow, and it supports voice over IP!”

“Golly gee! And it was awarded the best of show medal in the Western Tasmanian state fair in 19 …”

“And they are talking here about a partnership!”

“Oh, but get this, XYZ has just installed the Widget and thrown out the Fidget!”

“Well, we can forget the Fidget proposal.”

“Not just the Fidget, forget the rest, this is obviously the one we’ll be buying!”

And with that and the other tenders returned to the tender box, the whole team were eagerly going through the various brochures included with the two copies of the Widget proposal, oohing and aahing occasionally when they read various sections of the bid. That was until, …

… the alarm clock went off and the person having this dream woke up.

Tendering is the core of many an acquisition process. It has a history that long predates IT and, to the chagrin of many in IT sales and marketing, it shows no signs of going away.

Companies usually issue RFTs (requests for tender) and RFPs (requests for proposal) for good reasons. Although there are cases in which an RFT is required by policy even though the manager is determined to buy Brand X, this is very much the exception. In most cases, RFTs are issued because the buying organisation wants to determine which product or service is the best fit for its requirements, for the best price. Provided the requirements have been gathered systematically and methodically, and the specification is a well-written articulation of these requirements, the process of tendering is arguably the best means of determining how well each potential solution meets the organisation’s overall package of requirements. More importantly, it enables the organisation to determine how well the proposed systems meet these requirements ‘as specified by the organisation’, not as each contending vendor portrays them in a presentation.

This is best illustrated with an example:

Over the last 25 years or so, just about all PABXs have implemented the office telephony feature ‘group call pickup’. This is certainly useful, but to be really useful, the said feature must, if two or more extensions in the one group are ringing, pick up the one that has been ringing the longest—but there are still some PABXs that don’t do this. Comparing brochures would identify which PABXs support ‘group call pickup’ but only by specifying the actual requirement in an RFT would you identify those which perform it properly.

As part of the tendering process, the buying organisation will construct an evaluation table with one column for each bid, and rows (perhaps even hundreds of rows), one for each required capability. Each bid will then be evaluated against each of the required capabilities to determine compliance, non-compliance or partial compliance, with these individual outcomes entered in the table. Capital and recurring costs will typically be compared by calculating the net present costs (NPC—net present value without the minus sign) of each bid. Selection, possibly following visits to reference sites, will be made based on compliance with weighted criteria and NPCs.

Most readers will readily understand this, but there are those vendors who appear to be determined to frustrate this process by omitting some required information, peppering their response with superfluous information and providing a response in a format other than that specified. Evaluators will have several bids—perhaps very long bids—to go through and they want to be informed, not dazzled.

Worse are bids of dubious accuracy, or those claiming compliance without acknowledging a score of constraints and assumptions necessary for anything approaching compliance to be realised.

The following are some brief examples I have experienced when dealing with RFTs:

One response claimed compliance for a feature which, although planned, was still two years away from being released in a future version of the system! As a result, I added a set of compliance statements with precise definitions to my RFT template.
I’ve received a bid in which supervisor was repeatedly spelled “suppervisor”, so a ‘required’ was included in my template that the response be spell-checked. I’ve been told too many times about some so-and-so who replaced brand X with that company’s product, that I now expressly forbid such citations. After all, somewhere else the opposite will have occurred.
I’ve had tenders proposing the model A, but included compliance statements that their bid “complies with the model B”! So I added to my template a specification of the schedule and specified that compliance statements apply to what’s in the schedule, not what’s in their catalogue.
In one project, a particular vendor’s statements contradicted what that same vendor had written to me for an article I wrote a few months prior; when questioned, the vendor stated that it was acceptable to lie to journalists. If anything, this underscored the importance of having a tightly written RFT specification and not relying on advertising material. It also gave me a new disrespect for that vendor and the persons involved.
The most extreme case was a response to a multi-component RFT in which the compliance statement for every single clause in the predictive dialling section was: “partially complies.” The system even supposedly “partially complied” with a requirement that it be powered from a 48 volt DC supply! The more appropriate response would have been “perhaps, but we don’t know”. Of course, that vendor was asked to provide correct responses which took more of their time, as well as wasting mine and the client’s.
One tender I wrote included, in addition to specifications for an IVR system and CTI software, complete IVR and CTI application designs. Most tenders priced their implementation, but one proposed 60 days worth of joint application development (JAD) sessions during which they would design the applications! They might have been doing something else associated with joints when writing their response! But because we’d tendered, other bids’ pricing was more appropriate.
Also irritating are those vendors who can’t help but wax lyrically about features of the system that the organisation has not included in the RFT. Whenever a vendor prepares a response to a tender that does not seek whatever capability their marketing departments are most keen to push, they inevitably come to the assumption that this is because the tendering organisation is unaware of it. Just as inevitably, they’re wrong. No matter how keen marketing is to trumpet this or that capability, if it hasn’t been sought, it is not required.
Perhaps the most odious behaviour is the dummy spit by a vendor who has chosen to not respond to an RFT. Choosing to not respond is, of course, a perfectly valid course of action, but to claim to be “too busy” to reply to the RFT (so would they not be “too busy” to do the work if they won the job?), or that they’ve recently made some large sales (who hasn’t, and, after all, how recent it recent?), or to object to the RFT itself (because it hasn’t been written for them) but that we should attend a demonstration and just buy their system, tendering process notwithstanding, is really beyond the pale. Again, fortunately for that client, compliant responses from other vendors ensured choice and a successful outcome.
Of course, vendors are not the only ones who sometimes try to undermine a tendering process. There are those persons who are determined to buy Brand X, but who go through a tendering process for form sake, and there are consultants who write RFTs for which one brand always seems to win. At least these can be spotted by the astute vendor. Then there are those, often government departments, who have money in the consulting budget but not in the capital budget. Requirements are gathered, an RFT is issued, responses are evaluated, and that’s it.
And then there are those tender documents which are so badly written that the organisation (and vendors who attempted a response and are still talking to them), spend months trying to sort through the bids to achieve a selection.

Nonetheless, buying organisations are sometimes incompetent, but rarely devious. For all its challenges, tendering remains the pre-eminent process for acquiring major systems. And as long as vendors attempt to bamboozle the market with hype, obfuscation and misused terminology, buyers will continue to use tendering to procure capabilities they actually need.

Stephen Coates is the author of the reports computer telephony integration: from the internet to the desktop, in europe and Computer Telephony Integration: from the Internet to the Desktop, in North America. The report covers all aspects of CTI including standards, application integration, applicability to call recording, predictive dialling, audio call recording and internet integration, licence and application development costs, forecasts for future development by product category, and a glossary.