Technology partner for procurement and contracting officers

You buy technology in the same office that buys vehicles, janitorial services, construction, and professional services, under the same statute, the same policy manual, and the same audit. Technology arrives with problems the other categories do not have: a product name in place of a requirement, a quote that covers licenses but not the work that makes them useful, hosting somewhere the agency cannot inspect, a subscription that renews itself, and a vendor agreement that incorporates terms from a web page. A department brings you a requisition with a start date already attached and asks how quickly it can reach the governing body.

What you are accountable for does not change with the category. The competition has to be fair and has to be documented well enough to look fair later. The award has to hold if a losing proposer asks for the record. The contract has to protect the agency's data, its money, and its ability to leave. The work has to keep moving, because grant periods end, agenda deadlines fall well before the meeting itself, and the fiscal year closes whether or not the scope was ready. When a scope of work has been assembled from a vendor's brochure, you are usually the first person to notice, and the choice is to fix it and absorb the delay or release it and own what comes back.

What makes this hard

• Technology requests arrive as a product name and a quote rather than a requirement, leaving you to choose between releasing a specification written around one vendor and sending it back at the cost of weeks.
• Estimates cover license cost but not implementation, data migration, interfaces, training, or the renewal increases that arrive later in the term, so the amount awarded stops matching what the agency actually spends.
• Vendor paper resists agency terms: click-through agreements, terms incorporated by reference to a page the vendor can change, automatic renewal, limits of liability far below the value of the data at risk, and no termination for convenience or non-appropriation language.
• Evaluation committees want to score on demonstration impressions, and a thin scoring record is exactly what a protest tests.
• Sole source requests for technology are common and often weak, but rebutting one takes specific knowledge of the alternatives, which most purchasing offices are not staffed to hold.
• Amendments and renewals grow the work past what was competed, one reasonable-sounding change at a time, until the contract no longer resembles the award.
• The calendar belongs to other people: grant end dates, agenda deadlines, fiscal year close, and a requesting department that came to you late.

How HQT helps

• Turn a department's request into requirements that can be verified at acceptance, with must-have separated from desirable, and a statement of work that describes the outcome rather than one product's feature list.
• Build an independent cost basis for the estimate covering implementation, integration, data migration, training, hosting, and the renewal years, so the solicitation, the budget request, and the award reflect the whole term.
• Draft the technical contract exhibits: data ownership and export, source code and repository delivery, security requirements, accessibility conformance to WCAG 2.1 Level AA, service levels, acceptance testing, change control, and transition assistance at the end of the term.
• Write evaluation materials before release, including scoring criteria and weights, demonstration scripts built from the agency's own scenarios, and reference questions, so scores rest on published criteria instead of impressions.
• Review the technical claims in proposals, such as security questionnaire responses, accessibility conformance reports, hosting and subcontractor disclosures, and integration assertions, and give the committee plain findings it can cite in the record.
• Provide an independent technical assessment of a sole source justification, stating whether comparable alternatives exist and what switching would involve, with the determination left to the agency.
• Serve as the agency's technical representative after award, checking deliverables against the contract, analyzing change requests before they are approved, and advising on acceptance and go-live.

How work with a purchasing office usually starts

A department comes to you with a request that is already half a decision: a product, a quote, and a date. The technical work of turning that into something you can compete and defend has to happen somewhere, and it rarely fits in the requesting department's schedule. Engagements often begin with one defined piece of that work: writing testable requirements and a statement of work for a solicitation already in the queue, building an independent cost basis so the estimate covers the full term, or reviewing a sole source justification to see whether the capability described is genuinely unique.

After that, the work follows the procurement's own calendar. Requirements and evaluation criteria before release. Written answers during the question period, so every proposer sees the same information. Technical review of proposals against the published criteria, with scoring left to the committee. Then, when the agency wants it, technical oversight through implementation, where deliverables are measured against the contract that was signed rather than the demonstration that was given.

Purchasing offices generally want advisory work sized to a route they already have. A defined assessment or a solicitation package can often be scoped to a purchase order or a quotes process. Thresholds, approval paths, and posting rules vary by agency and are revised over time, so the route gets confirmed against your current policy before the scope is set.

What to ask any technology partner

Ask the questions whose answers belong in the file.

• Do you sell or resell what you are helping us evaluate? A firm that advises on a selection and also earns margin on the product cannot give an independent recommendation, and the appearance is as much of a problem as the substance.
• Will you bid on the solicitation you help us write? The answer should be no, and it should be in the engagement agreement rather than in conversation.
• Who owns what you deliver? Source code, configurations, documentation, and data should belong to the agency and land in agency-controlled repositories and accounts as the work proceeds.
• How do we get our data out, in what format, and at what cost? Export terms are inexpensive to negotiate before award and expensive to negotiate at the end of a term.
• Which of our standard terms will you accept? Termination for convenience, non-appropriation, public records handling, audit rights, insurance, and a limitation of liability proportionate to the risk in the scope.
• Will security and accessibility be contract terms rather than statements of intent? Named controls and conformance obligations belong in exhibits with acceptance criteria attached to them.
• What happens at transition? Named assistance, a defined period, and a price agreed at signing, not quoted later by a vendor with no remaining incentive.

HQT works with purchasing offices on that side of a technology buy: requirements, evaluation materials, technical review, and the contract exhibits that carry the agency's protections.

Frequently asked questions