A pre-solicitation readiness checklist for technology purchases

Reference article · 7 min read

Work through this checklist before anyone drafts a solicitation for software, systems, or technology services. It is written for the IT and program staff who will own the requirements and sit on the evaluation committee, and it works best as one working session with the purchasing office present. Each item should end in one of three states: yes, a documented not applicable, or a no with a named owner and a due date.

The useful result is an accurate sheet, not a full column of yes answers. Solicitations released with unresolved funding, undefined scope, or untested integration assumptions tend to produce addenda during the solicitation period, proposals that cannot be compared on equal terms, and change orders after award. No answers found now, while nothing is public yet, are the cheapest ones to fix.

The problem and the scope

• A written problem statement exists. A paragraph or two on what is not working now and what would be different afterward, reviewed and agreed to by the program that owns the work. If no, meet with program staff and write it before drafting anything else.
• The current process is documented end to end. Steps, handoffs, forms, approvals, and the spreadsheets or side systems staff actually use. If no, walk the process with the people who perform it and record what you observe rather than what the written policy says.
• Scope boundaries are written down. You can state what is in scope, what is out, which adjacent systems stay as they are, and whether this purchase replaces, adds to, or consolidates what exists. If no, decide each boundary now and record the decision, because a boundary left open before release becomes a negotiation after award.
• At least one option other than buying software has been considered, and the reason for rejecting it is written down. Process change, staffing change, training, or configuration of a system the agency already owns. If no, test each option against the problem statement before continuing.
• Volumes and user counts are documented. Transactions or cases per year, records to be migrated, named users, concurrent users, and peak periods. If no, pull the numbers from the current system or from manual counts, because vendors price from them and proposals cannot be compared without them.

Funding, authority, and schedule

• The funding source is identified and confirmed with finance. Which fund, which fiscal year, and whether it covers recurring costs as well as one-time implementation. If no, resolve it with finance before drafting.
• A cost estimate covers the expected life of the system, not the first year. Implementation, subscription or license fees, data migration, interfaces, training, internal staff time, and ongoing support. If no, build the multi-year estimate now, since renewal costs surface at budget review whether or not they were planned for.
• Grant conditions, where grant funds are involved, have been checked in writing. Federal and state awards can carry procurement requirements in addition to the agency's own rules, and the period of performance can limit when funds must be obligated and spent. If no, ask the grant administrator in writing and keep the answer in the project file.
• The purchasing route is confirmed with the purchasing office. Whether a formal solicitation is required at the expected value, and whether a cooperative or statewide contract already covers the scope. Thresholds and rules come from state law and local policy and differ between agencies. If no, ask the purchasing office first, because the route sets the schedule.
• The approval path and the calendar are mapped to real dates. Who approves release, who approves award, which governing body meeting dates apply, and how fiscal year close and peak service periods affect them. If no, work backward from the date the system must be in service and mark each decision point.

Requirements you can test

• Every mandatory requirement describes behavior someone can verify at acceptance. Requirements are sorted into mandatory and desirable, and the mandatory list is short enough that you would actually reject a proposal that missed one. "User friendly" cannot be verified. "A resident can submit an application from a phone without creating an account" can. If no, rewrite the untestable items and re-sort the list.
• Each integration is named with system, owner, direction, data, and method. Not "integrates with our financial system" but which product, what data moves, which direction, how often, and by what method. If no, contact each system owner and confirm whether an interface exists, what it costs, and which budget pays for it.
• The data to be migrated has been examined, not just counted. Formats, duplicate and incomplete records, retention requirements, and what will be archived instead of moved. If no, pull a sample and review it before committing to a migration schedule.
• The data classification is settled, and security, privacy, and hosting requirements follow from it. Criminal justice, health, student, and other personal information are each governed by rules that can constrain hosting location, access, background screening, and vendor agreements. If no, classify the data first and involve counsel or the privacy officer where the classification is unclear.
• Accessibility is written in as a requirement with a named standard. State the standard and version the agency follows, require a current conformance report at delivery, and require remediation of defects found after acceptance. If no, add the requirement before release and confirm the standard with whoever handles accessibility at the agency.

People and the evaluation plan

• Owners are named and their time is reserved. An executive sponsor, a day-to-day project owner, a named owner of the system after go-live, and an estimate of staff hours for configuration, testing, data cleanup, and training. If no, name the owners and arrange coverage or backfill before committing to a schedule.
• The evaluation committee is identified and members have confirmed the dates. Members know when proposals arrive, when scoring is due, and when demonstrations are planned, and conflict of interest disclosures have been collected in the form the purchasing office uses. If no, confirm availability before publishing a schedule you cannot keep.
• Evaluation criteria and weights are drafted and reviewed with purchasing before release. Including how price is scored against approach, qualifications, and references. If no, draft them now, because criteria settled after proposals arrive are harder to defend if the award is challenged.
• Demonstration scenarios are written by the agency. Your cases, your terminology, and your difficult examples, run by the vendor on its own system, with a time limit and a scoring sheet. If no, write the scenarios before release so every vendor is evaluated on the same tasks.
• Market research is far enough along to know what the market offers. Requests for information, demonstrations, published contracts from other agencies, and conversations with peer agencies that bought something comparable. If no, do it before drafting, so the requirements are not copied from one vendor's materials.

What to do with the results

Sort the no answers into three groups. Items that must be closed before release, such as funding confirmation, scope boundaries, data classification, and the purchasing route, each get an owner and a due date, and the release date moves if they are not met. Items that can be closed during the solicitation period, such as demonstration scripts and reference questions, go on a working list with dates. Items that are genuinely not applicable get a one-line note saying why, so the question does not come back later.

Keep the completed checklist in the project file. It records the decisions behind the requirements, and it gives whoever runs the next purchase somewhere to start.

HQT provides solicitation readiness reviews, requirements definition, and independent technical evaluation support for technology purchases, and does not bid on solicitations it helped write.

Frequently asked questions