MarketWorks working for you in your market

View this newsletter online

by Craig Terblanche

Tenders are the bane of my life. We have worked on both sides of the process in many tenders over the past five years or more. To be clear, the two sides of the process I refer to are before the transaction and after the transaction. A tender is intended to result in a transaction where a large sum of money changes hands for the implementation of some solution. If you're lucky, the money is paid legitimately upon the solution realising the intended benefits. But it really takes more than luck to get this right. Firstly, the requestor usually has preconceived ideas about who they want to get the solution from and what the solution should look like. These preconceptions are seldom legitimate or appropriate leading practice.

This is where The Ugly comes in. In order to ensure that the friends of the requestor can be awarded the tender, they are usually asked to draft the requirements. That way they know what to expect and can influence the solution. We have become quite cynical and selective about which tenders we respond to. With a little experience you can spot The Ugly a mile off:

• The requirements are rigid and biased towards a highly specific solution
• The requirements are totally unstructured
• The tender is published with a very short response window
• The tender is withdrawn and republished
• There is no specific response format
• Questions are asked ambiguously and therefore they cannot be evaluated consistently
• Communication about the tender process is inadequate
• There is no briefing session
• The briefing session is poorly conducted
• Communication in the briefiing session is inadequate
• Email clarification is promised but never arrives or arrives very late
• and I could go on..

Usually a combination of one or more of the above is indicative of the aforementioned prejudice and sometimes even foul play.

The Bad, on the other hand is where so-called professionals are involved and the outcome is still undesirable. To be fair, the transaction advisors (TA) are often set up for failure. This is mostly due to the process being so centered around the transction that the big picture is not considered. Solutions are requested that may or may not have value and the TA is just there to ensure that the solution is acquired, i.e. the transaction takes place. In the worst case, the so-called solution is a specific piece of hardware or software. Oh, how the techies love to put out a tender that is highly specific! It's logical - you must have an elaborate technical specification or you may not get what you want. Ah, but are you sure that you want the right thing? Are you sure you want what's best for the business? And - my worst scenario - are you just asking for this because your CEO read in a grotty magazine on the plane that it's a silver bullet? There are no silver bullets! Never, ever, under any circumstances will a piece of technology solve a problem instantly and without pain or avoid some unintended consequence - never.

This is not to say we should be paralysed and analyse every possibility to the opposite extreme. All we suggest is that CEOs and their peers really need to ask the question, "What is our position in respect of this technology?" before they ask for the technology to be implemented to solve a problem that is ill-conceived. Position Papers are one of my favourite tools (courtesy of Terry White's What Business Really Wants from IT) for establishing the beginnings of a business rationale. If you're going to spend money, please have a business reason for doing so! And please understand all of the business implications of that spend. Or at least understand the basic implications. Information Systems have have interdependent components - the technology is almost incidental. The critical component is People (CEOs understand how important it is to have the right people), followed by Process (What are the people expected to do?) and then Geography (Where are they expected to do this?) and finally Networks or Connectivity (How will they connect, interact and collaborate?) These are simple considerations and I apologise if I'm teaching gran'ma to suck eggs - after all, this is Information Systems 101 material. The trouble is that we forget the basics so easily, especially when under pressure.

Note that because these components are interdependent and they are dependent in some way on their environment, we really are talking about more than a black box when we implement a system. Systems require Systems Thinking, where the main consideration is for the business outcomes that are ultimately desired, rather than a linear objective like Implement CRM. Give this to the techies in your organisation and you'll get a CRM technology with no business approach, rationale and plan for business use and exploitation. This may sound riduculous - after all, a CRM system is intended to manage Customer Relationships. That's a solid business need and system, surely? Well it is, but there are many ways to manage customer relationships and you need to be clear on the outcome and approach that best fits your business needs. If you're not clear, the chances that the technology you apply will happen to meet your expectation are slim to zero. 

As you can see, by the time the poor TA comes on board to enact the transaction, the veritable horse has often bolted.

Enough negativity. The Good should always come first! At the end of the day, anything worth doing comes down to work and anything that takes more than a day takes some planning and thinking about what it is we really want and how to get the best business outcome. Independent advice may be a good start. In order to ensure efficiency and effectiveness you'll want:

• The process to be quick
• The quality to be good
• Fairness and equitability
• Consistency
• Transparency
• Control, in terms of both manageability and, more importantly, defensibility that demonstrates impartiality
• Clarity of outcome, informing a clear decision

As I said, planning your tender is important and here are some steps to consider:

• Once the business rationale and position is clear what is the business case?
• Is the project feasible in terms of the technological, operational and economic implications?
• Are the requirements addressing a whole solution, including all Information Systems components and using Systems Thinking?
• The success of the evaluation process is closely linked to the format of the Request for Tender and the nature and content of the questions themselves. How the questions are asked is as important as what is asked for. If the right questions were not asked, the information on which the decision is based may be incomplete.
• Do we have a clear plan and process for managing responses?
• Do we have a clear plan and process for evaluating responses?
• Have we thought through what is important and agreed weightings for our evaluation criteria?
• Has the security of the responses and the evaluation been catered for? Doing this propoerly is expensive and an information leak can kill the whole process.
• How will disagreements between evaluators or misunderstanding in responses be managed? An indepent arbitration comittee is desirable.

In our experience, simply applying criteria weightings to the sections of the tender and consolidating the scores per vendor gives a slanted outcome. To calculate the value for money factor for each vendor response gives a more meaningful result. Our value model achieves this. With a value for money approach, the pitfalls of the lowest bidder winning because they didn't really think through the solution requirements are circumvented.

Most of the tenders out there today have The Good, The Bad and The Ugly in every respect. This is such an important issue for Government and business to get right that I beg you to start with The Good! Our Value for money model can also be used to develop a proxy for the alternatives to your current or preferred solution. In my next article I'll outline more on "The Good " in Value for Money.