Are Evidence-Based RFPs A Better Way to Procure Software?
For decades, the request for proposal has been the standard method for procuring major software. It promises structure, fairness and an objective comparison between competing vendors.
Yet many organisations discover an uncomfortable truth after signing the contract: the vendor that produced the strongest written response does not necessarily provide the best software, implementation team or long-term fit.
The problem is not the RFP itself. The problem is relying on vendor assertions rather than evidence.
An evidence-based RFP retains the governance and competitive discipline of formal procurement, but requires vendors to prove their claims through realistic demonstrations, implementation detail, customer evidence and transparent commercial assumptions.
Why traditional software RFPs fall short
A traditional RFP can contain hundreds—or even thousands—of individual requirements. Vendors are asked to classify each requirement using answers such as:
Fully supported
Supported through configuration
Requires customisation
Planned for a future release
Not supported
This creates the appearance of precision. In practice, the answers can be difficult to compare.
One vendor's “fully supported” may involve a seamless, standard workflow. Another vendor may use the same answer for a process involving several screens, manual intervention or an additional product. Both receive the same score.
Long requirements lists also tend to reward vendors with experienced bid teams. The procurement process becomes a test of proposal writing rather than a test of the software.
Other common weaknesses include:
Requirements that reproduce the current system rather than improve the operating model
Every feature being treated as equally important
Product functionality receiving more attention than implementation risk
Licence prices being compared without complete implementation and lifecycle costs
Configuration, integration and custom development being poorly distinguished
Future roadmap statements being evaluated as though they were available functionality
The result can be a highly defensible procurement process that still selects the wrong solution.
What is an evidence-based RFP?
An evidence-based RFP changes the central question.
Instead of asking, “Does your system support this requirement?”, it asks, “Can you demonstrate how your system delivers this outcome?”
The distinction is important. Written responses remain part of the process, but they are treated as claims to be verified—not as proof in themselves.
An evidence-based process combines:
Outcome-based requirements
Early market engagement
Prioritised use cases
Scripted demonstrations
Clear configuration and customisation disclosure
Implementation due diligence
Comparable total-cost modelling
Customer reference validation
Proofs of concept where the risk justifies them
This direction is consistent with contemporary digital procurement guidance. The UK Government's Digital, Data and Technology Playbook, for example, promotes early market engagement, outcome-based specifications, whole-life value, testing and iterative delivery rather than overly prescriptive solution requirements.
Start with outcomes, not features
Feature questions encourage feature answers. Outcomes reveal whether the software can support the institution's real work.
Consider these two requirements:
Feature-based requirement:
The system must provide configurable student enrolment workflows.
Outcome-based requirement:
Demonstrate how a student changes their program, including approval, prerequisite checking, fee recalculation, study-plan updates and notification to relevant staff.
The first requirement can be answered with “Compliant.” The second exposes the actual workflow, data model, user experience, automation and dependencies.
For a student information system, useful scenarios might include:
Creating, approving and publishing a new program
Opening a term and managing class availability
Processing an application through admission and enrolment
Applying prerequisites, credit and progression rules
Changing a student's study plan after enrolment
Managing employer sponsorship or another third-party payer
Exchanging enrolment and results data with an LMS
Producing an academic transcript or regulatory return
Implementing a policy change without modifying the product core
These are end-to-end business processes, not isolated functions. They show how the solution behaves when multiple parts of the institution interact.
Make scripted demonstrations the centre of evaluation
Vendor-led demonstrations are useful for introducing a product, but they should not be the primary selection tool. Vendors naturally demonstrate their strongest features using carefully prepared data.
In a scripted demonstration, every shortlisted vendor receives the same scenarios, background information and expected outcomes. Evaluators can then compare like with like.
A good demonstration script should:
Describe the business situation without prescribing the technical solution
Use realistic institutional data and exceptions
Require vendors to show complete workflows rather than presentation slides
Identify the users participating in the process
Include reporting, security and integration implications
Allow time for evaluators to ask unscripted follow-up questions
Vendors should also identify, during the demonstration, whether each capability is delivered out of the box, through configuration, through an integration, by custom development or through a future roadmap item.
Where practical, demonstrations should be recorded and linked to the relevant evaluation evidence. This reduces reliance on evaluators' memory and creates a clearer audit trail.
Evaluate implementation—not just the product
Complex software is not purchased in isolation. The outcome depends on the product, implementation approach, institutional team, data quality, integrations and change management.
The evidence-based RFP should therefore evaluate the proposed delivery model separately from product functionality.
Vendors should provide evidence covering:
The named implementation team and their relevant experience
The division of responsibilities between customer and supplier
Data migration scope, cleansing assumptions and reconciliation methods
Integration architecture and ownership
Governance, escalation and decision-making processes
Training, adoption and organisational change
Testing and acceptance criteria
Upgrade and release-management arrangements
Customer effort required during each project phase
Dependencies that could affect cost or timeline
References should be comparable to the proposed project. A glowing reference from a small, simple implementation may provide little evidence for a large, multi-campus institution with complex reporting and integration requirements.
Ask reference customers what changed between the proposal and the actual project, what required more effort than expected and what they would do differently.
Compare whole-of-life cost
The lowest initial price is not necessarily the lowest-cost solution.
An evidence-based commercial evaluation considers the total cost over an appropriate period—often five to ten years. This may include:
Software subscriptions or licences
Initial implementation
Data migration
Integrations
Additional environments and platform services
Third-party products
Internal staffing
Training and change management
Support and managed services
Customisation maintenance
Upgrades and regression testing
Data storage, archiving and transaction charges
Contract exit and data extraction
All vendors should price against the same assumptions and volumes. Any exclusions should be explicit. Without a common cost model, a low-priced proposal may simply contain more unpriced work.
Use proofs of concept selectively
A proof of concept should not attempt to implement the entire system before procurement. It should test the small number of issues most likely to determine success.
For example, an institution might test:
A particularly complex progression rule
Performance with representative data volumes
Integration with an existing finance or learning platform
A high-risk regulatory report
Configuration of a distinctive business model
Proofs of concept require time and effort from both buyer and supplier, so they should be reserved for material risks that cannot be resolved through demonstration, documentation or customer references.
A practical evidence hierarchy
Not all evidence carries equal weight. Procurement teams can use a simple hierarchy:
Capability demonstrated live in the proposed product
Capability verified in a controlled proof of concept
Capability confirmed by comparable reference customers
Capability supported by current product documentation
Capability described in the written proposal
Capability promised on a future roadmap
Roadmap commitments may still be relevant, but they should not receive the same score as functionality available and demonstrated today. If a future capability is essential, it should be supported by an enforceable commitment, delivery date and commercial remedy.
Better evidence produces better decisions
The purpose of an RFP should not be to create the longest possible requirements document. It should create enough reliable evidence to make a sound, transparent decision.
For complex platforms such as a student information system, a successful procurement process must establish more than whether a vendor can say “yes.” It must determine:
How the software works in real institutional scenarios
What must be configured, integrated or developed
Whether the proposed team can deliver the project
What the institution itself must contribute
What the solution will cost over its lifecycle
How easily it can adapt as policies, technology and student expectations change
The RFP still has an important role in software procurement. It provides governance, competitive tension and a documented basis for selection. But it works best as the framework through which evidence is collected and compared—not as a substitute for that evidence.
The better question is no longer, “Which vendor gave the best answers?”
It is: “Which vendor provided the strongest evidence?”