Full utilisation looks like efficiency. Every team member is assigned. Every sprint is fully loaded. No capacity is sitting idle. Leadership reports that teams are working at capacity, which is presented as evidence that resources are being used well.
Forsgren, Humble, and Kim identify this as one of the most reliable predictors of low delivery performance: not because full utilisation causes people to work badly, but because full utilisation eliminates the slack that a complex system needs to absorb the coordination overhead, unplanned work, and integration failures that are not exceptions in software delivery — they are the default conditions. When slack is zero, every unexpected event becomes a crisis. Every integration failure blocks everything downstream. Every unplanned requirement displaces a planned one, on a timeline that cannot absorb the displacement.
Healthcare.gov is the largest documented case of this pattern causing a nationally visible failure. The GAO's February 2014 post-mortem found that teams were operating under conditions that left no capacity for the integration testing and cross-team coordination that the system's complexity required. The result was a launch that processed 1% of the intended concurrent user volume before failing.
What the GAO post-mortem established
The GAO's report — Healthcare.gov: Ineffective Planning and Oversight Practices Underscore the Need for Improved Contract Management — identified several structural failures in the project's execution. Among the most consequential: the project had no single integrator responsible for end-to-end system testing, teams were operating independently against their individual component deadlines without integrated testing, and the absence of end-to-end testing meant that integration failures were not discovered until launch.
The structural cause of the absent end-to-end testing was not a lack of awareness of its importance. It was a resource allocation structure in which every team's capacity was committed to component delivery, with no capacity reserved for the integration work that a 55-contractor project required. Full utilisation on component delivery meant zero utilisation on system integration — and zero utilisation on system integration meant that a system involving insurance marketplaces, federal data services, and state systems was tested as a whole system for the first time on its public launch date.
"CMS did not have adequate procedures for overseeing the development of Healthcare.gov. End-to-end testing of the system was not completed prior to launch because teams were operating against individual component deadlines, with no integrating structure that would have required cross-component testing as a precondition for launch. The absence of this testing meant that integration failures were not identified until the system was under public load."
Accelerate's research provides the quantitative context. Teams operating at 80–100% utilisation have lead times approximately twice as long as teams operating at 50–65% utilisation. The counterintuitive result — that reducing nominal utilisation increases actual throughput — is explained by queuing theory: at high utilisation, the queue of unplanned work that always exists in complex systems backs up indefinitely. The work does not disappear. It accumulates, blocks higher-priority items, and produces the coordination overhead and context-switching cost that reduces effective throughput below what any planning tool would predict.
What this means for AI project delivery
Enterprise AI projects are structurally predisposed to the Healthcare.gov failure mode for the same reason Healthcare.gov was: they involve a large number of teams — data engineering, ML platform, business unit analysts, risk and compliance, security, architecture — each with their own delivery commitments, and a system-level integration requirement that does not appear on any individual team's sprint board.
The integration requirement for an AI system is more demanding than for a conventional software system, because the interfaces are not just technical — they include data contracts (which team owns the schema?), model contracts (which team defines what constitutes acceptable model performance?), and governance contracts (which team owns the compliance case?). Each of these requires cross-team capacity. None of them will be scheduled unless capacity is explicitly reserved for them.
The integration capacity calculation
The practical resolution is not to reduce team utilisation as an end in itself. It is to budget explicitly for integration work before the project plan is finalised — and to treat integration capacity as a first-class delivery requirement rather than something teams are expected to absorb within their existing commitments.
For an enterprise AI project, the integration budget should include: end-to-end testing capacity (who runs it, when, and what does it test?), cross-team contract validation (who verifies that data contracts, model contracts, and governance contracts are mutually consistent?), and compliance integration (who confirms that the system as integrated satisfies the Article 9 obligations, not just each component in isolation?). Each of these requires named capacity. Without named capacity, they do not happen — and the Healthcare.gov pattern plays out at smaller scale in every AI project sprint review that ends with "we'll sort out the integration in the next sprint."
Before each sprint plan is finalised for an AI project involving more than two teams, run the integration capacity calculation. It has three inputs and produces one output.
Input 1: List every cross-team integration point that will be exercised or changed in this sprint — data contracts, model interfaces, API boundaries, compliance artefacts.
Input 2: Estimate the coordination time each integration point requires this sprint — review meetings, contract updates, testing, sign-offs.
Input 3: Add 20% for unplanned integration work (the Healthcare.gov finding is that unplanned integration work is not an exception — it is predictable overhead).
Output: That number is the integration capacity budget. Subtract it from the sprint's available capacity before any component work is planned. What remains is the capacity for new component development. If the integration budget consumes more capacity than was assumed, the sprint scope for component work must reduce accordingly. Not in the next sprint. This sprint, in the planning meeting, before the commitments are made.