Your next system should be better than your last one. Your RFP should give better companies a chance to build it.
See what to ask forKeep the requirements that protect your agency. Replace shortcuts that screen out capable companies before you see their work.
Evaluate sensitive data, financial accuracy, integrations, public access, and operational scale. Let vendors show how relevant experience transfers to your work. Check references for the people who will actually build your system.
Give every finalist the same realistic tasks and anonymized sample data. Watch a correction, an exception, an approval, and an export. Ask what works today and what still needs to be built.
Ask for an early usable release, regular demonstrations, and acceptance criteria for each milestone. Check original schedules and budgets against actual delivery, including later amendments and charges.
Compare implementation, all historical data, integrations, hosting, support, upgrades, and exports over the same term. Require vendors to identify exclusions and explain what happens when something doesn't meet the requirements.
Ask for applicable controls, current test results, manual accessibility review, a demonstrated restore, and a process for correcting findings. Check which claims cover the application and operations, rather than only the cloud provider.
A missed deadline should have consequences. Your agency should have more than a revised schedule and another invoice. Tie payment to accepted work, put a cost on avoidable delays, and keep the right to act when the vendor doesn't deliver.
Set these terms before award. Have your procurement and legal team define the amounts, triggers, exceptions, and remedies for your project and applicable law.
Tie milestone payments to requirements the agency has tested and accepted. Keep a meaningful final payment until conversion, performance, training, and launch criteria pass, followed by an agreed period of stable operation. Define what restarts that period, the review process, and payment deadlines. Using the system to keep services running should not automatically mean accepting unfinished work.
Consider daily or weekly liquidated damages for vendor-caused delay to critical milestones. Base the amount on a documented, reasonable estimate of likely agency costs, such as extended legacy operations and additional staffing. State when damages start, any limits, and how agency-caused delays or other excused events are handled. An arbitrary penalty is no substitute for a remedy the agency can enforce.
Set a deadline for reporting a missed commitment and submitting a recovery plan with named owners and dated actions. Require regular progress reports and escalation to someone authorized to fix the problem. The vendor should fund recovery from its own failures. A new schedule should not silently erase damages or other remedies already due.
Define how availability, response, and restoration commitments are measured, including exclusions. Require credits on the next invoice when a commitment is missed, without making staff chase a claim. Repeated or serious failures should trigger escalation and termination rights. A small credit should not become the agency's only remedy for a system that repeatedly fails.
Make every required record type part of conversion acceptance. Require counts by category, field comparisons, control totals, attachments, and linked history, with exceptions individually documented and approved. For a vehicle system, test recreational vehicles, boats, and trailers separately. An overall record count can hide a whole category that never made it across.
If a required category is missing, withhold acceptance and its milestone payment. Require the vendor to complete the conversion, reconcile the results, and repeat the tests at its expense. Requiring agency staff to type those records back in does not fulfill the conversion requirement.
If vendor failures force staff to reenter records, work overtime, or keep a legacy system running, the agency should not absorb those costs by default. Agree on recoverable costs, rates, evidence, notice, and approval in the contract. Keep a record of hours, affected records, and additional invoices.
For example, if an omitted record type requires manual reentry, require the vendor to fund the approved recovery work as well as fix the conversion. State how reimbursement interacts with delay damages and credits, without recovering the same loss twice.
A failed acceptance test should lead to correction and another test, with no increase in price. Set who pays for repeated agency or independent testing when vendor defects cause the failure. Apply this to the agreed accessibility, security, performance, integration, and conversion requirements.
If the vendor does not correct the failure within the stated process, reserve the right to have the required work completed elsewhere and recover the permitted costs. Define notice, cure, access, and cost-recovery rights before the problem occurs.
Specify refunds for prepaid services or deliverables that remain undelivered when the vendor defaults. Define the treatment of unusable partial work and how accepted, usable work is valued. Set the refund deadline, any permitted invoice offsets, and transition obligations. The agency should not have to pay a second company to finish while the first keeps payment for work it never delivered.
Define material failures, written notice, any cure period, and termination for cause. Require access to current source code, build instructions, documentation, and complete usable data throughout delivery. Set transition obligations and any right to recover completion costs where permitted. Review liability caps and exclusive-remedy clauses so they do not undo the protections you negotiated.
Federal examples: Liquidated damages policy · Acceptance and termination terms · Correction and recovery of costs. These illustrate procurement tools; state and local authority varies.
Reporting a bug shouldn't start a new sales conversation. Neither should discovering that required work was left out of the implementation price.
These examples give your procurement team a starting point for the solicitation and contract.
The proposer may demonstrate relevant experience through systems of comparable complexity, data sensitivity, integration requirements, and operational scale. Experience need not be in an identical product category. Identify the proposed delivery team's role, the results achieved, and references who can verify those results.
The contract price includes correcting defects and failures to satisfy the agreed requirements during implementation and the stated warranty or support term. Reporting, investigating, or correcting those failures does not incur a separate charge. The proposal must state the covered term, severity levels, response commitments, and escalation process.
The implementation price includes conversion of the identified historical records, attachments, and relationships, with no surcharge based on the age of a record. Define reconciliation checks, exception handling, and agency approval of the converted data before cutover.
Propose an early working release and regular demonstrations against agreed acceptance criteria. State milestone dates, dependencies, and total costs. Explain how staff feedback and evolving priorities will be incorporated within the agreed budget and delivery dates.
Identify ongoing charges, after-hours and holiday support, escalation contacts, and restoration commitments. Demonstrate end-user data exports and provide the API specification. State source-code and data ownership, access rights, and any transition charges before award.
A launch can be technically complete while staff and residents are still waiting. Readiness needs to cover the work at the counter, the accuracy of converted records, and the support available when something goes wrong.
In South Dakota, 605Drive launched on February 17, 2025. On March 7, the Department of Revenue reported title-processing times of three to four months, citing testing and training in preparation for the new system.
DOR launch announcement · DOR's March 2025 backlog notice
Teacher certification tells a similar story. In August 2023, five months after a new system launched, South Dakota education officials reported about 1,600 pending applications. KELO reported software glitches, difficulty handling transcript details, and overtime and reassigned staff to work through the backlog.
KELO's August 7, 2023 certification report
A public agency should not have to absorb the cost of unfinished software. Test the difficult cases before acceptance, agree on a recovery plan, and make the vendor responsible for the added work its failures cause.
We welcome clear acceptance tests, realistic deadlines, and fair consequences. A company that stands behind its work should be willing to put those commitments in writing. Hold us to that standard, and look at what we've delivered.
Bring us your difficult requirements, your deadline, and your budget. We'd welcome the chance to show you what we can do.
