Obamacare Was a Mess at the Start. Here's Why that's Not Shocking.

by Jonathan Coopersmith

Jonathan Coopersmith, an Associate Professor of History at Texas A&M University, is the author of FAXED, a history of the fax machine (forthcoming from Johns Hopkins University Press).

The news reports sounded horrible: The unresponsive website frustrating tens of thousands of people by swallowing their data, refusing to accept their applications, and otherwise turning what should be a smooth process into an uncertain and ongoing ordeal. Obamacare’s Healthcare.gov, right? How about the Common App?

If you are a high school senior, parent of a high school senior, or a high school counselor, you know exactly what I mean. Over 500 colleges and universities use the Common App to receive applications from hundreds of thousands of high school students. Last fall, however, a new version created problems so severe that many schools had to delay their deadlines for accepting applications. Forget the dog ate my homework excuse; the computer actually swallowed my college application.

Healthcare.gov performed better than the Common App in one respect: You could call someone. With the Common App, students could only file an electronic report and hope it would be read.

The Common App’s widely felt problems generated little media attention while the politics of the Affordable Care Act ensured widespread publicity of the unacceptably troubled October launch of the Obamacare website. Both reflect the troubled and complicated nature of software development for large projects with many variables.

Failure – measured in late delivery, substandard performance, cost overruns, and sometimes actual inability to do as promised – is normal with new large software projects. Every software designer has a favorite horror story. In 1998, the $328 million Mars Climate Orbiter crashed because one set of programmers used miles and another used kilometers for measurement. In 2012 the Knight Capital trading firm lost $440 million in an hour due to a software flaw. Perhaps the biggest failure to date was the British National Programme for Information Technology to create electronic health records. By the time the government cancelled it in 2011, the decade-long effort had consumed nearly $19 billion.

The computer program for a space probe only has to model the laws of physics. In contrast, Healthcare.gov had to balance thousands of variations in insurance plans, state policies, potential users, different databases, privacy concerns, and much more. Perhaps the wonder was not that the website performed so poorly but that it performed at all.

Several states with their own systems also experienced severe technical problems that often lasted for months. The tempting conclusion is Obamacare is too internally complicated and flawed. Unfortunately for such naysayers, the Connecticut AccessHealth CT worked so well that the state is selling its expertise and parts of its system to other states. The interesting question then becomes why Connecticut did so well and other states and the federal government so poorly.

The problems with Healthcare.gov and the state websites grew from foreseeable political, managerial and technical errors. The biggest flaw was not providing strong political support and management resources for implementation of a program once approved, unfortunately a common problem. In fairness to those managers, intense political opposition to Obamacare greatly complicated their task. The refusal of many Republican governors to run Obamacare at the state level meant the federal website had to do handle much more than originally intended. Republicans in Congress tried to choke resources for implementing the Affordable Care Act.

The inefficient nature of the government procurement process also hindered Healthcare.gov as did a long-standing technology management issue: How much expertise do you keep within the government and how much do you contract out? If you contract out too much, the government managers become very dependent on the contractor to oversee a project. Furthermore, if the government job is more oversight than development, the best people may leave for the more intellectually stimulating (and higher paying) private sector. NASA and the military have long wrestled with this issue.

More specific shortcomings also handicapped Healthcare.gov and the Common App. Their managers violated current best practices by keeping the software code secret, not testing and releasing the software in batches to get feedback, and not keeping their superiors informed (possibly because some superiors did not want to hear bad news). Some technical issues, such as creating an easily understandable and consistent user interface or programming to handle multiple databases and data feeds, were either poorly decided or implemented.

Significantly, Healthcare.gov improved significantly in the months after its launch, benefiting from the resources and attention it finally received. By March 1, Healthcare.gov had fulfilled its original goal of signing up seven million people, a significant technological accomplishment and political victory.

The Common App was less successful, forcing many colleges and universities to delay deadlines. In both cases, leaders – Rob Killion, executive director of Common App, and Katherine Sebelius, the Health and Human Services Secretary – stepped down, reminders that good leaders ultimately take responsibility for what worked, and what did not.

Healthcare.gov and the Common App recovered, but their challenges remain for all large projects. Most importantly for the future, policymakers and managers need to appreciate how challenging software development is and the need to hear critical news early. Implementation of a project is as important as its creation.