How Do You Know If You’ve Missed a Tender Requirement?

Tender packs have an irritating ability to hide things in plain sight.

The insurance requirement is in the contract schedule. A certificate appears once in an appendix. The specification contains an operational commitment that never makes it into the response questions. A clarification issued four days later changes something everybody had already written down.

None of this requires a particularly devious buyer. It requires only several documents, several authors and enough time for one instruction to drift away from the place where a bidder would naturally look for it.

This is why “we read the whole pack” is less reassuring than it sounds. Under the Procurement Act 2023, the buyer's requirements can sit across the tender notice and associated tender documents, including the specification, contract terms and procedural requirements such as deadlines, word limits and information the supplier must provide.

A tender is therefore less a document-reading problem than a reconstruction problem. Reading every file is only half the work; the other half is making sure that every obligation survives the reading and finds its way into whatever working model the bid team actually uses.

Requirements come in different forms#

One reason requirements disappear is that bidders mentally put rather different things into the same bucket.

The distinctions are consequential. Conditions of participation concern whether the supplier has the relevant legal and financial capacity or technical ability. Award criteria concern the tender being offered. Procedural requirements govern the process of submitting it.

A company can understand the service perfectly and still miss something affecting its eligibility. It can be perfectly eligible and submit something procedurally defective. Or it can submit a compliant tender while misunderstanding what actually earns points.

The first job, then, is not merely collecting important-looking sentences. It is working out what each of them does.

Searching for “must” will only get you so far#

Keyword searches are useful. Must, shall, required, minimum, failure to provide and their relatives will uncover plenty.

Unfortunately, requirements are not obliged to announce themselves so politely.

A scoring table can establish a minimum without using any of those words. A footnote can alter what counts as acceptable evidence. “The successful supplier will…” may create an obligation after award rather than at bid stage. A pricing workbook can reveal that an apparently optional service is expected across every lot.

The better unit of detection is the obligation itself: what has to be true, supplied, demonstrated, avoided or done — and by when?

Keywords help find those obligations, but they do not define them. Searching a 200-page pack for must, finding 73 occurrences and filing the remaining 199 pages under apparently harmless is not a particularly robust review method.

Keep the source attached#

Suppose somebody extracts the following requirement:

That may be enough for the first conversation. It deteriorates rapidly afterwards.

Was it in the specification or the conditions of participation? Does it apply when the bid is submitted, before award or at contract commencement? Did the original wording specify Cyber Essentials, or Cyber Essentials or equivalent? What evidence did the buyer actually request?

A requirement detached from its source slowly turns into bid-team folklore. Each retelling preserves the conclusion while shedding a little more of the qualification around it.

The record does not need to be elaborate. It just needs to retain enough information to get back to the original evidence.

For example:

The useful fields will vary between procurements, but the principle is stable: keep the requirement, its location, its type, its timing, the expected evidence and any unresolved uncertainty together.

That becomes particularly valuable when somebody later asks, “Are we sure this is mandatory?” Instead of reconstructing the reasoning from memory, the team can return to the source in a few seconds.

It also makes contradictions much easier to handle. Two unsupported notes are opinions. Two traceable requirements pointing in different directions are a problem that can actually be investigated.

Read across the pack, not simply through it#

Once the requirements have been extracted, reading the entire pack again from page one is not necessarily the best use of anybody's afternoon. A second pass becomes more useful when it moves across the documents rather than through them in sequence.

Some comparisons are particularly productive:

• specification ↔ response questions
• conditions of participation ↔ evidence you actually possess
• pricing workbook ↔ stated scope
• contract terms ↔ assumptions already made during drafting
• clarification log ↔ requirements already extracted

Another useful approach is to ask what each document contains that would surprise somebody who had read the others.

That tends to expose the oddities: a mobilisation period mentioned nowhere else, a different insurance figure, a mandatory attachment, a requirement applying only to one lot, or an innocent-looking sentence that turns a nice-to-have into a minimum.

None of these requirements needs to be obscure. The difficulty comes from their distribution. Something can be perfectly legible on page 47 and still be functionally invisible to a team working primarily from the response questions on page 12.

Some requirements deserve more attention than others#

Finding a requirement and understanding its consequence are separate jobs.

A useful register should eventually distinguish between things that can stop the bid, things that can cost points, things that require evidence and things that simply need to inform the response.

A rough triage might look like this:

This matters because discovering thirty unresolved items shortly before submission is not particularly useful if nobody knows which three could actually kill the bid.

Under the Procurement Act framework, those consequences can differ substantially. A supplier that fails a condition of participation cannot ultimately be awarded the contract. Procedural breaches can permit a tender to be disregarded, while published pass/fail award criteria can disqualify a tender where the assessment methodology provides for it.

The register is therefore doing two jobs at once: preserving what the tender says and helping the team decide where attention belongs.

Then there is the moving-target problem#

Even a careful extraction can become wrong.

During a competitive procurement, contracting authorities can modify the terms of the procurement. Cabinet Office guidance specifically notes that supplier clarifications may reveal that tender documents need to be amended. Those changes can affect requirements, conditions of participation and award criteria.

A requirement register should therefore be treated as a live representation of the procurement rather than a souvenir from the day the documents were downloaded.

When a clarification or amendment arrives, the useful question is not merely whether anybody has read it. It is what the new information changes elsewhere.

A revised deadline is simple enough. A clarification that alters the interpretation of a specification may affect an existing requirement, a response already being drafted, an assumption in the pricing model and perhaps a decision made several days earlier.

Replacement files deserve the same treatment. A folder containing Pricing Schedule.xlsx, Pricing Schedule v2.xlsx and Pricing Schedule FINAL.xlsx is not yet a version-control system, however optimistic the filenames may be.

What a good review leaves behind#

By the time drafting becomes expensive, the team should have a reasonably stable account of what can make it ineligible, what can make the submission non-compliant, what will actually be scored, what evidence has to be supplied and when, and what has changed since the procurement was first published.

That sounds like information the tender pack already contains, and usually it is. The work lies in preserving the relationships between those pieces of information as they are pulled out of several documents and handed between several people.

“Cyber Essentials required” is easy to write down. Whether it is required from every bidder, whether an equivalent is acceptable, when it must be held and which document established the requirement are precisely the details most likely to disappear afterwards.

A good review therefore produces something rather more useful than evidence that somebody has read 200 pages. It produces a smaller, traceable representation of the procurement that the rest of the bid team can actually work from, while retaining enough of the original pack to check its conclusions when something looks wrong.