A Lesson In How Not To Make Software
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 to be confused and scattered about what caused this #EpicFail. Make no mistake about it, designing and building software and website can be a very complex undertaking 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 positions. 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 some 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.
Deadlines are your friends — not your enemies.
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, the development firm responsible for the botched Healthcare.gov launch, was either greedy, incompetent or both when it came to managing scope and expectations for what could realistically be accomplished within the unrealistic deadline they were given. In reading some of the interviews of developers that worked on Healthcare.gov, it is clear that they were teed up for certain failure. 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.
Identify and build a Minimum Viable Product first — then add features.
Ironically, CGI should have felt more like they were in the driver’s seat when it came to managing this project and their government client because 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 very big 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 disaster.
Imagine an MVP that had a stated business goal of simply enabling users (U.S. citizens) to create an account and submit an application for healthcare coverage. That’s it. No integration with disparate systems from Social Security Administration, IRS, Veterans Administration, Office of Personnel Management and the Peace Corps. No comparison-shopping among competing plans. No 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.
It is simply far easier to troubleshoot and debug an MVP than it is 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 the software development, we call this Agile Development.
Never spend $196 million for any website — ever.
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 same 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.
Use testers to test — not clients.
It appears that CGI 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 because it requires a deep technical understanding of software development and testing methodologies that are executed in order 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.
Customers make demands — not businesses.
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 certain 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.
A bad User Experience is actually worse than no User Experience.
“You never get a second chance to make a first impression.” This is especially true with the User Experience of your website. 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.
Perhaps the most important takeaway from this debacle is that it shows how the User Experience is not just about visual design, interaction design or information design — it’s about every aspect of a software product that can have an impact on the end-user’s experience.
p.s. you know you messed up big when SNL mocks you.