How to Write Requirements that Deliver Outcomes: A Practical RFP Language Guide for Revenue Management & Control Programs
In Part I and Part II of this chapter, we explored two foundational decisions that shape every revenue management and control program: architecture and funding. Together, they determine how a government will generate intelligence, coordinate enforcement, sustain operations, and maintain accountability over time.
Once selected, these decisions are embedded into the procurement process. Requirements can only operationalize strategic choices already made. An RFP built on a limited architecture or unsustainable funding model cannot recover the capabilities that were excluded earlier in the process.
The next challenge is therefore translating these strategic choices into procurement requirements that enable the desired outcomes.
This is where many RFPs begin to lose value.
Rather than defining the outcomes a system must achieve, procurement teams often focus on specific technologies, components, or implementation methods. Requirements become lists of products: tax stamps, scanners, databases, mobile devices, or security features.
The consequence is that vendors are evaluated on their ability to match a prescribed solution rather than on their ability to deliver measurable public outcomes.
A stronger approach starts with a different question:
What capabilities and outcomes must the State be able to demonstrate once the program is operational?
The Principle of Outcome-Based Procurement
Revenue management and control programs are ultimately designed to help governments achieve five national objectives:
- Protect tax revenues
- Strengthen enforcement effectiveness
- Increase supply chain visibility
- Improve interagency coordination
- Build public trust and accountability
These objectives should form the foundation of the RFP. Rather than prescribing technologies, governments should define the outcomes they seek to achieve and allow bidders to demonstrate how their proposed architecture, operating model, and solution will deliver them.
Every requirement in an RFP should serve a risk reduction objective: fiscal, operational, governance, political or audit. The role of procurement is therefore not to select a collection of technologies, but to identify the solution most capable of delivering the desired outcomes while minimizing long-term institutional exposure.
For example, instead of prescribing a solution, governments should define measurable expectations:
| Less effective requirement | Outcome-based requirement |
|---|---|
| “The solution shall include security stamps incorporating holographic features and handheld inspection devices.” | “The solution shall enable authorities to authenticate regulated products in the field and detect counterfeit, diverted, or non-compliant products with a high degree of confidence.” |
The second requirement focuses on the objective rather than the mechanism. This distinction may appear subtle, but it fundamentally changes the quality of proposals governments receive.
The Four Requirement Domains of a Strong RFP
To achieve the objectives outlined above, requirements should be evaluated not only on functionality, but on the degree to which they reduce institutional risks.
For this reason, governments should structure requirements across four complementary domains, each of them with risk reduction objectives:
Together, these domains define not only how a system operates, but also how it creates national value, remains sustainable over time, and supports defensible public decision-making.
1. Solution Architecture Requirements
Architecture is not simply a technical design choice. It determines the level of visibility, intelligence, enforcement capability, and interagency coordination a government can achieve throughout the life of the programme.
Many procurement requirements can be modified during implementation. Architecture decisions cannot. Once an architectural model is embedded into an RFP, governments effectively lock in:
- The level of intelligence they can generate
- The degree of interagency collaboration they can achieve
- The extent to which citizens can participate in verification and reporting
- The auditability and defensibility of future enforcement outcomes
These choices are rarely reversible without significant operational disruption, political justification, retraining efforts, budget adjustments, or renewed procurement activity.
For this reason, architectural requirements deserve greater scrutiny than individual technical specifications. Governments should avoid prescribing technologies and instead define the capabilities and outcomes that the architecture must deliver.
Risk Reduction Objective
A well-designed architecture should reduce four categories of institutional risk:
| Operational Risk | Illicit activity is detected too late to enable effective intervention |
| Enforcement Risk | Authorities lack actionable intelligence to support investigations and field operations |
| Coordination Risk | Agencies operate with fragmented information and limited cross-agency visibility |
| Audit Risk | Government cannot demonstrate, explain, or defend programme outcomes with confidence |
Key Evaluation Question:
Which proposed architecture provides the most effective combination of visibility, intelligence, coordination, and auditability while minimising long-term institutional risk?
Common failure
Government specifies security features instead of authentication outcomes.
Result:
- high compliance
- low intelligence
- limited enforcement impact
Example RFP Language
The solution shall provide an integrated architecture enabling product authentication, traceability, enforcement support, and regulatory oversight within a unified framework.
The solution shall provide authorized government entities with access to a trusted and auditable source of information supporting compliance monitoring and enforcement activities.
The architecture shall enable both physical verification and digital intelligence capabilities in support of enforcement and compliance objectives.
The architecture shall support the capture, storage, and retrieval of relevant product events throughout the regulated supply chain.
Drag to explore
2. Funding & Sustainability Requirements
As discussed in Part II, funding is not simply a financial consideration. It directly impacts governance, continuity, market acceptance, and long-term program success. RFPs should therefore clearly define funding expectations and require bidders to demonstrate how the proposed model remains sustainable throughout the lifecycle of the program.
The objective is not necessarily to prescribe a government-funded, industry-funded, or hybrid model, but to ensure transparency, accountability, and long-term viability.
Common failure
Government selects a high-capability architecture but allocates funding only for deployment.
Result:
- analytics degrade
- enforcement activity declines
- intelligence quality deteriorates
- programme outcomes weaken over time
Funding requirements should reduce:
- Fiscal risk
- Political risk
- Continuity risk
- Programme sustainability risk
Example RFP Language
Bidders shall clearly describe all costs associated with the implementation, operation, maintenance, evolution, and support of the proposed solution.
The proposed funding model shall demonstrate the ability to sustain program operations, enforcement activities, system upgrades, and regulatory evolution throughout the contract lifecycle.
Where industry-funded or partially industry-funded models are proposed, bidders shall demonstrate mechanisms ensuring regulatory independence, government authority, and transparent governance.
Drag to explore
3. Governance & Sovereignty Requirements
A Revenue Management & Control programme is ultimately an instrument of State authority. While technology providers may deliver platforms, security features, and operational services, governments must retain control over policy, enforcement priorities, regulatory evolution, and strategic decision-making.
Sovereignty is therefore not a technical consideration; it is a governance requirement.
A strong RFP should ensure that control remains with the State across four critical dimensions:
| Data Ownership | Government retains ownership of programme data, intelligence, regulatory records, and operational information generated throughout the programme lifecycle |
| Operational Ownership | Authorities maintain control over business rules, enforcement priorities, compliance policies, and programme direction without undue dependency on the service provider |
| Knowledge Ownership | Institutional knowledge, operational expertise, and system understanding are progressively transferred to government teams to avoid long-term capability gaps |
| Transition Rights | Government can transfer operations, data, services, and knowledge to another provider, or bring them in-house, without disruption to public operations. |
The fourth dimension is particularly important. Sovereignty is often discussed in terms of ownership, but true sovereignty is demonstrated by the ability to maintain continuity, control, and freedom of action over time.
A government that cannot transition to another provider without significant disruption does not possess full operational independence, regardless of who technically owns the data. For this reason, sovereignty requirements should be defined in measurable and auditable terms rather than through policy statements alone.
Well designed governance requirements should reduce:
- Sovereignty risk
- Vendor dependency risk
- Transparency risk
- Legal and audit risk
- Loss of institutional knowledge
Strong governance requirements ensure that the State remains in control throughout the program lifecycle, preserves operational continuity across political transitions, and avoids long-term dependency on a single provider.
Example RFP Language
The contracting authority shall retain ownership of program-generated data, regulatory information, and operational records throughout the duration of the program.
The solution shall enable the contracting authority to define, modify, and govern business rules, operational policies, and compliance parameters without undue dependency on the service provider.
The bidder shall demonstrate how services, operations, knowledge, and data can be transferred to the contracting authority or a future provider without disruption to public operations.
Drag to explore
4. Performance & Outcome Requirements
A revenue management and control program should not be evaluated based solely on system deployment or technical functionality. Success must ultimately be measured against public policy outcomes, enforcement effectiveness, operational performance, and long-term national value. For this reason, performance requirements should focus on measurable outcomes rather than technical inputs alone.
Common failure
Government focuses on deployment metrics instead of outcome metrics.
Result:
- projects delivered
- policy objectives missed
Performance requirements should reduce:
- Delivery risk
- Value realisation risk
- Enforcement effectiveness risk
- Political accountability risk
Example RFP Language
The bidder shall propose a framework for measuring program outcomes throughout the contract lifecycle, including enforcement, compliance, operational, and financial indicators.
The solution shall support periodic performance reviews and the identification of improvement opportunities based on operational data and program outcomes.
The solution shall provide executive-level dashboards enabling decision-makers to assess program performance against defined national objectives.
Drag to explore
A strong RFP should balance four dimensions:
- Architecture
- Governance & Sovereignty
- Performance Outcomes
- Sustainability
The purpose is not to recommend a specific weighting model. The example illustrates how strategic outcomes can be evaluated alongside cost and technical compliance.
Weights vary by jurisdiction, but governments should ensure strategic outcomes receive comparable importance to cost and technical compliance.
Strategic Reminder
Architecture, funding, governance, and performance should not be evaluated independently. A strong architecture cannot compensate for weak governance. Strong governance cannot compensate for inadequate funding. Strong funding cannot compensate for poor performance measurement. The most resilient programmes are those in which all four dimensions reinforce one another.
The 5th evaluation lens: decision defensibility
Architecture, funding, governance, and performance are often evaluated separately during procurement. Senior decision-makers must answer a broader question: Can this decision be justified, defended, and sustained throughout the life of the programme?
A decision is defensible when government authorities can clearly demonstrate why a solution was selected, how risks were assessed, and how the chosen approach supports long-term public objectives.
Questions decision-makers should ask:
- Can evaluators clearly justify scoring and selection decisions?
- Can the selected architecture be explained and defended under political, operational, and audit scrutiny?
- Can the funding model remain credible if priorities, budgets, or administrations change?
- Can programme outcomes be demonstrated through evidence rather than assumptions or vendor claims?
- Can the State show that sovereignty, continuity, and public-interest objectives have been protected throughout the programme lifecycle?
Decision defensibility helps reduce:
- Procurement risk – challenges to the fairness or rationale of the selection process
- Political risk – scrutiny from legislators, ministries, industry, or civil society
- Audit risk – inability to demonstrate why a decision was made and whether it delivered the intended outcomes
- Programme continuity risk – loss of support when leadership, administrations, or priorities change
The 5 questions every evaluation committee should ask:
1. Does this architecture reduce risk?
2. Is the programme sustainable?
3. Does the State retain sovereignty?
4. Can outcomes be measured?
5. Can the decision still be defended five years from now?
Conclusion
The effectiveness of a Revenue Management & Control program is often determined long before proposals are evaluated. Architecture, funding, governance, and performance requirements collectively define what outcomes the State will be able to achieve and sustain over time.
A strong RFP therefore focuses on capabilities, accountability, and measurable outcomes rather than technologies alone. By doing so, governments create the conditions for stronger competition, more defensible procurement decisions, and greater long-term national impact.
Strong requirements ensure that architecture, funding, governance and performance remain aligned with those outcomes from procurement through execution.
What Comes Next
Once the RFP is published, the challenge is now selecting the solution most capable of delivering the desired outcomes.
In Chapter 3, we move into the Active RFP phase and examine how governments can evaluate vendors, distinguish evidence from claims, assess long-term value beyond price, and make procurement decisions that remain robust under audit, political scrutiny, and future review.
After all, the objective is not to select a compliant bidder. It is to select the partner most capable of delivering sustainable public outcomes.
Before the RFP
Coming Soon
Coming Soon
Contact us
If your institution is preparing or reviewing an RFP for a revenue management & control program, Inexto provides government-only advisory sessions to support drafting, review, and evaluation design.