Healthcare.gov: Why we should have expected a disastrous launch

It’s safe to say that the much-anticipated launch of Healthcare.gov, the Web portal for President Obama’s Affordable Care Act, was an unmitigated disaster. Supposedly no more than six people were able to fully enroll on the day of its launch, and the majority of users were unable to create an account. Tens of thousands of people were trapped in a virtual waiting room while tech teams frantically attempted to fix the bugs. Suffice it to say, it was frustrating for everyone involved, and things haven’t gotten much better.

However, while the website rollout was a disaster, that should not come as much of a surprise. Simply put, we should not be shocked when a new website proves incapable of handling 2.5 million visitors at once.

A lot of people are pointing fingers at the President, the technical team behind Healthcare.gov, and governmental figures like Health and Human Services Secretary Kathleen Sebelius, who testified before the House Energy and Commerce Committee, saying, “Hold me accountable for the debacle.” In reality, there’s no way to think of them as anything other than scapegoats.

The responsibility for this mess doesn’t rest on the shoulders of any one person or even the tech team that implemented it. The problems arose from much larger systemic issues. And the American public had unrealistic expectations that a government still catching up with modern technology could pull this off without encountering problems.

The fantasy of governing based on certainty

The general hypothesis behind Healthcare.gov seemed to be that Congress would create a piece of legislation made up of 381,417 words, with corresponding regulations totaling roughly 11.5 million words. They would use these guidelines to create a Web application that adhered to the terms prescribed by the bill without many setbacks. As anyone who has been involved in building digital platforms during the past decade will tell you, this hypothesis was completely unreasonable.

The problem stems from the fact that Healthcare.gov was created using the outdated Waterfall method, which mandates that all aspects of a software model be worked out before the development of the platform begins. Oftentimes, this sets the features and specifications of an application in stone. We’ve found this method to be wildly problematic when it comes to launching any large project, especially those that need fine-tuning or have uncertain outcomes. In recent years, developers have created new ways of launching digital products that help avoid the staggering technical risks provided by the Waterfall model.

Scaling things down

In order to increase the effectiveness and efficiency of a launch, many startups adhere to the lean startup methodology. This involves defining what is known as a minimum viable product (MVP), which is a stripped-down version of the application that includes as few features as possible to be used for the initial release. Determining an MVP provides several benefits:

• Reduced time to market
• Reduced technological complexity
• Reduced development costs
• An opportunity to respond to user feedback with updated features

When following the lean method, it’s also helpful to keep the team and scope of the initial version of the product small. Unfortunately, our government works within a set of strict timelines and rules and, by necessity, must work with outside vendors. The government lays out all the regulations, legislation, and timelines surrounding the project, and vendors are held to these timelines.

Even though modern experience has proven otherwise, most people expected Healthcare.gov to be stamped out as a perfect, finished product. This simply is not the nature of a complex digital launch.

If the government had been operating like a lean startup using agile practices, the development of Healthcare.gov should have gone like this:

• Hypothesize: Create a pilot project to test whether U.S. citizens will even be interested in using Obamacare and interacting with a government-run website to acquire health insurance.
• Build: Construct an initial MVP platform and launch to a limited number of people.
• Measure: Perform extensive tests to measure the MVP’s effectiveness and the user experience.
• Learn: Learn what needs to be improved or fixed from the test data.
• Iterate: Glean insight from actual customers and enhance features where necessary. Work out problems and scale the application at a reasonable pace, rather than all at once. (This would be possible if a slimmed-down Healthcare.gov were in place.)

This process isn’t all that new, but as we know, the government has a tendency to lag in areas related to technology.

Think about it: Facebook is one of the largest sites on the Web, but at one time, it wasn’t open to everyone and didn’t have all the features it now boasts. It grew slowly, providing technical teams with the chance to refine and develop the product we know today. The same was true for Twitter. Remember the fail whale? It took time for tech teams to scale the platform to serve millions of people, but they had the benefit of starting small and building up.

As long as our government operates with an outdated mentality, we’re going to see more hiccups when substantial legislation is rolled out. As technology evolves, an increasing number of governmental initiatives will be attached to digital delivery systems. Maybe it’s time to rethink how we write legislation and apply these mandates to services for the public.

The bottom line is we’re all getting a little tired of experiencing the governmental fail whale.

“Help” image courtesy of Shutterstock.