Defence procurement is one of the most process-intensive commercial environments a software vendor will encounter. The combination of public accountability requirements, national security sensitivities, complex technical requirements, and multi-stakeholder decision processes creates a procurement cycle that operates on timescales and with procedural complexity that bears little resemblance to commercial software sales. Understanding the process — specifically the sequence from initial market engagement through to contract award — is essential for software vendors who want to manage their pipeline realistically and position themselves effectively at each stage.
The fundamental sequence across most Western defence procurement systems is: Request for Information (RFI) → Request for Proposal (RFP) or Request for Quotation (RFQ) → Evaluation → Contract Award → Contract Management. Each stage has a specific purpose, and the strategic actions available to vendors are different at each stage. Confusing the stages — treating an RFI as an opportunity to pitch, or treating an RFP evaluation as an opportunity to negotiate requirements — is one of the most common mistakes vendors make when entering the defence market.
RFI vs RFP vs RFQ: Differences and When Each Is Used
Request for Information (RFI) is a market research instrument used by procurement organisations to understand the current state of the market before committing to a procurement approach. An RFI is not a commitment to purchase — it is a structured survey of what the market can offer. Procurement organisations use RFI responses to: understand the range of available technical solutions, assess the maturity of the technology in question, identify potential vendors, inform their requirements development, and estimate likely costs before drafting a formal budget request.
The appropriate response to an RFI is a substantive, technically specific, honest description of your product's current capabilities and limitations — not a sales pitch. Procurement staff are skilled at identifying responses that oversell and will discount them accordingly. RFI responses that are honest about current limitations but specific about the development roadmap are more credible and create a better foundation for subsequent engagement than responses that claim capabilities that will need to be demonstrated at evaluation.
Request for Proposal (RFP) is the formal competitive tender document. It specifies the procurement organisation's requirements in detail and invites vendors to submit proposals that describe how they would meet those requirements, at what cost, on what timeline, and with what contractual commitments. An RFP represents a commitment by the procuring organisation to award a contract to the successful respondent (subject to the responses meeting minimum quality thresholds), which means that preparing a competitive RFP response is a significant commercial investment that should only be made when there is a realistic prospect of award.
Request for Quotation (RFQ) is a simplified procurement instrument used for smaller-value acquisitions or acquisitions where the requirements are sufficiently well defined that competitive negotiation on technical requirements is not needed. RFQs are common in defence for commodity software purchases, software maintenance renewals, and small-scale consultancy engagements. The evaluation process for RFQs is typically simpler and faster than for RFPs, with price playing a larger role relative to technical quality.
Evaluation Criteria: Technical, Commercial, Past Performance
Defence RFP evaluations typically assess proposals against three categories of criteria: technical, commercial, and past performance. The weighting between these categories varies by procurement, but for software programmes, technical quality typically accounts for 40–60% of the evaluation score, commercial terms (price, contractual risk, payment structure) for 20–30%, and past performance for 20–30%.
Technical evaluation assesses how well the proposed solution meets the stated requirements. Evaluators are typically subject matter experts who score each proposal against a defined rubric. The most common mistake in technical proposal writing is providing generic capability descriptions rather than specific requirements-referenced responses. A good technical proposal takes each stated requirement, describes specifically how the proposed solution meets it, provides evidence (test results, operational references, technical documentation), and where the solution does not fully meet a requirement, acknowledges the gap and describes mitigation. Evaluators who cannot find specific responses to specific requirements will score conservatively.
Commercial evaluation assesses price competitiveness and contractual risk. For software, the price evaluation is typically on total cost of ownership — not just license cost but implementation, training, maintenance, and support costs over the contract period. Vendors who quote low licence costs and high support costs may score poorly on commercial evaluation if total cost of ownership exceeds competitive alternatives. Contractual risk is assessed through the proposed contract terms: warranty provisions, indemnity limitations, IP ownership, data handling, and business continuity provisions are common evaluation factors.
Past performance evaluation assesses the vendor's track record on previous comparable contracts. The definition of "comparable" varies: for large prime contracts, comparable means comparable in scale and complexity; for software component contracts, comparable means comparable in technical domain and security classification. Vendors without relevant defence contract history face a structural disadvantage at this evaluation stage, which is one of the reasons that building a track record through smaller contracts or subcontract positions before competing for prime contracts is the conventional market entry strategy.
Key insight: The evaluation that matters most is not the one on paper — it is the one in the evaluator's mind before the formal process begins. Procurement organisations rarely award large contracts to vendors they have never previously encountered. The purpose of the pre-RFP engagement period — RFI responses, industry days, capability briefings — is to ensure that when the formal evaluation begins, the evaluator already has a positive prior expectation of your capability. A technically superior proposal from an unknown vendor frequently loses to a slightly weaker proposal from a known and trusted one.
Country-Specific Nuances: US FAR/DFARS, EU Procurement, UA DOT-Chain
US Federal Acquisition Regulation (FAR) and Defence Federal Acquisition Regulation Supplement (DFARS) govern US defence procurement. For software vendors, the most important FAR/DFARS provisions are those relating to software data rights — specifically the provisions that determine whether the government acquires unlimited rights to software source code developed under contract. DFARS 252.227-7013 specifies the default government data rights for technical data and computer software; vendors who want to retain proprietary rights to their commercial software must assert them through the "commercial item" designation process. Failing to understand and assert these rights at contract negotiation stage can result in inadvertently surrendering IP that the company needs for its commercial business.
EU defence procurement does not have a single unified framework equivalent to FAR/DFARS. The EU Defence and Security Procurement Directive (2009/81/EC) provides a framework for competitive procurement in the security and defence sectors, but implementation varies significantly across member states. The most important variation for software vendors is in the handling of security requirements: some nations (France, Germany, Netherlands) have stringent national security vetting requirements that create significant delays in the pre-qualification stage; others (Eastern European members) have relatively streamlined security requirements. Understanding the national procurement culture and security vetting requirements of your target market is essential preparation.
Ukrainian DOT-Chain is the accelerated procurement mechanism described elsewhere in this series. Its most distinctive feature — the ability to complete procurement on a compressed timeline through Brave1 pre-qualification — applies specifically to categories of defence technology defined by the Ministry of Defence. Software tools that fall outside these categories are still subject to normal procurement rules, though the tolerance for expedited processes is higher across the board in the current operational context.
How to Write a Winning Proposal as a Software Vendor
Several structural principles distinguish proposals that win from those that do not. First, write the executive summary last and make it decision-ready: evaluators at senior levels will read only the executive summary, and it must stand alone as a complete case for award. Second, mirror the RFP structure precisely: evaluators score against a rubric that maps to the RFP sections, and proposals that reorganise the information in a non-standard structure force evaluators to hunt for responses, which systematically produces lower scores. Third, use the evaluation criteria as headings: if the evaluation criteria specify "operational reliability in degraded communications environments", use that exact phrase as a section heading and provide specific, documented evidence of performance under those conditions. Fourth, submit prior to the deadline by a meaningful margin: late submissions are disqualified, and submissions received in the last hour before the deadline often have administrative problems that would have been caught with more time.