A Lesson From the Affordable Care Act Rollout

Without commenting at all on the policy wisdom of the Affordable Care Act, it’s clear that the rollout of Healthcare.gov has been disastrous. This has been chronicled more diligently elsewhere, but can be summed up by noting that, while Healthcare.gov was plagued with bugs, crashes, and general confusion, a team of three college students replicated much of the desired functionality of the site in a few days.  Of course, the alternative site, HealthSherpa, does not handle the user or data scale of healthcare.com or perform the most complex operations of applying for coverage, but the contrast between a site built for free and the ~$600+ million obligated for healthcare.gov is sobering.

We can draw a few lessons from this affair.  The first is that it represents a deep structural problem of government IT projects. The process used to bid out and build healthcare.gov was not, contrary to what you might have heard, especially unique or nefarious.  On the contrary, it represents the norm for large federal IT projects: mandating what should be straightforward products to be built from scratch in many ponderous phases, replete with massive sets of requirements and a commensurately high number of billable hours. 

The major difference is that this time, the users are the American people. The frustration of grappling with subpar technology is the same experienced daily by some of the most vital people in our public service ranks.  Soldiers, intelligence analysts, law enforcement officers, and veterans care workers, to name just a few, are routinely forced to implement tools that are barely functional, told to simply “make it work”.  This is by no means meant to minimize the headaches associated with healthcare.gov – on the contrary, it points to the need for real, systemic change.

There are two fundamental flaws at work in the legacy government IT acquisitions model. The first is that the same procedures used to acquire tanks and aircraft carriers are used to build software. Yet software development is by nature a creative, generative, iterative process, not a static set of requirements that won’t change significantly over the lifecycle of the product.  And while good software is never truly finished, the essential building blocks can often be delivered right away - the key is that you’re creating a basis for iteration and creative enhancement, not obediently following the same blueprint for years at a time.

The second, and subtler, flaw is the failure to recognize that America in general, and Silicon Valley in particular, are unique in the ability to build software.  Many remarkable advantages of American life have contributed, in turn, to our dominance in software development. Pondering an increasingly data-driven future, our abundance of software talent has to be considered one of America’s most strategic resources, and leveraged and fortified accordingly. Sadly, in the current IT acquisition landscape, armies of contactors are paid by the hour to produce a crude facsimile of what our best software artists could create for a tiny fraction of the cost - but ignoring such a precious asset would be a mistake at any price.

One great irony of the healthcare.gov fiasco is that a major rationale for the Affordable Care Act was the idea that Americans can do better than the legacy healthcare system – only to see what should have been a slam-dunk website rollout crippled from the beginning by the IT acquisitions machine, another legacy system. Regardless of one’s views about the law itself, though, one saving grace is made clear: if we want to do better, doing what we’re already the very best at seems like a good place to start.

8 responses
most definitely the govt procurement process for software services is to blame for HealthCare.gov woes. Clay Johnson (former White House fellow) has discussed this issue for a while now and has started something called EZ-RFP that could be interesting. what's so short-sighted (and frustrating) is that by treating software as a commodity the govt will award LCTA (lowest cost technically acceptable) and put proposals through a whitewash where 15 years of experience maintaining COBOL systems is valued more than 5 years of Mark Zuckerberg's experience. so in the end LCTA ends up costing the taxpayers more money (because they eventually hire an army of mediocrity to do the job of a few) and they get less capability. guess the cherry on top, is that most recently HealthCare.gov awarded a sole source, not to the small innovative companies Shyam mentioned above, but to Accenture, another large govt contractor who has a history of projects that are over budget and behind schedule. even if you felt it was necessary for a big company to do the website, where was Amazon, Facebook, Google, etc in the competition?
7 visitors upvoted this post.