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.
Josh,
The problem with the post above is that the government wasn’t interested in creating a MVP. They weren’t interested in creating a “startup” venture but instead move a whole lot of people to a defined new way of doing things extremely quickly. There is no other option for which consumers can browse these marketplaces for healthcare, giving this site an instant monopoly.
I’m not advocating that Waterfall works – but in this case, the software was sold with upfront capabilities. Do we know for certain that behind the scenes agile wasn’t done in certain teams?
Tim, I think you are correct in stating that the government wasn’t interested in creating an MVP. My view is that this in conjunction with the massive scope of the project is what doomed things from the start.
I think it would be possible to adapt principles from the Lean Startup to the way our government operates. In this case, maybe that would mean creating a more gradual rollout plan for healthcare.gov that involved gathering feedback from users and adjusting priorities along the way.
I don’t have any inside knowledge of exactly how the project was managed, but I think anyone can see that a Lean or Agile approach was not used to maximum extent. I think talking about whether our government or the public is even ready for an approach like this is an interesting topic of conversation.
Do you see the problem as one of massive scope or massive audience? Thrusting millions of people on a new website means it has to serve everyone simultaneously – additionally it wasn’t simply to serve one state then another and another until all 50 were on board, all 50 states at once, all people everywhere. Perhaps this is what you mean by scope?
Excellent post, Josh. I thoroughly enjoyed it.
While there is evidence that agile processes were used by (some of) the software dev teams, the presence of the trappings of scrum doesn’t guarantee that work was conducted in the spirit of scrum (or any other agile methodology).
Michael Daconta claims to have seen development documentation for the project, and the work is talked about in terms of the scrum framework. It’s an interesting read on the subject as well:
Excellent post, Josh. Having seen your experience and expertise in-person, I appreciate your insight even more!
I only hope our government will learn from the experience and base changes on tests, knowledge, and practical results. (One can dream, right?)