Writing an RFP for a data project without collecting unusable bids

An RFP is not a longer brief

A requirement brief states what you need built. An RFP states how you intend to buy it: how responses are formatted, what has to be attached, how the bids will be scored, and what happens between submission and award.

When bids arrive unusable, the cause is usually a blank in the second document rather than a weak vendor. A bid that cannot be compared, an attachment that does not exist, a price that cannot be normalized on any common basis — each of those is a field the RFP left out, and the cost is paid at evaluation time when the schedule is least forgiving.

The fields, and what each blank costs

The list below is the commercial content of the RFP, separate from the specification it encloses. Each entry names a field and the consequence of omitting it.

• A response template with one line per cost component. Without it, bids arrive in incompatible shapes and the comparison becomes an exercise in reconstruction.
• The unit you will pay on, defined in terms of your acceptance procedure. Without it, each bid prices its own definition of a unit and the numbers cannot be compared.
• The acceptance procedure you will apply. Without it, quality is a matter of opinion at delivery, and the argument happens after the work is finished.
• Required attachments: annotation guideline, consent text, a quality report from a past project, a subprocessor list by category, and a redacted delivery manifest. Without them you are comparing proposals, which are written to persuade, instead of evidence.
• A sample task using your own material, with a stated deadline. Without it, the first evidence of annotation quality arrives after the contract is signed.
• The contract terms you will require: rework allowance, re-collection terms, change pricing, cure period, and data handling. Without them, every bid prices a version of the project that will not exist.
• Evaluation criteria and their weights. Without them, the award looks like a price decision whether or not it actually was one.
• The timeline, including a question deadline and a submission deadline. Without it, questions arrive as private conversations and some bidders end up better informed than others.
• An explicit out-of-scope section. Without it, scope arrives through the bids and becomes a negotiation instead of a boundary.

Publish the evaluation method, including weights

Disclosing the criteria and their weights changes how vendors bid, and the change is useful. Providers who cannot meet a heavily weighted criterion tend to withdraw rather than submit a bid they know will score badly, which shortens the evaluation for everyone.

Two statements belong in this section. First, that the lowest bid is not automatically the winner, with the reason stated. Second, that a bid missing a required attachment is non-responsive, so an incomplete submission is rejected rather than completed through follow-up questions.

The weights you publish should be the weights you use. If the evaluation ends up weighting something else, the next RFP will be treated as decorative, and vendors will bid to the process they believe you actually run.

Run the question window in writing

One shared channel, questions and answers visible to every bidder, and a deadline after which answers stop. This is not bureaucracy. It is what makes the comparison valid. When one vendor receives a verbal clarification about the delivery format and another does not, the two bids are responses to different documents.

Keep your own answers versioned alongside the RFP. An answer that contradicts a clause in the specification is a specification change, and it should be published as one, with the same version discipline the brief gets.

What to require as attachments, and why each one

Attachments do the most work in an RFP, because they cannot be written by a proposal team in an afternoon. State in the RFP what happens if an attachment is missing, and apply that rule to every bidder, since a single exception teaches every vendor that the list is negotiable.

• The annotation guideline. It exists or it does not, and a description of it is not a substitute for the document.
• The consent text from a recent project, redacted as needed. This answers more about the rights chain than any assurance ever will.
• One quality report from a past delivery: what was sampled, what failed, and what was done about it. A provider with a real process has one on hand, and a provider without has a paragraph about a quality culture.
• A subprocessor list by category, with a change-notice process attached to it.
• A redacted delivery manifest, which shows whether records are kept at the file level or reconstructed from memory when someone asks.

The RFP that attracts one bid

A short field of bidders is sometimes a signal about the market and sometimes a signal about the document. Three checks are worth running before publishing:

• Every requirement is either a need or a habit. Requirements that specify a tool, a team structure, or a working method narrow the field to providers who already match your assumptions, and that narrowing is usually invisible from the inside.
• The sample task is sized so a serious provider can complete it inside the deadline without dropping other work. A task requiring a week of unpaid effort selects for providers with slack, which is not the same as providers with capability.
• The submission deadline is long enough for a provider to read the specification, ask questions, and write a considered response. Very short deadlines mostly select for pre-written proposals.