ITP Techblog

Over the past few years I've seen an increased public sector focus on producing better tender documents for ICT projects and designing procurement processes that are likely to lead to better results for government. However, it is still relatively common for standard ICT precedent agreements to be attached to the RFP at the last minute in order to meet the "good practice" guidance in the Rules of Sourcing that proposed terms and conditions should be included in RFP documentation.  

When a last minute call for a contract to attach to an RFP comes in, finding a precedent that is truly "fit for purpose" can be extremely challenging. This is particularly true if the customer is open to a range of different solutions and implementation methodologies for the project (COTs versus bespoke, cloud versus locally hosted, waterfall implementations versus agile) that may require quite different contracts.

Attaching a "standard" precedent can sometimes be risky:

• the contract may contain a number of "red herrings" for potential respondents - eg equipment warranties and title clauses where there is no equipment being provided, detailed implementation processes that only reflect a waterfall approach, clauses that grant ownership of any new IP in the customer even if the solution is multi-tenanted. Red herrings can lead to confused (or confusing) proposals and could potentially put potential suppliers off responding at all;
• depending on how red the herrings are, there could be an impact on pricing if the respondent feels it is forced down a route that does not match how it operates its business.  A generic template which gives an impression that the customer has a preference for a particular solution or approach (when it in fact doesn't), could also impact on how the respondents pitch their responses - potentially twisting their preferred approach to deliver what they believe the customer wants rather than playing to their strengths.  Alternatively, some respondents simply choose to essentially ignore the contract - providing no or limited comments and hoping to negotiate better terms later;
• the precedent, particularly if it has been around for a while, might not include detailed provisions about the things that may really matter to the customer (eg whether the supplier can use open source code in significant bespoke developments, how data back-ups are addressed).

There are of course a range of options to address the challenge. A few common options we see are:

• early market engagement processes to work out what solutions might be available and help the customer to refine and identify what it is looking for before issuing an RFP;
• issuing a standard precedent (often in the form of a master agreement) but including instructions and commentary to respondents to give them guidance as to what parts of the precedent the customer anticipates may need to change and highlighting where the customer has some flexibility depending on the chosen solution; and
• issuing high-level contract principles that set out the basic terms the customer would expect to apply regardless of the nature of the project and/or solution chosen.

The contract principles approach can be particularly beneficial if the customer anticipates that it may wish to select a supplier, such an offshore provider or public cloud provider, who may insist on using its own standard terms as a base. In such cases, it is often a good idea to also ask respondents to the RFP to provide any supplier terms that the respondent would propose (without any customer commitment to use them) and to require the respondent to explain in its response how any inconsistencies between the supplier terms and the customer's contract principles would be resolved. This can also help avoid the surprisingly common nasty surprise where the supplier late in the process (often once selected) provides additional "mandatory" supplier terms (eg supplier or third party user licences that must be executed for the customer to receive the solution).

Whatever the approach taken, if the customer knows when it issues the RFP that the draft contract or contract principles may not quite fit the bill, it is important to leave sufficient time in the process for redrafting and negotiation. While it can be frustrating to select a supplier and then have to spend more time than you'd hoped tied up in contract drafting and negotiations, a robust contract reflecting the way the parties actually intend to work and the solution that is being provided is generally worth the time and effort.