I’ve procured and administered a handful of procurement frameworks on Jisc’s behalf over the years, and a lot of the language and accepted practices of public procurement are familiar to me (drummed in by colleagues in our excellent procurement unit). However, I’ve been struck recently that for a number of our members, when we invite them to complete an invitation to tender (ITT) for one of our frameworks, such as the dynamic purchasing system for procuring public wifi services, it may be the first time they’ve had to write in this particular idiom. Hence this short guide.
The purpose of an ITT is to describe exactly what you want to buy and to elicit responses from the supplier that give you enough information to judge whether they will supply a good solution and be a good delivery partner.
Background
In your ‘background’ section, you must set the context, and you have to keep reminding yourself that the bidders don’t know things that you take for granted. If later in the ITT you are going to ask them to describe how their solution will integrate with your network, you have to provide them with some details and diagrams of that network here. This will probably need to be suitably edited to remove unnecessary detail that might prompt a security concern, such as the IP address of routers. Similarly, if you are going to ask them to confirm that their solution has sufficient capacity, you need to offer some usage projections for the life of the solution based on your experience of your campus. Basically, for every question you ask them in subsequent sections, you need to reflect whether there is any background info that you have that would make it easier for them to answer fully that you could add in here. The more relevant detail you provide here, the fewer clarification questions you may get from the bidders, and ultimately the better design of solution you may be offered.
The bulk of your ITT consists of statements for the bidder to respond to, that can come in two flavours, a mandatory requirement or an informational requirement.
Mandatory Requirements
These are the nuclear option in your ITT. If you ask for something in a mandatory requirement (MR), the bidder must be able to provide exactly what you asked for. If they can’t, you are forced to throw the rest of their bid away and they cannot win the contract. Mandatory requirements are therefore graded purely on a pass or fail basis; you can’t assess how well they do whatever it is you asked for, or compare between bidders and decide which does that thing better or with more features. The language is typically direct and forceful to express this: The bidder must confirm that the proposed solution is capable of <X>.
If you write a too-narrow MR, or make assumptions about what kind of solution they might offer and phrase it with that in mind, you may find yourself forced to reject an otherwise excellent solution. For example, if you are sourcing a network system that will be used by minors, you might be concerned that it has to be firewalled from undesirable content on the internet. You might use an MR to specify that the bidder’s solution must integrate with your existing firewall (which you would have described in your background section, knowing you’d ask this question), or you might perhaps have a requirement such as the solution must be capable of implementing the site blacklist as published on the PREVENT website at a known URL. But you should avoid, for example, assuming that the firewall would be implemented as a router access control list just because that’s an approach that you are familiar with and describing it as such in an MR, because that might exclude an arguably better solution based on alternate technologies.
Generally, you are better off pairing an MR that describes at a high level the functionality that must be present with an informational requirement (IR) that gives you the opportunity to ask for further details.
Informational Requirements
IRs will typically form the bulk of your ITT. They give you the chance to ask for details of approach and implementation, and require you to offer a marking scheme so you can indicate how well the bidder’s response meets the requirement you set. Those marks will help guide your eventual purchasing decision, and can also be used to give an indication of the relevant importance you assign to different aspects of the solution. You should make your IRs as specific as you can, to avoid bidders going off on a tangent and providing information you don’t need, but keep it focused on the area you are addressing in that IR; it’s seldom helpful to mix questions about multiple facets of the bidder’s proposal in a single IR.
Taking the firewall example above, you might end up with:
- MR1 The bidder must confirm that their solution is capable of implementing firewalling rules.
- IR1 The bidder shall describe, using diagrams where relevant:
- how the proposed firewall solution would implement the blacklist as published by PREVENT at <URL> (5 marks);
- what logs will be held (and for how long) of firewall operations (3 marks); and
- the mechanism(s) by which the customer can change firewall parameters in real time (5 marks).
It’s a quirk of procurement rules that you must give maximum marks within your marking scheme to an answer that fully meets the requirement that you set out; you can’t leave ‘headroom’ marks for an even better answer that does everything you asked for plus even more that you didn’t mention.
It’s not just structure
This blog addresses the formalism of structuring the ITT language; it doesn’t really tell you what you should enquire about. How will the solution evolve with time to accommodate changing needs? How does the bidder see GDPR duties being divided with the customer? Could you introduce charging next year if you wanted to? All I can suggest is trying to anticipate the headaches that a future version of you might wish you’d avoided at this stage.
For expert advice on our frameworks, you can always speak to our team procurement@jisc.ac.uk.
Summary
The key ingredients of a well structured ITT that gives you the best possible chance of getting good bids in for consideration should include:
- a background statement that provides all the relevant detail a bidder might need about what you are seeking to purchase;
- a limited and highly selective handful of MRs that address only the most vital essentials of a solution that you can’t live without and are phrased in a general way open to a range of approaches;
- a comprehensive set of IRs that address every different facet of the proposed solution that you want information on (alongside their marking scheme to allow bidders to judge their relative importance to you).