Affordable “Snare” Act: ObamaCare Website Fails to Launch
Something’s on the roast, but it’s not Thanksgiving turkey. After a complete failure in its official launch last month, Obamacare’s HealthCare.gov is under tremendous public criticism. Will this project burn to a crisp, or is there a way to salvage it?
Signed into American legislation on March 23rd, 2010, the Patient Protection and Affordable Care Act is a national health care reform aimed at changing the future of the American health care system especially for the millions who previously could not afford it. The idea is to reduce government spending in and provide better, cheaper options of health care for all Americans. As part of this reform, affectionately referred to as “ObamaCare,” the online health insurance marketplace HealthCare.gov was launched on October 1st, 2013 that allows Americans to determine if they are eligible for government-subsidized coverage and compare prices on affordable, quality insurance.
So what went wrong at launch?
- The unanticipated flood of users interested in the website lead to a virtual “wait room” for all users who could not even log in due to massive lag and denied access.
- There were further glitches in the website that prevented certain payment transactions.
- The website was criticized for difficulty in navigation on top of the technical problems.
What was the damage of the unsuccessful launch?
- After one month of launch, only 106,185 Americans chose Obamacare out of all health insurance plans available and only 25.2% purchase through HealthCare.gov.
- HealthCare.gov cost upwards of $600 million, more than triple the amount spent to build LinkedIn ($200 million).
What additional problems arose after the launch?
- On October the 20th, well over two weeks after the website’s launch, U.S. President Obama himself admitted to being disappointed at the website’s launch. The Department of Health and Human Services published a blog post acknowledging previous hiccups during the site’s testing and even promotional phases, and promised to bring in “the best and the brightest” to fix it. This provoked critics to disparage why that was not done in from the onset.
- Earlier this week on November the 26th, the Obama administration announced a one-year delay for small businesses in signing up coverage via HealthCare.gov and forcing them to go through offline enrollment while they fix the user functionality. 
So what actually went wrong?
This, of course, is a huge discussion. Aside from the political nature of this website, additional volatility surrounds the vast amount of stakeholders and uncertainty in predicting website usage. As expected, a lot of fingers have been pointed at different stakeholders, but it is still ultimately the U.S. government’s responsibility to establish a working website.
LACK OF AN OFFICIAL PROJECT CHARTER
This project bares similarity to the TAURUS project developed by the London Stock Exchange which failed because they were over-ambitious, tried to appeal too many stakeholders, and never clarified a starting point and ending goal. A clear project charter would have helped to clarify the stakeholders, requirements, timeline, and key objectives of HealthCare.gov, thereby eliminating scope creep and assigning accountability. Clearly outlining the project requirements and expectations across all contractors could have also aligned them towards a common set of goals and deliverables. They could have even outlined performance metrics or used an earned value management tool to track the progress of the project during development to keep both the budget and timeline tight. The result of not having a project charter? Overpromising and under-delivering.
OUTSOURCING METHOD WAS OVERLY COMPLEX
Given all the stakeholders HealthCare.gov had to address, the Obamacare website was already complicated enough without 55 different contractors. Out of the 55, CGI Federal was the main contractor, handling the Federally Facilitated Marketplace, QSSI lead the registration tool and data transfer service, Equifax verified the income data to determine eligibility to health care, and Serco handled paper applications. Proprietary software was impossible to integrate, functionality and speed was not well considered, and communication was difficult to facilitate across all different parties. This unnecessary complexity lead to critical functionalities of the website being sub-par even at launch.
LACK OF CLEAR RISK MITIGATION STRATEGY
Not only was end-to-end testing held off until a couple weeks before launch, and even so the failed testing should have been a clear red flag, but even that was overlooked. Using a Risk Matrix could have been established even before the website launch to anticipate a proper mitigation strategy should the launch fail (which happened to be the case). Inability to handle more than peak load could have been one of these risks, and a simple solution would be waiting for the results on legal compatibility with Amazon Cloud Services to establish a central, scalable solution.
So what should they do now?
An initial failure to launch does not mean that the project cannot be salvaged. By establishing structure and seeking the right help, HealthCare.gov still has the chance to become a service Americans can be thankful for.
First and foremost, they need to seek the right help to help them get back on track. Aneesh Chopra, former White House CTO, suggests the Presidential Innovation Fellows to help pair the U.S. government with the “best and brightest” from the private sector with a track-record in restoring programs that have faced technical troubles like this. Finding one capable and experienced leader who knows politics, technology, and the healthcare industry is crucial in overseeing the IT project, and will help to centralize communication.
Second, they should develop project plan and management structure. Knowing the complexities in the backend working with an abundance of contractors and databases, managing all these parties in an effective way will help streamline the project delivery. All the time while developing the functionality, they must remember to anticipate risk.
Next, they need to get the website to function properly. This starts with gathering user feedback, prioritizing what to fix, and starting with guaranteeing the core functionalities of the website: “organizing insurance plans, assessing program eligibility, facilitating consumer enrollment.” These are the “minimum viable product” for the website, or the bare minimum for the website to function.”
In the long term, after they finally launch a bug-free version website, HealthCare.gov should to consistently monitor the activity to ensure first response to unanticipated problems.