Pretty much every agency has a version of the same government software procurement story. A modernization project launches with urgency. There is a permit system running on Access or some other legacy system, an inspection workflow living in spreadsheets or a compliance process that relies on someone’s institutional memory. After leadership approves a budget, there’s a monumental effort to scope the project and then a lengthy RFP is posted. A vendor wins. And then, somewhere between the signed contract and the go-live date, something goes wrong. The project strays, expenses increase and people aren’t happy with the outcomes.
The procurement response is usually to tighten the next RFP with more requirements, more rigid statement-of-work language and more documentation.
Here’s the problem: for modern regulatory software, that instinct makes the problem worse.
Traditional procurement was designed for fixed, predictable projects, like bridges, buildings, infrastructure with well defined and known specifications. It wasn’t designed for software systems that should evolve alongside changing regulations, shifting policy priorities, and the institutional knowledge of the program locked in the heads of program staff. When agencies apply a construction-era procurement model to a living, complex software system, they don’t reduce risk. They just temporarily push it under a rug.
There is a better approach. Instead of asking, “what’s the perfect solution?” This approach starts with a different question: “how do we most effectively get to a great solution?”
Why Traditional Government RFPs Create More Risk, Not Less
The logic of a traditional RFP is straightforward: the agency defines every requirement up front, vendors bid a fixed price, and the winner delivers what’s in the spec. It feels rigorous. In practice, it often fails to deliver satisfying results.
Regulations and how we work don’t hold still. By the time a 12-to-18-month RFP process concludes and a vendor comes up to speed, new federal mandates, state legislation, or practices may have already shifted portions of the original requirements and agency process.
The deeper problem is alignment. Written requirements ask every stakeholder to agree on a description of how software will work before anyone has seen it work. It also expects stakeholders to break highly complex and interconnected rules and processes down into short and distinct descriptions. Due to their nature, these requirements often lack the glue that binds those descriptions to their holistic context.
Business analysts, developers, subject matter experts, and vendors each read the same language and build a different mental model of the end product. Nobody knows they’re misaligned until the system is built and staff see, for the first time, what they actually signed off on. By then, the gap between expectation and reality gets resolved through change orders, delays, and political friction.
Traditional procurement doesn’t prevent these problems. It just makes task owners (who get the blame if things go wrong) clear.
Five Ways Traditional RFPs Fail Government Software Projects
Frozen requirements in a moving regulatory landscape. Regulatory programs deal with new federal rules, evolving state policy, and shifting priorities like PFAS tracking, environmental justice mandates, climate resilience requirements. Traditional RFPs lock in form fields, workflows, and data models as if none of that will change. It always does, and change orders follow.
The lowest-bid illusion. RFP scoring that overweights price creates a predictable dynamic: vendors underbid to win, then rely on change orders to recover margin once the real complexity surfaces. The agency selects on paper confidence, not on demonstrated capability. The vendor who promises the most for the least is rarely the one who delivers the highest value.
Specs no one truly shares a mental model of. “The system shall…” requirements are interpreted differently by every reader. “As a , I want so that…” user stories are just marginally better. Program staff, IT, compliance officers, and vendors each fill in the gaps with their own assumptions. The misalignment is invisible until it becomes a defect — usually late in development, when fixing it is maximally disruptive.
Vendor and platform lock-in by contract. A single-vendor, multi-year contract that ties your workflows and data models to a proprietary platform creates an exit problem. When something goes wrong — and in large IT projects, something always does — switching course is politically costly and technically painful.
No room for learning. The traditional model assumes you know the right solution before you build it. In reality, agencies learn the most in the first months of actually using a system. A contract structure that penalizes change and makes iteration expensive doesn’t reflect how regulatory software actually has to work over a five-to-ten-to-twenty-year system lifespan.
A Better Model for Government Software Procurement
The alternative isn’t to abandon procurement discipline — it’s to reorder the sequence. Instead of writing a detailed spec before you understand the solution, start by understanding how people who develop great systems get them there (hint: it’s largely driven by focusing on user needs and incremental change). If possible, develop a POC that integrates some of the features that will make a big quality of life improvement for your team. Then write the procurement around what you’ve learned.
This approach applies human-in-the-loop principles at the procurement level: humans make key decisions at every stage, informed by real evidence rather than assumptions.
Start with a working prototype, not a written spec.
A great way to get started is to have a short design and prototype engagement. typically six to ten weeks with a modest budget. This should produce something a requirements document never can: actual screens and workflows that program staff can react to, approve, and correct. Use your existing paper forms, legacy screenshots, and subject matter experts as the raw material. The deliverable isn’t a document. It’s a set of visual designs reviewed by the people who will use them, and a working prototype demonstrating the core flows.
This step forces alignment early, when the cost of changes is less. When your permit reviewers, your IT team, and your compliance officer all react to the same screen, misunderstandings surface in days instead of years.
Layer complexity through iteration, not big-bang releases.
Use the prototype as the foundation for everything that follows. Rather than building the entire system and releasing it all at once, add functionality in focused, timeboxed phases. Each phase produces working software that staff can use and respond to. The prototype evolves into the production system incrementally — which means problems surface and get resolved continuously, not catastrophically at go-live.
Require technical independence in your RFP language.
This is where procurement language can do real work. Shift your RFP from asking for a “turnkey platform” to specifying what ownership actually looks like:
- Designs must remain editable by agency staff as program needs evolve.
- Non-technical users should be able to drive simple changes.
- Application code should be readable, maintainable and committed to Git, bringing a sense of ownership to the agency.
- The system must be able to be maintained by your internal team or a different partner if circumstances change.
Your Next Step: Rethink the Pilot
The most effective change you can make right now is structural: carve out a Design & Prototype phase. If possible, do this before your next full RFP. If that’s not possible, integrate government software RFP best practices into your next project from the start, focusing on iterative improvement rather than rip-and-replace approaches.
Here’s how that looks in practice.
1. Choose one contained program to start.
Resist the temptation to pilot everything at once. Pick a single, meaningful slice of work — one permit type, one inspection workflow, one complaint intake process. It should be representative enough to prove the approach, but small enough that you’re not betting the agency on the outcome. A well-chosen pilot gives leadership a credible proof point; a sprawling one gives them another IT project to explain to the legislature.
2. Run a short design and prototype engagement — before biting off the whole thing.
Give yourself 6–10 weeks and a modest budget to focus on that one area of improvement. Use your existing paper forms, legacy screenshots, and subject matter experts as the raw material. The deliverable isn’t a requirements document — it’s a set of visual form and workflow designs, reviewed and approved by the program staff who will actually use them, and a working prototype demonstrating the core flows. Be sure to include designated time for the team to collectively reflect on what’s working and what’s not, taking notes for the next phase.
This step does something a 200-page spec never can: it forces alignment early, when changes are cheap. When your permit reviewers, your IT team, and your compliance officer all react to the same screen, misunderstandings surface in days instead of in year two of a contract.
3. Turn those prototype artifacts into the specification and mature solution.
Whether doing so within a larger RFP or taking a pilot approach. Carry screens and workflow diagrams directly to your next phase. Require vendors to explain — specifically, not generically — how they will extend those designs, integrate with your existing systems, and preserve your ownership of the code and configuration over time.
This shifts the vendor-agency relationship from being intentions-based to a demonstrating understanding and alignment. Vendors who can’t engage with real designs at the proposal stage won’t magically improve in the future.
4. Score on approach, not just price.
Discuss and define expectations for how vendors handle change and new information. Ask them: What happens when a regulation shifts mid-project? How do program staff participate in ongoing design decisions? What does your handoff process look like if we need to bring in a different partner in year three?
The vendor who answers these questions well — even if their price is higher — is almost always the lower-risk choice. The one who can’t answer them is telling you something important.
5. Build iteration into the contract from day one.
Define short, timeboxed delivery phases — 8 to 12 weeks each. Require working software at the end of every phase, not just documentation or status reports. Build in explicit review points where program staff can react to what’s been built and where scope can be adjusted within the approved budget.
This isn’t agile for the sake of being agile. It’s about making sure that the first time your staff sees the real system isn’t also the first time your vendor asks for a change order.
Why This Is Safer for Leadership
A phased, design-first approach gives agency directors something traditional RFPs cannot: a defensible record of how decisions were made.
You start with a modest engagement. If it works, you expand. If it doesn’t, you haven’t lost millions — and you still own the designs and the code as agency assets. The risk profile of incremental change is fundamentally different from a five-year build-everything commitment.
At every phase, you can show oversight bodies, legislative committees, and auditors exactly how the system evolved from a regulatory requirement to a visual design to a working application. You can demonstrate that requirements were reviewed and approved by program staff. You can show the Git history of every change and the human decision that preceded it.
That’s not a side benefit. For agencies operating under public scrutiny, it’s the whole point. The goal isn’t just a better project — it’s a project record that holds up.
Fix the Process, Not Just the Technology
Traditional RFPs weren’t designed for the kind of adaptive, long-lived, complex software your agency now depends on. When people try to force certainty where uncertainty is inherent, they drive the very failures they’re trying to prevent.
By rethinking how you define, test, and procure modern systems — starting with design and prototypes, insisting on keeping the process human-centered and flexible you can modernize more effectively, reduce risk, and maintain the control and accountability your mission demands.
Don’t wait for the next multi-million-dollar failure to change your approach. Start with your next RFP: carve out a design and prototype approach, and build the rest of the procurement around what you learn.
Schedule a HAGE consultation to see what a design-first pilot can look like for your agency.