Procuring grants management software — particularly for government agencies and large public funders — requires navigating both procurement policy requirements and the practical evaluation of complex software. Getting the procurement process right is as important as selecting the right software.
This guide covers the procurement process for grants management software, from needs assessment through contract award.
Effective procurement starts with a clear statement of requirements. Before going to market, funders should:
Document current state. What systems are in use today? What are the pain points? What's working and what isn't? What manual processes are being done that software should automate?
Engage programme staff. The people who actually administer grants have the clearest view of what the software needs to do. Their input on requirements is more valuable than IT or procurement staff working in isolation.
Define must-have vs nice-to-have. Not all requirements are equal. Essential requirements (audit trail, configurable forms, online applications) should be distinguished from desirable features (advanced analytics, specific integrations) so evaluation can be appropriately weighted.
Consider integration requirements. What systems will the grants management software need to integrate with? Accounting software, CRM, payment systems, SSO providers. Integration requirements are often underspecified in procurement and become expensive problems post-contract.
Size the programme. How many grants per year? How many active programmes? How many concurrent users? How many external applicants? Sizing informs pricing and platform selection.
Document compliance requirements. For government agencies, what are the specific compliance requirements — audit trail depth, delegation enforcement, ministerial briefing formats, OIA readiness? For gaming trusts, what are the DIA compliance requirements? For large foundations, what are the governance requirements?
Direct procurement (low value). For smaller organisations procuring within delegated authority thresholds, direct procurement without formal tender may be permitted. Most New Zealand government agencies can procure under $100,000 directly; Australian Commonwealth agencies have PGPA Act thresholds. Check your procurement policy.
Competitive quotation. Seeking quotes from multiple vendors — typically 3 or more — with a defined selection process. Appropriate for mid-range procurement. May be conducted informally or through a structured RFQ (Request for Quotation).
Formal tender (RFP/ITT). A formal Request for Proposal or Invitation to Tender process, with published requirements, a structured evaluation framework, and documented selection. Required for large procurements and recommended for complex software procurement regardless of value.
Panel / HGSNZ / AusTender. In New Zealand, the All-of-Government (AoG) panels and NZGP contracts provide pre-negotiated pricing for certain software categories. Australian agencies can use the Digital Marketplace or existing standing offers. Checking whether an existing panel arrangement covers grants management software reduces procurement overhead.
A grants management software RFP should cover:
Background. Who you are, what you do, what grant programmes you run, what you're trying to achieve with the new system.
Current state. What you use now, why you're changing, and what problems you're trying to solve.
Functional requirements. The specific capabilities you need. Organise by priority (essential/highly desirable/desirable). Common categories:
- Application portal and form design
- Assessment and scoring
- Grant management and agreement
- Payment processing
- Grantee reporting
- Integration requirements
- Security and access control
- Audit trail and compliance
- Reporting and analytics
Non-functional requirements. Performance, availability, data residency, security standards (e.g., ISO 27001, NZSF requirements for government).
Pricing requirements. Ask vendors to provide transparent pricing — including implementation, training, and ongoing licence costs — so you can evaluate total cost of ownership, not just sticker price.
Reference requirements. Ask for references from organisations similar in type and scale to yours.
Implementation approach. How will the vendor implement the system? What is the typical timeline? What is required from the customer?
Evaluation criteria. Publish how submissions will be evaluated — functional fit, commercial, vendor capability, references. Being transparent about criteria improves response quality.
Common evaluation dimensions for grants management software:
Functional fit (typically 40-50% weight). How well does the solution meet the stated functional requirements? Evaluated through demonstrations, vendor responses to requirements, and reference checks.
Commercial (typically 20-30% weight). Total cost of ownership over a defined period (3-5 years). Implementation, licensing, support, and any variable costs.
Vendor capability (typically 15-20% weight). How capable is the vendor to implement and support the solution? Track record, customer base, team expertise, financial stability.
Security and compliance (typically 10-15% weight). How well does the solution meet security and compliance requirements? Certifications, data residency, audit trail, access controls.
Evaluating features instead of outcomes. Evaluating whether a feature exists is less useful than evaluating whether it works well for your use case. Demonstrations and reference checks provide better evidence than feature checklists.
Under-weighting implementation and support. Software that isn't implemented well provides no value. The vendor's implementation capability and ongoing support quality are as important as the software features.
Buying for the worst case. Specifying requirements for the most complex scenario you can imagine — and dismissing simpler solutions that would serve 95% of your needs — leads to over-specified, expensive procurement.
Not involving end users. Procurement decisions made by IT and procurement without input from programme staff often result in software that is technically compliant but operationally unsuitable.
Treating price as a proxy for quality. In software procurement, the most expensive solution is not necessarily the best, and the cheapest is not necessarily the worst. Evaluate value, not just price.
Ignoring references. Vendor references from similar organisations are among the most reliable signals of whether a platform will work for you. Follow them up properly.
Grants management software contracts should address:
Tahua is a purpose-built grants management platform for the Australasian public and philanthropic sectors, with government procurement experience, existing agency clients, and transparent pricing.