Subscribe

Tender trouble

Terry White
By Terry White, Director at CXO Advisor.
Johannesburg, 01 Oct 2013

On average, a medium to large request for proposal (RFP) costs the issuer between R200 000 and R500 000 to prepare. And each respondent sinks about the same amount into his/her individual response. There are usually an average of seven respondents per RFP, so the cost of one RFP is between R1.5 million and R4 million.

So, why are they so bad?

I've been following the Government Gazette tenders for a few years, and on average, 30% of all tenders issued are cancelled. Some basic maths here: government departments publish about 150 tenders per month - about one-third of them above R20 million. Assume 30% of these are cancelled. The cost to the economy is between R25 million and R65 million - per month.

That's not the cost to suppliers, where a tender is successfully awarded - there can be one winner, so three-quarters of the costs of a tender are born by unsuccessful bidders. That can be put down to the cost of sales, I suppose.

And even those tenders that are awarded are filled with errors and fatal flaws. I've seen a 250-page tender for about R25 million, where the requirements were confined to eight bullet points on page 83. All the rest was procurement wordage. I've seen several tenders where the customer forgot to put in its requirements at all! Actually to be fair, it did spell out its requirements, but forgot to give bidders a place to respond in the response templates.

It's not just government tenders that fail to meet a minimum quality standard. I've seen private companies ask unanswerable questions, but the biggest problem is that most questions in RFPs are largely un-evaluable. It's no good asking: "Do you supply MPLS network solutions?" - How will an answer that comes back with a "yes" be evaluated? The failing is in constructing a question without the expected answer in mind.

Tender talk

Let's get to the purpose of a tender. Most people would say it is to choose a supplier that best fits the customer requirement. That's fine, but there are subsidiary factors to consider. The tender must reflect a requirement that fits the organisation's objectives. I've seen a number of tenders that are more of a political statement of intent, rather than an actual requirement.

A few months ago, a company CEO questioned the value and cost of his IT department. The department responded by issuing a tender for its services, to show the CEO that no one out there could do it cheaper than the IT department. I've seen a tender for an "all singing and dancing" solution, where the customer had no intention of contracting for the full scope of services - it was just testing the waters.

Even those tenders that are awarded are filled with errors and fatal flaws.

There are some governance requirements in issuing a tender. I'm not talking about the standard contractual obligations here. The tender must be defensible - in tough times, suppliers are quick to challenge the award of a tender, delaying the implementation, and adding significant costs.

I'll go through the right way to prepare an RFP, and to respond, in later Industry Insights, but here's some thinking on preparing tender documents that may result in fewer cancellations, and in more fair and defensible selection of the best suppliers.

Motivation

Firstly, as Forrest Gump said: "If you're going to do something, try to have a reason for doing it."

Know the business reasons for why the tender is being issued. Secondly, write those business reasons into the RFP document, and make them a contractual obligation. I had a client who wanted an EDW (enterprise data warehouse). When I asked the client why, the response was: "Because the boss wants it." I helped the company rewrite the RFP to include the business reason (a single version of the truth).

Thirdly, let the business reason inform every part of the requirement. Don't ask for an MPLS; ask for a physical network that can run a number of independent virtual networks.

Fourthly, don't specify too tightly - risk will be transferred back to the company by insisting the solution fits its (often outdated) architecture. Let the supplier decide how best it can solve the business problem, while accommodating the company's architecture.

Fifthly, try to ask questions in a way that the response is contractible: "Describe how your... solution will meet our business need" is a much more contractible way of asking: "What do you supply?" (They might supply something that doesn't suit the company's needs.)

Finally, show some respect. I've seen too many adversarial RFPs that assume the supplier is out to rip off the customer. They're not. It's bad business.

Just as issuing a poor RFP is bad business. It's bad for reputation, and bad for the economy.

Share