The recent failed rollout of Healthcare.gov is riddled with so many issues that it’s hard for the average American to comprehend why it happened and who is to blame. Even the mainstream news reports appear confused and scattered about what caused this #EpicFail.
Make no mistake: designing and building software and websites can be very complex, so the confusion is understandable. However, if you are in the business of making software (like we are), this kind of story makes your blood boil – regardless of your political position. This poster child for how not to make software will have designers and developers repeating “Remember Healthcare.gov?” in client meetings around the world.
So, what lessons can we all learn from this? How can we use this failure for something positive? Below, I’ve outlined some of the lessons learned from Healthcare.gov that will hopefully help contribute in some small way to the greater good of all future software releases.
Having a deadline enables you to define a very specific scope of work that can only be done within the confines of how many effort hours can be performed within a set duration.
CGI Federal was the development firm responsible for the botched Healthcare.gov launch. They were either greedy, incompetent, or both when it came to managing the scope and expectations for what could realistically be accomplished within the unrealistic deadline they were given. In reading some of the interviews of developers who worked on Healthcare.gov, it is clear that they were teed up for certain failures. Deadlines can not always be solved by adding more resources. Rome was not built in a day — nor could it be if you assigned every living human to work on it.
Ironically, CGI should have felt more like they were in the driver’s seat when managing this project and their government client. There was no way the government could ever find a firm to replace them in time to meet the deadline they set. This was a huge missed opportunity to stand firm with a client and steer their expectations towards releasing a Minimum Viable Product (MVP) rather than a full product release for the initial rollout. Instead, it appears tons of features and systems integration requirements were included and agreed to in the scope and even added during development, which is a recipe for certain disasters.
Imagine an MVP with a stated business goal of enabling users (U.S. citizens) to create an account and submit an application for healthcare coverage. That’s it. There is no integration with disparate systems from the Social Security Administration, IRS, Veterans Administration, Office of Personnel Management, and the Peace Corps. No comparison shopping among competing plans or live web chat support. Just capture the data and let the users know that they’ve successfully enrolled and to look for an email in the near future containing a link to some healthcare plan choices and new features as they get released.
Troubleshooting and debugging an MVP is far easier than a full-featured product release. Once the base MVP is rock solid, you can begin rolling out new features in subsequent releases from your backlog of requirements. In software development, we call this Agile Development.
If you receive a proposal from a software development company for your website with a budget cap of $94 million, run. If you approve a proposal for a $94 million website, please resign immediately. If that project quickly inflates to $196 million, and you approve a new budget cap of $300 million, you don’t belong on this planet.
No website of any kind should ever require an initial budget cap of $94 million. I’m not saying that it’s not realistic for a company or government agency to eventually invest that amount of money in their website over time. It should never be possible to spend that much money on building any initial release of any website. That is all.
CGI apparently relied heavily on the government’s Centers for Medicare and Medicaid Services to test the website during the final weeks. That task, known as integration testing, is supposed to be handled by software Quality Assurance (QA) testers. It requires a deep technical understanding of software development and testing methodologies that are executed to identify problems before the public sees the final product. There is simply no possible way a Medicare or Medicaid worker is qualified to perform unit testing, integration testing, regression testing, etc.
The only type of testing a client should perform is what is known as User Acceptance Testing (UAT). A client performs UAT to simply verify that the system meets the mutually agreed-upon requirements.
Americans have until about mid-February to sign up for coverage if they are to meet the law’s requirement that they be insured by the end of March. If they don’t, they will face a penalty. In the business world, this would be like a business telling its customers to pay their bill by a specific date or they’ll shut off their service – except the business makes it impossible for its customers to pay their bill.
In the case of Healthcare.gov, the government is the business, and Americans are the paying customers. Yet, it is the government that is imposing an unachievable demand on its citizens. Clearly, they have forgotten who the paying customers are. If your customers (Americans) are paying you (with tax money) to provide them with a product (healthcare coverage), you should be the one that responds to their demands — not the other way around.
“You never get a second chance to make a first impression” is especially true of your website’s user experience. With so many sites to choose from, it’s nearly impossible to regain users once they’ve had a negative User Experience. The one thing Healthcare.gov has going for it is there’s no competition — unless your state has its own site you can use.
The most important takeaway from this debacle is that it shows how User Experience is not just about visual design, interaction design, or information design. It’s about every aspect of a software product that can impact the end-user’s experience.
p.s. You know you messed up big when SNL mocks you.
