Healthcare.gov's Implementation Failure

Big Money, High Stakes

IT implementation is described inside consulting firms as bread-and-butter work, and the description undersells the scale involved: dozens of consultants, multiple locations and sometimes two to three years to fully roll out an enterprise resource planning system.1 These are large, complex projects that regularly cost hundreds of millions of dollars, feeding not just the technology arms of major consulting firms but strategy, human capital and program management practices alongside them. Marquee client lists for this kind of work, spanning technology, industrials, government and consumer goods, illustrate just how central implementation work has become to the consulting business model.

A High-Profile Failure

The most closely watched IT implementation story in recent memory was the botched launch of a major government healthcare marketplace website, intended to connect buyers and sellers of health insurance and bring more than 34 million uninsured Americans closer to coverage by linking to 36 separate state exchanges.2 It did not work as planned. Site visitors were greeted with error pages and endless loading screens rather than a functioning marketplace, an outcome made worse by the scale of what the project was supposed to achieve.

Measured Against a Known Checklist

A widely cited list of common enterprise resource planning mistakes offers a useful scorecard, and the launch matched an uncomfortable number of items on it, including poor planning, inadequate vendor vetting, underestimating required time and resources, failing to set clear priorities, underinvesting in training and change management and underestimating the importance of accurate data.3

Vendor Selection Went Wrong

Whichever vendors were selected for the build, the results suggest the selection process failed on some level: the work did not meet basic functional standards, and the vendors reportedly did not flag serious risk to the client with enough urgency to prevent a very public breakdown. The aftermath consumed weeks of congressional testimony, with parties largely pointing at each other rather than at a shared root cause.

The Schedule Was Too Tight

One vendor reportedly acknowledged, roughly a month before launch, that the compressed schedule left inadequate time for proper performance testing, a warning that apparently went unheeded at a level senior enough to change course.

Priorities Were Never Set

Independent analysis after launch found the site required users to download dozens of separate files and scripts just to complete a basic application, with the volume of data passed back and forth so heavy that the system reportedly behaved as though it were attacking itself under normal user load.

Training Failed at the Worst Moment

Perhaps the most avoidable failure: while users were locked out and flooding customer service lines for help, support representatives were reportedly working from an outdated script, instructing frustrated users to reset passwords in a way that appears to have made the underlying problem worse rather than better.

The Broader Pattern in Government IT

The failure was unusual in scale and visibility, not in kind. Large government technology projects have a documented history of running over budget, over schedule or both, often for the same root causes that surfaced here: compressed timelines set by political rather than technical considerations, vendor selection processes that reward the lowest bid over demonstrated capability and a reluctance to delay a politically important launch date even when the underlying system is not ready. None of that excuses the specific execution failures, and all of it explains why similar stories keep recurring across administrations and agencies.

What a Red Team Would Have Caught

One detail that surfaced after the fact deserves more attention than it usually gets: an internal review process, sometimes called a red team, had reportedly flagged risk factors ahead of launch that closely foreshadowed what actually went wrong. A red team's entire purpose is to argue against a project's own assumptions before an external audience ever sees it, deliberately hunting for the failure modes a delivery team is too invested to notice on its own. When that kind of internal warning exists and does not change the launch decision, the failure is not really about the underlying technology at all. It is a governance failure, a case where the organization had the right information and no mechanism forceful enough to act on it in time.

Data Quality Was an Afterthought

Insurance companies receiving applications through the system reported incomplete and duplicate submissions, a data-quality failure with real downstream consequences for actual coverage decisions. Whatever one's view of the underlying policy goals, the consensus was near-universal that the technical execution fell well short of what the stakes demanded, and it remains one of the clearest object lessons in why implementation discipline matters as much as strategic ambition.

• 1Enterprise resource planning
• 2HealthCare.gov
• 3IT project management