Why large IT contracts fail structurally
The failure pattern in large state IT programs is well-documented. A single vendor holds the entire scope under a contract where cost and schedule are visible but the real risk — whether the requirements as written actually describe the right system — is not. When requirements change, as they always do, the agency has limited leverage: the vendor relationship is too valuable to terminate, the switching cost is too high, and renegotiation typically produces a change order rather than a redesign.
The Government Accountability Office has repeatedly reported that federal IT projects often fail — in its words, "even after exceeding their budget by millions of dollars and delaying the schedule by years, the result does not meet requirements" — and that long-term system development projects have historically produced disappointing results (GAO-16-469, August 2016). GAO's findings cover federal investments; state programs face similar structural pressures, though this article does not cite a comparable state-level dataset. The 18F De-risking Government Technology guide, originally published by 18F, the General Services Administration technology team that GSA eliminated on March 1, 2025 (Nextgov) (an archived copy is maintained by former 18F staff), warns that pursuing a large, complex system "through one big contract" makes a project "more likely to fail because it doesn't account for changes in agency needs" (buying development services), and that the waterfall method increases failure risk because it "falsely presumes that all needs can be accounted for before a project starts" (principles).
The core problem is risk concentration. A procurement that prices the full scope of a multi-year system before the requirements are understood forces both the agency and the vendor into a contractual fiction. The vendor prices risk into the bid. The agency accepts an overstated scope to satisfy the solicitation requirements. Neither party can course-correct without blowing through the contract structure. By the time a steering committee agrees the system is not delivering, the agency is years into a relationship with no clean exit.
What modular contracting is actually asking for
Modular contracting — the practice of breaking IT work into smaller, independently deliverable components procured under separate contracts — is the architectural answer to that structural problem. Each module delivers working software against defined acceptance criteria. A failing vendor can be replaced without bringing down the whole program. The agency maintains leverage because the relationship is bounded.
But modular is not simply "smaller contracts." It requires a set of organizational capabilities that fundamentally change where the program risk lands:
Integration architecture before vendors. In a modular approach, the agency must define the seams between modules — the data formats, API specifications, and service boundaries — before the first module is procured. If two modules interact through an undefined interface, the integration work becomes the hidden waterfall project inside the modular structure. The agency, not a vendor, owns that definition. Most state IT shops are not structured to produce integration architecture documentation at procurement-grade specificity before a vendor is engaged.
In-house product ownership. Modular procurement shifts the responsibility for the overall product roadmap from the vendor to the agency. Someone inside the program needs to own the user needs, the priority sequencing, the acceptance criteria for each module, and the decisions about what gets built next. That role is distinct from a contracting officer's or a project manager's function. It requires technical judgment, direct access to end users, and institutional authority. States that have tried to run modular programs without this role find that module coordination becomes an informal negotiation between vendors rather than a managed product decision.
Vendor management bandwidth. Running three or four vendor relationships simultaneously requires more procurement and contract management capacity than running one. Each vendor needs a statement of work, a set of deliverables, and someone at the agency who can evaluate whether the working software meets the acceptance criteria. States with lean IT offices often discover that the administrative overhead of modular procurement exceeds what their staff can absorb — not because modular is wrong, but because the capacity assumption was not examined before the procurement launched.
The three conditions for a realistic readiness assessment
Before committing to a modular approach, the following questions require honest answers — not aspirational ones:
1. Can your agency define the module boundaries before issuing the first solicitation?
Not approximately, and not in the solicitation itself. The integration architecture needs to exist as a draft, reviewed by technical staff, before vendors bid. If the answer is no — if the system's requirements are not yet understood well enough to draw the module boundaries — a discovery phase is the prerequisite, not the first module.
2. Do you have a named, empowered product owner with technical authority?
This person should be able to reject a deliverable because it does not meet user needs, not only because it misses a specification. If the person who will serve that function does not yet exist inside the agency, identify how you will fill that role before the first contract is awarded. A contractor product owner is a significant conflict of interest in a multi-vendor environment.
3. Does your procurement and contract management office have the bandwidth to run concurrent awards?
A realistic estimate includes not just issuing solicitations but managing vendor performance, processing deliverable acceptance, handling any protests, and issuing modifications across multiple active contracts. If your current capacity is stretched on a single large contract, the question is whether additional procurement staff will be funded — not whether the theory of modular is correct.
When the conditions are not yet in place
The conclusion is not to fall back to a large waterfall contract. The risk profile of a traditional big-bang procurement is well-understood and generally worse. The question is how to de-risk a program when full modular is not yet executable.
Several contract provisions materially reduce risk in a single-vendor relationship without requiring the full product management infrastructure that modular demands:
Time-boxed work orders against outcomes, not just deliverables. Structure work in phases of six to twelve months, each with defined outcomes that must be demonstrated before the next phase is funded. This is not the same as modular, but it provides real re-compete leverage at each decision point.
Source code, data, and documentation access from day one. Require that all work product is delivered to the agency continuously, not at project close. This reduces switching costs if the relationship needs to end and prevents the vendor from holding the codebase as leverage.
Explicit re-compete triggers. Define in the contract the conditions under which the agency will issue a competitive solicitation for continued work — a missed milestone, a failed demonstration, or a change in scope exceeding a defined threshold. Making this explicit at award is easier than negotiating it when the relationship is already troubled.
A dedicated acceptance function. Even in a single-vendor contract, establish a team inside the agency whose job is to evaluate whether delivered software meets user needs, not just whether it meets specification. This builds the organizational muscle for eventual modular management.
The path from here
For agencies that have diagnosed their large-contract risk and want to move toward modular over time, the sequence matters:
- Fund a time-boxed discovery phase (eight to twelve weeks) under a small contract or existing vehicle to map current system behavior, identify the real integration points, and produce a draft module boundary definition. Do not procure the first module until this work is complete.
- Define the integration architecture before the first solicitation. This includes data models, API contracts, and the sequencing logic for how modules will be built and connected. Publish this as part of the procurement so bidders understand the technical context.
- Establish the product owner role explicitly in the budget and org chart. This is not a temporary assignment for a project manager. It requires dedicated headcount and the authority to accept or reject deliverables.
- Start with one module in a bounded scope before running concurrent procurements. Build the acceptance and vendor management muscle before adding complexity.
California's child welfare system modernization shows what a modular start looks like: by early 2016, with help from 18F, the state had replaced a 1,500-page monolithic solicitation with modular procurements built around a 10-page statement of work, as 18F described in March 2016 (18F team blog post, archived copy maintained by former 18F staff at blog.18f.org). How that program has fared since is outside this article's sourcing. Our recommendation, which is judgment rather than a documented finding, is to build product management capability first and add procurement complexity as that capability matures.
Why this matters now
State IT projects are under concurrent pressure: most ARPA SLFRF funds obligated by December 31, 2024 must be expended by December 31, 2026 or returned (31 CFR 35.5), and closeout is now forcing programs to assess sustainability, federal 90 percent matching funds for Medicaid eligibility and enrollment systems remain available, but only under CMS-approved advance planning documents and conditions that include using "a modular, flexible approach to systems development" (42 CFR 433.112), and legacy mainframe retirements are creating deadlines that cannot be moved. The procurement structure chosen in the next eighteen months will determine which programs deliver and which become the next cautionary case study.
The structural answer to large-contract failure is real. Getting there from current agency capability requires an honest capacity assessment before the solicitation — not a structural assumption that modular is simpler than it is.
Spartan X brings enterprise architecture and systems integration experience from state technology work in Colorado and Florida to exactly this kind of pre-procurement assessment: mapping integration points, testing whether module boundaries are drawable, and sizing the product ownership role before a competitive acquisition. That preparation is usually the most consequential investment a program can make before a major modernization award.
Sources and further reading
- 18F (GSA; eliminated March 1, 2025, per Nextgov), De-risking Government Technology Guide — archived copy maintained by former 18F staff (archive banner dated January 20, 2025); guidance on budgeting, buying custom software through performance-based services contracts, and vendor management.
- U.S. Digital Service (now U.S. DOGE Service), Digital Services Playbook — 13 plays, including structuring budgets and contracts to support delivery (Play 5) and assigning one accountable leader (Play 6).
- GAO, Information Technology Reform: Agencies Need to Increase Their Use of Incremental Development Practices (GAO-16-469, August 2016) — finds significant inaccuracies in agencies' IT Dashboard reporting of whether major IT software projects delivered usable functionality every six months (about half of the projects GAO reviewed reported doing so), and notes that long-term system development projects have historically produced disappointing results.
- National Association of State Chief Information Officers (NASCIO), annual state CIO survey — tracks state IT priorities, staffing and budget challenges that affect procurement capacity.
