Topic hub
Government Technology Procurement
Purchasing routes, solicitations, evaluation, contracts, pricing structures, and grant-funded buying.
Technology procurement decides more about a project's outcome than any technical choice made later. A solicitation that states testable requirements produces comparable proposals and a contract that can be enforced. A vague one produces padded prices, change orders, and a dispute about what acceptance meant.
These pages are written for the staff who run those processes: which purchasing route fits which kind of work, how to write requirements a vendor can price, how to evaluate proposals on evidence, which contract terms protect the agency's data and its ability to switch vendors, and what changes when federal grant money is involved.
HQT capabilities in this area
- Technology Advisory & Systems EngineeringIndependent technical advice, requirements, architecture, procurement support, and oversight for agency technology programs.
Services
- RFP Development & Vendor Evaluation
- Project & Program Management Support
- Requirements Engineering & Architecture
- Owner's Technical Representative
- Federal Systems Engineering Support
- Technology Strategy & Roadmaps
- Independent Verification & Validation
- Acceptance & Test Support
- Data Center Consolidation
- Responsible AI Policy & Governance
- Agile Software Development
- APIs & Systems Integration
Solutions by agency type
- Cybersecurity for Cities and TownsPractical security programs for municipal IT teams that support finance, public works, police, and fire with limited staff.
- Software Development for Cities and TownsResident-facing services, staff tools, and integrations between the platforms a city already owns.
- Software Development for State AgenciesAgile and DevSecOps delivery on large state programs, directly and as a subcontractor.
- Cloud and Enterprise IT for Cities and TownsGetting city systems out of the basement, modernizing networks across facilities, and keeping cloud costs predictable.
- Data and Analytics for Cities and TownsCouncil reporting, open data, and operational dashboards built on definitions everyone agrees with.
- Technology Advisory for Cities and TownsIndependent help specifying, buying, and overseeing the systems a city will live with for a decade.
- Technology Advisory and Systems Engineering for State AgenciesRequirements, architecture, independent verification, and oversight on large state technology programs.
- Technology Advisory for Special Districts and AuthoritiesIndependent technical leadership for agencies that need judgment more than they need staff.
- Cloud and Enterprise IT for State AgenciesMigration sequencing, landing zones, identity, and cost governance for state agencies moving large legacy portfolios under central IT standards.
- Cybersecurity for State AgenciesSecurity assessments, compliance evidence, and Zero Trust planning for departments answering to both state enterprise standards and federal auditors.
Step-by-step guides
- How to run a technology RFP, from planning to awardA sequence for agency staff running a competitive solicitation for software or technology services, from market research through award.
- How to evaluate an AI feature before you enable itA review process for the artificial intelligence features vendors are adding to software agencies already license.
Reference articles
- Two-step procurement: qualify vendors first, open prices secondHow two-step technology solicitations work: screening qualifications first, then opening sealed prices only for firms that advance.
- Fixed price, time and materials, or staff augmentation: choosing a contract structureA side by side comparison of fixed-price, time-and-materials, and staff augmentation contracts, and how to choose between them.
- A pre-solicitation readiness checklist for technology purchasesA readiness checklist for IT and program staff to work through before drafting a solicitation for technology products or services.
- Scoring technology proposals: evaluation criteria, weights, and committeesHow to build an evaluation rubric for a technology RFP: criteria, weights, price scoring, rating definitions, and committee mechanics.
- Sole source justification for software: building a defensible recordWhat a sole source justification for software has to prove, the evidence behind common fact patterns, and what gets one rejected.
- Change orders and amendments on technology contractsHow agencies separate a true scope change from a clarification or defect, and move a change from request to signed amendment
- Contract administration after award: who owns the obligationsHow agencies hand a signed contract from procurement to the program, and the artifacts and approval roles that keep it running.
- Who does the work: in-house staff, a managed service, or project vendorsHiring staff, contracting a managed service, or buying project by project: what each model costs an agency in money, risk, and retained knowledge.
- Market research before a solicitation: RFIs, demos, and fair dealingHow agencies learn what is available and what it costs before drafting a solicitation, without tainting the later competition.
- Buying with federal funds: procurement thresholds and required clausesHow federal procurement standards apply to grant-funded purchases: methods, documentation, and the contract provisions the award must carry.
- NDAA Section 889: banned cameras and access control gear in agency purchasesHow Section 889 restrictions on covered camera and telecom brands reach state and local purchases made with federal funds.
- Advance planning documents and federal cost allocation for HHS systemsHow planning and implementation APDs, prior approval thresholds, match rates, and cost allocation plans shape HHS system procurement schedules.
- Debriefing unsuccessful proposers after a technology awardHow state and local agencies can run a post-award debrief that is useful to the losing firm without disclosing competitors' confidential information.
- Cooperative purchasing: using contracts other agencies have already competedHow agencies buy through cooperative and piggyback contracts, and what to check before doing so.
- Writing a technology RFP that gets good proposalsHow agencies structure a solicitation so that vendors can price it accurately and evaluators can score it fairly.
- Run your own security operations or buy monitoring as a serviceFour models for continuous security monitoring, what each asks of staff and contracts, and how response decisions stay with the agency.
- Bid protests: common grounds and how agencies reduce the riskWhat a bid protest is, the grounds that most often appear, how the process runs, and the habits that prevent them.
- SaaS renewals: what to do in the year before the term endsA month by month approach to a SaaS renewal: notice windows, price escalation caps, usage inventory, and exit readiness.
- Software asset management and license audits for agenciesHow agencies keep an accurate software entitlement record, reconcile it against deployment, and prepare for a vendor license audit.
- E-rate: how schools and libraries fund broadband and network equipmentHow the federal E-rate program discounts broadband and network equipment for schools and libraries, and what it requires.
- GASB 96 SBITAs and GASB 87 leases: getting the data out of your contractsHow to inventory SBITAs and leases, decide what is in scope, pull terms from contracts, and produce GASB 96 and 87 disclosures each year.
- Budgeting and capping AI usage costs: tokens, seats, and overageHow agencies estimate, cap, and charge back AI software costs across seat, token, and overage pricing models.
From the blog
- Discovery should be a small fixed-price project, not a free sales exercise
- A project is not finished until the agency can run it without the vendor
- Your vendor's new AI feature is a new system, not an update
- The uptime number is the least important part of a service level agreement
- A plain-language glossary of the technology terms in your next IT solicitation
- Publish DMARC at reject, then keep the callback rule anyway
- An acceptable use policy for generative AI should govern data, not tools
- Running language models inside the agency's cloud boundary
- Five terms we think every agency AI contract should include
- Acceptance criteria that a tester can execute and a contract can rely on
- A SOC 2 report is evidence, not a certificate
- Boring technology is the right default for systems that must run for a decade
- The accessibility rule for state and local websites is not a future problem
- API-first integration for agencies that own a dozen vendor systems