How to Write an RFI/RFP for a Drone Detection Radar System

A drone-detection RFI or RFP should translate the approved threat model, site basis and operating workflow into measurable supplier responses. It should not ask vendors to interpret an undefined mission or rely on brochure terms such as “360-degree detection,” “AI classification” or “camera linkage.” Every mandatory claim needs a response field, evidence source, responsible party and acceptance method. Use the parent Drone Detection & Low-Altitude Surveillance Radar Procurement Guide to approve the threat model, sensor architecture and site basis before issuing this document.

How to Write an RFI/RFP for a Drone Detection Radar System

1. Freeze the Procurement Basis Before Issuing the RFP

• Protected assets, surveillance zones and prohibited approach corridors.
• Target classes, dimensions or RCS assumptions, speed, altitude and representative routes.
• Required warning time, operator decision and response workflow.
• Approved sensor roles, external platform interfaces and cybersecurity boundary.
• Site-survey basis, proposed locations, blind-zone assumptions and infrastructure responsibility.
• Factory, field and site-acceptance stages and the data that must be retained.

If these items are not approved, the RFP will collect incompatible solutions rather than comparable responses. Resolve the baseline first, then allow suppliers to propose compliant alternatives with clearly identified deviations.

2. Define Mandatory Evidence and Deliverables

The RFP should state what evidence and delivery documents every respondent must submit. The purpose is not to rank suppliers inside this guide; it is to prevent vague claims from becoming untested contract assumptions.

Do not accept generic statements such as “deployed worldwide,” “AI accuracy above 95%” or “near-zero false alarms” as sufficient responses. Require the target classes, dataset or field-test basis, environment, system configuration, confidence threshold, limitations and named document owner. Evidence requirements should be identical for every respondent and should become part of the technical contract where relevant.

3. Require a Requirement-by-Requirement Compliance Schedule

Each requirement should have a unique identifier and fields for compliance status, offered value, condition or limitation, evidence document, document revision, responsible organization and proposed acceptance method. Do not combine several technical requirements into one yes/no line because a partial response becomes impossible to evaluate.

How to Write an RFI/RFP for a Drone Detection Radar System

4. Separate Product Capability From Project Delivery

A product datasheet can support a response, but it does not define the complete project. The RFP should separately request the radar sensor, server and software, licences, EO/IR integration, external interfaces, site engineering, masts and civil works, cabling, commissioning, training, documentation, spares, warranty and support. This prevents a low equipment price from being mistaken for a complete operational system.

5. Define the Commercial Disclosure Schedule

The RFP should require a complete disclosure schedule so that later quotations can be normalized without guessing what is included. The schedule should identify equipment, infrastructure, engineering, integration, deployment, recurring services, maintenance, assumptions, exclusions and buyer responsibilities.

This guide does not calculate or rank lifecycle cost. It only defines the information that every supplier must disclose. Architecture-specific maintenance, redundancy, spares, support region, downtime consequence and software obligations should be stated with assumptions and evidence; the separate quotation-comparison guide should then evaluate those disclosures on a like-for-like basis.

6. Minimum RFI/RFP Response Schedule

Require every respondent to complete the same schedule. A blank, “TBD” or “supported” response remains an unresolved requirement until a measurable statement, evidence source and responsible party are supplied. The completed schedule creates the common baseline later used for quotation comparison.

7. Control Deviations, Assumptions and Optional Alternatives

Require every deviation to identify the affected requirement, operational consequence, proposed alternative, price effect and acceptance implication. Assumptions should be consolidated in one register rather than scattered across the proposal. Optional alternatives should be priced separately and must not be used to conceal noncompliance with a mandatory requirement.

8. Attach the Documents That Will Govern Delivery

• Approved technical specification and site-basis document.
• Coverage drawing and residual-risk statement.
• Interface control document and responsibility matrix.
• Evidence and submittal schedule.
• Factory, field and site-acceptance test plans.
• Commercial inclusions, exclusions, recurring charges and delivery milestones.
• Warranty, support, software-update and end-of-life obligations.

How to Write an RFI/RFP for a Drone Detection Radar System

9. Define the Evaluation and Clarification Workflow

After receipt, screen every response in three passes. First, identify mandatory noncompliance and missing evidence. Second, issue a controlled clarification log that preserves the original requirement ID and records the supplier reply, impact and closure status. Third, separate compliant baseline scope from optional advantages before price scoring. This prevents a technically incomplete offer from appearing competitive because it is cheaper or more heavily marketed.

Clarifications that change the offered scope, performance condition, responsibility or price should be incorporated into the final proposal and contract annex. Email explanations that are not transferred into the controlled offer should not be treated as binding delivery commitments.

Common RFP Failure Modes

• Using one maximum detection range without a target and operating condition.
• Treating API availability as completed integration.
• Accepting an AI accuracy percentage without dataset, threshold and limitations.
• Leaving masts, civil works, servers, licences or commissioning outside the response schedule.
• Defining acceptance only after contract award.
• Allowing suppliers to respond in different formats that cannot be normalized.

10. Govern the Controlled RFP Baseline

Assign an owner to every requirement, interface and evidence schedule. Issue one controlled baseline to all respondents, log every clarification, and identify whether each answer changes compliance, price, delivery or acceptance. Before award, incorporate accepted clarifications and deviations into the final technical schedule so that the evaluated offer and the contract describe the same system.

Conclusion

A defensible drone-detection RFP is a controlled response system. It gives every supplier the same requirement IDs, evidence expectations, responsibility fields, commercial disclosures and acceptance methods. Once compliant responses are received, the buyer can move to the separate quotation-comparison stage without reconstructing what each proposal actually includes.

FAQ

Should the RFP specify a preferred radar model?

Usually no. Specify the required operational outcome, target set, interfaces and acceptance criteria first. A model may be named only when compatibility, standardization or an approved design requires it.

What evidence is stronger than a brochure claim?

A controlled test report, interface document, coverage drawing, raw-data extract or live demonstration tied to the proposed configuration and stated operating conditions.

When should commercial exclusions be disclosed?

In the initial controlled response. Exclusions discovered during negotiation or installation create avoidable change-order and schedule risk.

Should the supplier response become part of the contract?

Material technical responses, drawings, assumptions, deviations, delivery outputs and acceptance commitments should be incorporated into the contract or its controlled annexes.