HealthCare.gov didn’t fail at launch because building a website was too difficult. It failed because an enormously complex program was allowed to reach go-live without proving it was ready.
More than a decade later, the troubled 2013 launch of HealthCare.gov remains one of the most valuable case studies in enterprise project management.
And this isn’t a political article.
Whether you supported or opposed the Affordable Care Act is irrelevant to the project-management lessons. Strip away the politics and HealthCare.gov starts looking remarkably similar to many troubled ERP and digital-transformation programs I’ve encountered.
Multiple vendors.
Changing requirements.
A fixed deadline.
Complex integrations.
Unclear accountability.
Testing compressed toward the end.
Executives receiving warning signs but continuing toward go-live.
And eventually:
The date became more important than readiness.
Sound familiar?
The Project Was Enormously Complex
HealthCare.gov wasn’t simply a public-facing website.
The federal marketplace had to support eligibility, enrollment, plan selection and other functions while exchanging information across numerous government and private-sector systems.
The Department of Health and Human Services Office of Inspector General later reported that CMS awarded 60 contracts across 33 companies supporting the Federal Marketplace.
Think about that from a program-management perspective.
Dozens of contracts.
Multiple contractors.
Multiple systems.
Government agencies.
External organizations.
Policy requirements.
Security requirements.
A massive consumer-facing application.
And one immovable date:
October 1, 2013.
Complexity itself wasn’t the failure.
Complex programs can succeed.
The question is whether the governance structure is strong enough to manage that complexity.
In this case, government investigators concluded that it wasn’t.
Lesson #1: Someone Has to Own the Whole Program
This may be the most important lesson from HealthCare.gov.
The HHS Office of Inspector General conducted an extensive case study that included interviews with 86 current and former HHS and CMS officials, employees and contractors, along with reviews of thousands of documents.
One of its most important conclusions was the absence of clear leadership.
The OIG found that this contributed to delayed decisions and unclear project responsibilities. It also reported that CMS had not assigned a project leader with a centralized vision of what needed to happen and when.
That should make every CIO, CFO and transformation executive uncomfortable.
Because I still see versions of this today.
The implementation partner owns configuration.
Another vendor owns integrations.
Another owns data.
Another handles testing.
The business owns requirements.
IT owns infrastructure.
Finance owns the budget.
Executives sit on the Steering Committee.
Everyone owns a piece.
But who owns the outcome?
Vendor management is not program management.
Having several excellent vendors doesn’t automatically produce an excellent program.
Someone on the client side needs authority and accountability across the entire transformation.
Lesson #2: A Deadline Is Not a Readiness Assessment
October 1 was the launch date.
As that date approached, however, warning signs were accumulating.
GAO later found that CMS delayed key governance reviews. An assessment of marketplace readiness originally expected much earlier was pushed to September 2013—just weeks before launch.
According to GAO, HealthCare.gov ultimately launched without verification that the system met performance requirements.
This is one of the most dangerous behaviors in enterprise implementations.
At some point, leadership stops asking:
“Are we ready?”
and starts asking:
“What do we have to do to hit the date?”
Those are very different questions.
I’ve seen ERP programs reach the same point.
Testing isn’t complete.
Data isn’t clean.
Integrations aren’t stable.
Training is behind.
Critical defects remain open.
Business processes haven’t been proven end to end.
But the organization has announced the date.
Travel has been booked.
Consultants are scheduled.
Executives have communicated the launch.
So momentum takes over.
Go-live becomes a commitment instead of a decision.
A mature PMO needs the authority to say:
We may have planned to go live on this date, but the evidence does not support doing so.
That’s not project failure.
Sometimes that’s project leadership.
Lesson #3: Integration Testing Is Not Something You Squeeze In at the End
GAO later found that HealthCare.gov and its supporting systems were not fully tested before launch.
Testing documentation also lacked important elements, including criteria for determining whether systems had actually passed tests. GAO concluded that CMS therefore had limited assurance the systems would perform as intended.
This lesson should be printed on the wall of every ERP program office.
A Finance module can work.
Warehouse Management can work.
CRM can work.
EDI can work.
Your payment provider can work.
Your tax engine can work.
Your data warehouse can work.
Your e-commerce platform can work.
And your implementation can still fail.
Why?
Because:
Component readiness ≠ enterprise readiness.
The question isn’t whether each individual system works.
The question is whether the entire business process works across all of them.
Quote-to-cash.
Procure-to-pay.
Plan-to-produce.
Order-to-fulfillment.
Record-to-report.
You don’t discover whether those processes work from PowerPoint status reports.
You prove it through end-to-end testing.
Lesson #4: Changing Requirements Have a Price
GAO found that changing requirements and CMS decisions contributed to cost increases, delays and wasted contractor effort.
For two major areas examined by GAO, obligations increased substantially. Federal marketplace obligations grew from approximately $56 million to more than $209 million, while data-hub obligations increased from approximately $30 million to nearly $85 million between September 2011 and February 2014.
Requirements change.
That’s reality.
Especially on complex transformation programs.
The problem isn’t that requirements change.
The problem is pretending those changes don’t affect:
- Scope
- Budget
- Resources
- Architecture
- Testing
- Training
- Schedule
- Risk
You cannot continually change one side of the project-management triangle and pretend the other sides remain fixed.
Eventually reality sends the invoice.
Lesson #5: Red Status Means Nothing If Nobody Acts on It
One of the most fascinating parts of the HealthCare.gov story is that the problems weren’t entirely invisible.
There were warning signs.
GAO reported that CMS had identified significant contractor performance concerns as the deadline approached. By September 2013, program officials were concerned enough that they moved operations to the marketplace contractor’s offices to provide onsite direction.
Yet the launch continued.
This is something every Steering Committee should think about.
I’ve seen projects with beautiful RAID logs.
Executive dashboards.
Red-yellow-green indicators.
Weekly status meetings.
Risk registers.
Escalation procedures.
And absolutely no meaningful action.
A red status isn’t governance.
What leadership does because something is red is governance.
If the same critical risk appears on a Steering Committee deck month after month, it may no longer be a risk-management problem.
It may be a leadership problem.
Lesson #6: Your System Integrator Cannot Own Your Business Outcome
HealthCare.gov involved many contractors, but CMS remained accountable for the overall program.
That distinction matters.
Your implementation partner can own contractual deliverables.
They can configure the software.
Develop integrations.
Migrate data.
Resolve defects.
Provide consultants.
But they cannot ultimately own whether your organization succeeds.
The client must retain ownership of the transformation.
This is why I strongly believe large ERP programs need strong client-side program leadership.
The implementation partner manages its scope.
The client-side PMO manages the outcome.
Those aren’t the same thing.
Lesson #7: Project Recovery Requires Changing the Operating Model
Here’s the part of the HealthCare.gov story that gets discussed far less.
They recovered.
The initial launch was extremely problematic, but that wasn’t the end of the program.
CMS and its contractors took corrective actions. The organization changed how the effort was being managed, addressed capacity and software issues, improved quality reviews and continued development.
By the second open-enrollment period, the HHS OIG reported that operations ran smoothly.
That’s an important project-recovery lesson.
A troubled implementation isn’t necessarily doomed.
But recovery usually requires more than telling everyone:
“We need to work harder.”
You may need to change:
Governance.
Leadership.
Decision rights.
Vendor accountability.
Testing.
Priorities.
Communication.
Resources.
And sometimes vendors themselves.
You cannot recover a failing program while protecting every decision that created the failure.
The Lesson We Still Haven’t Learned
Here’s what surprises me.
HealthCare.gov launched in 2013.
Yet more than a decade later, I can walk into a troubled ERP implementation and see many of the same symptoms.
Unclear ownership.
Multiple vendors pointing at each other.
Incomplete requirements.
Weak client-side PMO leadership.
Compressed testing.
Late integrations.
Changing scope.
Executive pressure to maintain the date.
Risks being documented instead of resolved.
Training pushed toward go-live.
Business readiness confused with technical readiness.
We’ve changed the technology.
We’ve moved to the cloud.
We’ve adopted Agile.
We’ve implemented DevOps.
Now we’re adding AI.
But the fundamental principles of enterprise transformation haven’t changed nearly as much.
Technology doesn’t eliminate the need for governance.
Agile doesn’t eliminate accountability.
AI doesn’t eliminate leadership.
And a green project dashboard doesn’t mean your organization is ready.
Perhaps the biggest lesson from HealthCare.gov is remarkably simple:
Go-live should never happen because the calendar says you’re ready.
Go-live should happen because the evidence says you’re ready.
Before your next Steering Committee approves a major launch, ask one question:
If the launch date disappeared from the calendar today, would the evidence still tell us to go live tomorrow?
If the answer is no, you may have just learned the most important lesson HealthCare.gov taught us.