By Juan Gonzalez with Nicco Mele
On October 1st, the White House launched HealthCare.gov to much fanfare and almost immediately the site crashed. Over $500 million dollars, three weeks, and two political distractions later, the technical centerpiece of President Obama's Affordable Care Act is seen as a colossal failure. Justly lambasted by the Right as "an unmitigated disaster" and "a train wreck", the website's widespread problems have forced even those on the Left to acknowledge it is, at best, a "fiasco." Yet these "glitches" should be no surprise.
In the age of radical connectivity, "Big" is a liability. The Big Institutions - huge Federal bureaucracies, large technology companies, and a massive government procurement process - spent hundreds of millions of dollars on producing a glorified webform, and failed miserably. But these Big Organizations never stood a chance and were set up for failure. Smaller, more agile, and nimbler technologies and processes could have prevented these problems which now threaten the success of the President's legacy-defining legislation.
(Photo: Reuters, M. Scott Mahaskey / POLITICO)
Notables like open-source technologist and former Presidential Innovation Fellow Clay Johnson have written extensively about what went wrong these past few weeks, and it simply comes down the structural deficiencies inherent in Big Government. In the end, the Federal Contracting process failed to identify the proper functional requirements for the new site, couldn't adequately vet firms during the bidding process, and ultimately misidentified both the tools and technologies that would eventually be used. As the sensational details leak out to the press, the results of this big and bloated process speak for themselves:
- The Winning Firm was a Serial Loser: The primary technical contractor, the U.S. arm of Canadian technology giant CGI had been fired by the Government of Ontario for incompetence in building a medical registry website, thereby cancelling a $46 million contract. They were "at best sloppy and at worst unqualified for the job," says Johnson.
- The Technology used was Ancient and Inadequate: Big Contractors ended up building HealthCare.gov on 10-year-old software that will require months of constant updates and eventually need a complete re-write. Use of this bloated and outdated technology was so systematic that it contributed to laying the foundation of the platform with bad systems and bad architecture, making the entire investment essentially wasted since it will all have to be rebuilt from scratch - and in the short-term, it's going to need more than 5,000,000 lines of code re-written just to function.
- Politicians, not Programmers, called the shots: Even though HealthCare.gov was being criticized as being "built by rookies," politicians and bureaucrats ordered the site launch on their own schedule despite the fact that the site failed its most important pre-launch tests. So on the eve of the launch, as the website was crashing and couldn't even handle a couple hundred concurrent users, federal healthcare officials launched the site to tens of thousands of simultaneous visitors at midnight and the debacle unfolded rather unsurprisingly.
- The Website failed at its most basic task: If HealthCare.gov's primary function is to allow consumers to compare health insurance offerings and sign-up for healthcare, the website's constant crashes and persistent time-outs have prevented it from fulfilling its basic purpose. Of the 476,000 estimated users who started the application process, many of these applications either had sent insurers incorrect data and just one week into the program, rumors circulated that the number of successful applicants was limited to the single digits.
Breaking Big: The Solution
These problems seem giant and senseless. How could all of this have been avoided? I have written in the past about what causes Strategic Failure like what happened to HealthCare.gov, and what these big and bloated processes underline is the absence of purpose and poor planning at the fundamental project management level. Big Institutions, and especially Big Processes, like the Federal Procurement Process, are driven towards giant projects and tend to avoid more flexible and pragmatic approaches to building technology that is practical. Evaluating the purpose of HealthCare.gov required understanding the end-user experience and limiting it to its bare essentials to maximize the likelihood that users could complete the process, and then constantly calibrating and adjusting to improve the basic experience for users. Instead, CGI Federal built a site that was so complex to justify the procurement process that contractors admit that a smaller, more focused project would have been successful.
Amidst the failures of HealthCare.gov, there are numerous examples of how small, agile, focused, disciplined digital teams were able to build successful experiences for users, especially on the locally-run State Exchanges, and each example tells us how the problem of HealthCare.gov could be solved.
- Simpler is Better.
HealthCare.gov tried to automate a large number of processes - from eligibility and verification, to comparison shopping based upon complex data pulled from a number of agencies and sources, and eventually automated checks and controls in real time. But none of these ridiculously complex processes were even really necessary for the site to achieve its basic function - getting people to sign up for health insurance. The Massachusetts Health Connector, Massachusetts' state exchange website, was built to simply provide information and receiving intake from web users - basic forms - which would then be processed by hand, and any automated checks are optional and being rolled out gradually to make it easier for users to completely fill out forms.
- Smaller just Works.
The government's preference to hire large and established federal contractors, a by-product of the disastrous Federal procurement process, is ultimately divorced from realities of what most projects, especially HealthCare.gov, really need. Hiring Big results in teams that are more likely to be bulky and uncoordinated, averse to innovation, lack institutional focus and discipline, are incapable of iterating with agility. Big firms ultimately carry so much overhead that they are prone to lengthier, more complex solutions as a way to justify margins. Consider the "Start Here" information-section of HealthCare.gov website, which was built by the smaller and more agile firm Development Seed. Not to be confused with the rest of the HealthCare.gov site (the "Apply" sections), a small team of 12 people built the information portal in a garage and it just works. Smaller teams, simpler focus, and basic essentials ensure that the site can serve part of its mission by informing users.
- Focus on Basic User Needs.
Smaller, state-run exchanges are working where HealthCare.gov has failed because many of these local exchange systems, like Massachusetts, operate with a better understanding of the total pool of the uninsured - data that the Federal government cannot and does not manage. This in turn leads to states being able to identify the primary needs of users -- is it information first and then a simple automated enrollment process? Or is it initiating an in-person intake process by first submitting an online form? -- and then building sites to serve those specific needs. For example, the Washington Health Benefit Exchange delivered on an understanding that users really didn't need user accounts and that account-creation for a process that was generally all about submitting information would create an unnecessary bottleneck that was a distraction from, not an enhancement to, the user needs. States that do not rely upon integration with Federal systems, like Connecticut, Kentucky, and California, have had generally positive experiences processing thousands of applications for coverage, while states that are integrated with federal verification and eligibility data sources, such as Minnesota, Nevada, and Rhode Island, have been plagued with issues, though all state exchanges are nevertheless significantly out-performing their federal counterpart.
The technical problems with HealthCare.gov are emblematic of how Big Failures have led to non-trivial undermining of the Affordable Care Act, and a wide range of potential consequences have been bandied about - from resignations of cabinet secretaries and lawsuits against the contractors to potential increases in costs for the risk pools because younger and healthier people were the most likely to stop the enrollment process when problems began.
However, while there will be much hand-wringing and gnashing of teeth about what happened, who should pay, and what consequences there should be, this is an essential learning moment for the entire country. Understanding that Big Decisions led to this failure and that they could be remedied by simplifying to focus on solutions that address the prioritized needs of users can help ensure that the future HealthCare.gov website works for all Americans. Many of the complicated and convoluted qualifications checks and automatic processing should be aimed at expediting the application process and simplifying the experience for users rather than assuming that users needed all of this hand-holding to begin with. At the end of the day, the Field of Dreams myth proved too alluring for Big Government, Big Companies, and Big Contracting Processes, but it never works that way online -- If you build it, they won't come. Instead, build what they need when they need it.