Tenders are a waste of time, effort, and money. There, I’ve said it. Every business I’ve been involved with when selling a product turns tenders away (unless there has been involvement prior to the tender being released). Why?
What is a Tender?
A “tender” is a a process by which a company that is going to market in order to find a solution to a business challenge or to assist in growing the business, asks a number of vendors to submit multiple pieces of documentation in order to compare, contrast and eventually select and implement a solution presented by one vendor.
The process starts with the company performing internal requirements analysis. Typically, the tender process is championed by one internal stakeholder who then asks each department that will be involved in using the end solution to submit a list of desired functionality. This internal stakeholder then compiles these responses into one document and often a spreadsheet, the latter being kept internal for the process of later comparison. The document itself is normally a set of questions in the nature of “Can your system perform X? What is the process to perform Y?” etc. These questions are aimed at covering off each of the desired pieces of functionality that the departments involved have requested. The resulting document is then either issued on a website and available for any vendor to respond to, or the champion handpicks a few vendors to participate in the tender.
Each vendor must then compile a response document answering each of the questions (there could be dozens and dozens) in as much detail as possible, including use cases, screenshots, and anything else they feel would help win the business. The vendors then submit these responses back to prospective client. The client reviews (this is a problem in itself), updates their internal comparison spreadsheet and more often than not, a few shortlisted vendors make the next step of meeting with the prospect to discuss moving forward.
There are a number of different types of “tenders” too. One tender can follow another where the responses submitted by vendors vary in length and detail. Two common types of “tenders” are Request for Information (RFI) and Request for Proposal (RFP).
Who is Involved?
There are many people involved in the tender process. From the internal stakeholders that collect the requirements, department heads and end-users that are interviewed to discover their requirements, the accounts departments and primary decision maker(s) – this could be a CEO or the board of Directors for example. Then there is every one of the vendors and the people they employee to qualify, and document a response to the tender request, as well as the key sales representatives that perform most of the interaction. Remember, only one vendor will possibly win the tender and often no vendor is selected at all!
In reviewing the people involved, we’re looking at least seven different groups of people all of at least one person. Then add at least another two groups of people for each additional vendor involved.
That is a lot of time, effort and money wasted.
Where is the Problem, Exactly?
While this process is riddled with time consuming busy-work, the problems originate at the beginning. The first step in the process is to perform internal requirements analysis. The call goes out to each department and end-users to submit their “needs”. And that is the problem. Too many people misconceive a business need versus a personal “nice-to-have”. A business need is the true cause for looking for new software or application. It is summarised by completing a sentence such as: “We require new IT functionality to assist the business with…”. This can then be broken down into further detail. These are the true requirements. As soon as the requirements analysis ends up in the hands of the end-users, or even the group managers, the business needs are drowned out by each person’s claim of “It should do ‘this'”, “We need it to do ‘that'”, “This system needs to talk to that system” etcetera. These are not business needs. These are individual people’s wishlists to build a behemoth software application that solves nothing, but looks pretty. All these personal agenda’s then clutter the comparison matrix and mean that no vendor will be able to meet every requirement. In the comparison matrix, the weighting (if any) is not evident and skews the judgement of the decision makers, who do not necessarily go into detail on the requirements, but only look at the results in passing and rely on someone else’s interpretation as basis of their decision.
What is the Solution?
So how should requirements be determined? Simple. Start by identifying the root need. First ask yourself, “what if we did nothing, what would be the impact on the business?”. Stop there and perform a high-level a cost-benefit analysis looking at the cost to the business in terms of time (man-hours) and money, taking into consideration the projected state of the business if the growth or problem continues. Compare this to the same analysis when the problem is solved. Now put a dollar value on that difference. This is the budget the business can work with. Identify the key date when latter analysis exceeds the former. This is the deadline for the implementation – be sure this is realistic given the broadness and complexity of the requirements.
Then ask, “Why are we looking into this?” and, “What are we hoping to solve”. With the management team, prepare two short answers to these questions – very brief, less than half a page. This is now the basis for your requirements. Combine these responses with some details about your current business and IT state and you now have a document of no more than three pages, the high-level requirements. Compiling the requirements has taken no more than one day and has taken the time of only a handful of key people. Quick, effective, and inexpensive.
The next step is to go shopping. Pick out a few key words from your description of what the business is hoping to solve and throw them into Google. You’ll find a number of companies that attempt to solve the business problem in varying ways. Do some research, read some reviews from other users. If it reads well, shortlist the company. Don’t end up in analysis paralysis. Shortlist no more than three possibilities. Contact these companies by phone and discuss your project and business state. You should always contact these companies by phone – you will quickly get a feeling for how the company operates by how they deal with your enquiry. And, more importantly, you will experience the communication and interaction that company provides. This is key to the final decision made.
If there is a good feeling from the conversation send them your requirements document and invite them to discuss the project and what they offer in more detail. The vendor will, at this point, perform further discovery of their own. Huge benefit here is that the companies you involve perform their own discovery, using their own time and resources.
The rest of the process is simple. However, do not ask for a trial of the solution. The business will then start to evaluate features and functionality rather than the overall solution to the business need. A demo is advisable, if for nothing else, to get a better understanding of the user interface layout. (Side note – if the vendor has done their homework, the demo will be more of a confirmation of what you already know, rather then showing areas that have never been discussed).
Make sure the solution solves the business need, as already discovered and documented internally. And ultimately, make sure the key stakeholders have a good working relationship with the key contacts at the vendor. It is always amazing to see how much extra assistance the business will get when stakeholders and vendor are considered “people” and “friends”, not “dollars” and “that software company”.
Going to tender wastes time, energy and money of both the business and each of the vendors. Vendors will often turn down a tender request without even looking at it. The key to finding the solution that is right for your business is in keeping things simple. Identify the key business need, find a company that will work with you, not just for you to make that need a reality. The “bells and whistles” are just that, and should not be taken into consideration then making a decision. Throw out comparison charts and spreadsheets and talk to people. A lot more will get done after a conversation than reviewing cumbersome tables for days to decide based on numbers rather than true value.
Have you had experience with “tenders”? What happened? Leave your thoughts below.