Tenders, RFP (Request for Proposals), RFQ (Request for Quote) plus other various names, are all a way for an organisation to conduct a buying process with an extensive list of requirements, with the aim to level the playing field. For the most part, certain elements of Tenders can be counter-intuitive to building great software. In many cases, they need the buyer to know exactly what the end product will be. Furthermore, the buying process can require the company submitting the tender to spend large amounts of time with a very low chance of success unless you follow a few principles.
Government departments are a classic example of an organisation that needs to produce Tenders. There is a fiduciary requirement when spending public money that the purchasing process is transparent and allows all suppliers to compete on a level playing field. These can be very time-consuming and expansive documents, they can also limit contact with key stakeholders and decision-makers.
Why is it a problem for software consultancies?
Most Tenders have a few things in common when it comes to software. They can be very rigid and can be structurally counter-intuitive to the Agile method of building software. If Tenders have rigid rules and look for a fixed price, Agile processes would be affected and if the Tender was won, hours of time would be consumed by the processes to alter the agreed-upon framework.
What is the problem for sales teams?
Firstly, there are never any guarantees of winning any work regardless of the efforts taken to win business, but Tenders often invite significantly more competitors than you would generally need to compete with.
Secondly, while Tenders are written documents that are supposed to level the playing field - this is not always the case. When a supplier and vendor relationship is formed, there are 1000's of data points that are factored in - reputation, past client success, culture, displayed skills, communication style, internal disciplines, plus many other intangible items. Tenders often don't ask questions where the relevant strengths of a supplier can be demonstrated, you can only answer the questions that are asked. Therefore, they can favour an incumbent supplier - or suppliers with an intimate knowledge of the client.
Be selective with tenders you reply to
Tenders are time-consuming for a sales team and generally need a process like a Spec Review performed at no cost in order to complete a response and, as a result, the decision to submit a tender needs to follow a few key principles:
- Do you have a pre-existing relationship with the key stakeholders, or does the tendering process allow you to build a relationship where you cannot only complete a document but some of the intangibles are taken into account in person-to-person meetings?
- Do you have developers on the bench that you can commit to upskilling on documentation and working on Tenders whilst not on client work?
- Do you know the competition? - Although organizations will generally be guarded about information about the competitors, if there are any more than 4 known competitors (and the above no. 1 point about the relationship is not strong enough to make the vendor feel that they will be naturally shortlisted) do not respond. You are probably only there to make up the numbers.
- Does the tender fit Agile methodologies? - Look carefully at the process to make changes and how detailed the scope is. Also, see if the client is open to a Spec Review to fine-tune the estimates and scope. If Agile development is not possible, the Tender is not a good fit.
Tenders can be a waste of time, with low-skilled assessment by purchasing people who can overly focus on cost and a narrow set of requirements. Only go for them if you have a good chance of winning.
