A Practical Guide To Government IT Services RFPs

A request for proposal (RFP) for government IT services must do more than describe a technical problem. It needs to explain the public outcome, establish a fair procurement process, protect sensitive information, and give suppliers enough detail to submit comparable, realistic offers. A well-written document reduces ambiguity before the contract is signed and creates a stronger basis for managing performance later.

Australian government buyers work within a procurement environment shaped by public accountability, probity, privacy obligations and value-for-money expectations. The approach may differ between a Commonwealth agency, a state department, a local council or a government-owned organisation, yet the underlying discipline is similar: define the need clearly, invite competition fairly and make the evaluation method visible from the start.

Define The Public Outcome Before The Technology

Begin with the business problem and the public service outcome, rather than naming a preferred platform. For example, a department might need to reduce permit-processing time, improve access to digital services in regional communities or give frontline staff a reliable case-management system. This tells suppliers what success should look like while leaving room for innovative approaches.

A useful statement connects the current situation, the intended change and the people affected. Explain who uses the service, which channels are involved, what pain points exist and why the project matters now. Include relevant constraints such as legacy applications, shared government infrastructure, accessibility requirements, service continuity and the expected number of users.

Avoid vague objectives such as “modernise ICT” or “implement a best-practice solution”. Replace them with measurable outcomes: a defined response time, a target availability level, a reduction in manual handling or a specific improvement in customer satisfaction. If the agency is exploring a government-as-a-platform model, this reference on shared digital government can help frame the broader service context.

The scope should also state what is excluded. Suppliers need to know whether the engagement covers discovery, design, implementation, data migration, testing, training, service transition, support and continuous improvement. Clear boundaries make pricing more reliable and prevent an attractive proposal from quietly expanding into an unaffordable programme.

Turn Needs Into Testable Requirements

Separate mandatory requirements from desirable capabilities. Mandatory requirements should be limited to conditions that are essential for legal compliance, operational safety, security or successful delivery. If every feature is labelled compulsory, smaller Australian suppliers may be discouraged and the evaluation team may lose sight of the project’s real priorities.

Write requirements in a way that can be tested. “The system must support role-based access with multi-factor authentication” is stronger than “the platform should be secure”. “The supplier must restore priority-one service within four hours” is easier to evaluate than “the provider must offer responsive support”. Each requirement should have an identifiable source, an owner and a method of verification.

For Australian projects, include requirements relevant to the operating environment. These may include compliance with the Privacy Act 1988, Australian Privacy Principles, state records legislation, accessibility expectations and the agency’s information-security policies. Commonwealth agencies may also refer to the Protective Security Policy Framework, the Information Security Manual and the Essential Eight, where applicable. Requirements should reflect the agency’s risk profile instead of copying a generic checklist.

Ask for evidence rather than assurances. A supplier could provide a sample service-level report, penetration-testing approach, disaster-recovery results, personnel screening process or data-residency explanation. If information will be hosted in Australia, specify whether Australian data storage is mandatory, preferred or simply one factor in the assessment. This distinction can materially change the supplier market and the price.

Design A Commercially Clear RFP

A strong statement of work explains the expected deliverables, dependencies, milestones and acceptance conditions. Include the agency’s responsibilities as well as the supplier’s responsibilities. Government projects often slow down because the client must provide data, subject-matter experts, approvals or access to legacy systems, yet those dependencies were not made visible in the tender.

Set out the pricing response in a consistent format. Request separate figures for implementation, licences, hosting, integration, training, support, travel, optional services and any usage-based charges. State whether prices should include GST and whether expenses must be pre-approved. For a long-term managed service, ask suppliers to identify indexation, volume assumptions, renewal costs and exit fees.

Budget information requires careful handling. Providing an indicative range can improve the quality of responses, particularly where suppliers need to propose a delivery team and transition plan. Withholding every financial signal may produce bids based on incompatible assumptions. Procurement teams can also monitor wider market conditions, including reference information such as today’s gold rate, when considering economic volatility and supplier cost pressures, although commodity prices should never substitute for a project-specific cost model.

The contract model should match the uncertainty in the work. A fixed price may suit a tightly defined implementation, while time-and-materials arrangements with a capped value may be more practical for discovery or agile product development. The RFP should explain how changes will be approved, how delays will be handled, what warranties apply and which party carries each major risk.

Include intellectual property, licensing and data provisions in plain language. State who owns newly created materials, whether the agency receives a perpetual licence, how open-source components must be disclosed and what happens to agency data at contract expiry. Include obligations for confidentiality, subcontractor approval, records retention, audit access, incident notification and secure deletion.

Make The Procurement Fair And Manageable

The response instructions should tell bidders exactly what to submit and how the submission will be assessed. A practical format might include an executive summary, understanding of the need, proposed solution, delivery plan, team profiles, relevant experience, security response, pricing schedule, assumptions, risks and contract departures. Set page limits where appropriate so that evaluation focuses on evidence rather than presentation.

Publish a timetable covering the release date, briefing, question period, addenda, closing time, evaluation, negotiations, approval and anticipated contract award. In Australia, use the procurement channel appropriate to the organisation, such as AusTender for relevant Commonwealth opportunities or the applicable state or territory portal. A local council in Queensland, New South Wales or Victoria may use different systems and rules, so the RFP should identify the governing policy and contact point.

Treat supplier questions consistently. Send answers to all registered bidders unless the material is genuinely confidential, and issue formal addenda when a clarification changes the requirement. Do not provide informal guidance to one supplier by phone or during a private meeting. A Canberra incumbent, a Melbourne software firm and a regional integrator should have access to the same material and the same time to respond.

Probity controls matter even when the contract is modest. Record conflicts of interest, use a confidentiality undertaking for evaluators and keep a decision trail that explains how scores were reached. Avoid requirements that appear designed around one supplier’s proprietary product unless there is a defensible reason and an approved exception. Consider whether the opportunity can be divided into work packages so that capable small and medium enterprises can participate.

The evaluation panel should be formed before the RFP is released. Include operational, technical, commercial, security and procurement perspectives, with an independent probity adviser where the risk or value warrants it. Define how non-compliant bids, abnormally low prices, conflicts, subcontractors and clarification requests will be treated. These decisions become harder to defend when they are invented after bids arrive.

Compare Offers On Value And Delivery Confidence

Evaluation criteria should reflect the outcomes described in the RFP. A common model might assess technical and functional fit, delivery approach, security and privacy, relevant experience, service management, price, social value and quality of the proposed team. The weighting will depend on the engagement, but the criteria should be specific enough that two evaluators can reach broadly similar judgements.

Use a scoring guide with descriptions for weak, acceptable and excellent responses. “Demonstrates extensive experience” is less useful than “provides two comparable public-sector examples, named references and evidence of meeting agreed service levels”. Score the evidence presented, not the reputation of a supplier or the polish of its branding.

Price should be assessed across the expected life of the service. A low implementation fee may conceal expensive licences, integration work or support charges. Ask for a total-cost-of-ownership view that covers the initial term, extension options, transition-in, upgrades, cybersecurity obligations and exit. Consider the financial resilience of the provider, particularly where the service will become operationally critical.

Plan for due diligence before award. Reference checks should test claims about delivery quality, incident handling, staff continuity and contract governance. Demonstrations should use realistic scenarios supplied by the agency rather than a rehearsed sales script. For a cybersecurity-sensitive service, verify the proposed controls and personnel rather than accepting a generic certification list.

Practical Checks Before Release

• Confirm the procurement authority, approval pathway and applicable Commonwealth, state or local policy.
• Test every mandatory requirement to ensure it is genuinely essential and objectively verifiable.
• Ask an independent person to review the scope, evaluation criteria and contract risks.
• Provide suppliers with consistent templates for pricing, assumptions, departures and security responses.
• Check that privacy, accessibility, records management and data-hosting expectations are explicit.
• Include transition, knowledge transfer, business continuity and exit requirements from the beginning.
• Prepare a decision record that can explain the preferred supplier to auditors, executives and unsuccessful bidders.

RFP Element	Weak Approach	Stronger Approach
Objective	“Modernise the department’s IT”	“Reduce average application-processing time by 30% within 12 months”
Security	“The supplier must be secure”	Defines controls, evidence, incident reporting and agency policies
Pricing	One total project figure	Separates implementation, licences, support, options and GST
Evaluation	General assessment of quality	Published criteria, weightings and scoring guidance
Service levels	“Provide reliable support”	Measurable availability, response, restoration and reporting targets
Data	Broad confidentiality wording	Specifies hosting, access, retention, breach notification and deletion
Supplier access	Informal briefings	Shared Q&A, formal addenda and equal response opportunities

After selecting a preferred bidder, keep the proposal, evaluation record and negotiated departures aligned with the final contract. A supplier’s response may contain important assumptions that disappear during drafting unless they are deliberately carried forward. Make acceptance criteria, reporting obligations and governance meetings contractual rather than leaving them in an aspirational proposal.

Contract management should begin before mobilisation. Establish who owns the relationship, how performance data will be reviewed, how risks will be escalated and how changes will be prioritised. For a service used across multiple Australian offices or remote communities, agree on support hours, regional coverage and communication arrangements before the first incident occurs.

A government IT services RFP succeeds when it creates a fair test of capability and a reliable bridge to delivery. Define the public outcome, make requirements measurable, disclose the commercial model, protect probity and evaluate whole-of-life value. With those foundations in place, procurement teams can attract credible suppliers and give the eventual contract a much better chance of delivering practical benefits for the community.