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 tracked federal IT investment performance over multiple review cycles and consistently found that large programs — those with the highest cost and longest duration — have the worst on-time, on-budget and on-scope delivery rates. State programs follow a similar pattern. The 18F De-risking Government Technology guide, published by the US General Services Administration's technology practice, identifies the structure of the procurement itself — particularly large, fixed-price, waterfall contracts — as a primary driver of those failures, separate from vendor competence.
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.
The states that have navigated this transition successfully — including California's work on modular eligibility system components, discussed in the 18F De-risking Guide — did not start with the full modular architecture. They built the product management capability first and then used it to manage increasing procurement complexity.
Why this matters now
State IT projects are under concurrent pressure: ARPA SLFRF closeout is forcing programs to assess sustainability, federal matching funds for Medicaid eligibility technology remain available but require demonstrable progress, 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 has helped state technology programs conduct pre-procurement technical architecture assessments, define module boundaries, and establish the product ownership function before a competitive acquisition. That preparation work is usually the most consequential investment a program can make before a major modernization award.
Sources and further reading
- 18F / GSA, De-risking Government Technology Guide — practical guidance on modular contracting, vendor management, and agile acquisition for government programs.
- USDS, Digital Services Playbook — foundational plays on contracting, procurement and product ownership for federal and state programs.
- GAO, Information Technology: Agencies Need to Fully Implement Key Program Management Practices (GAO-16-469, 2016) — documents persistent failure patterns in large IT programs and the management practices that distinguish better-performing programs.
- National Association of State Chief Information Officers (NASCIO), annual state CIO survey — tracks state IT priorities, staffing and budget challenges that affect procurement capacity.
