IT project managers can learn a lot from the failed Obamacare website roll out. Let’s look at the primary lessons those in information technology can draw from it.
More is not better.
The federal health insurance exchange website and its interfaces contain an estimated 500 million lines of code. There is a law that states that complex processes that work well evolve from simple processes that work right. The website’s design is a complicated mess. It tries to do a lot, and fails to even deliver user input data correctly to insurers, the very purpose of the website. The state based exchanges that have their own websites and link to far fewer groups have a far rate of enrollment, albeit mostly to state Medicaid. The websites are simpler and have far fewer interfaces, which is why they work.
Take the time the project needs, or it ends in disaster.
Initial criticism of the federal healthcare exchange site started with the fact that they had three years to do this. Why doesn’t it have proper security measures in place to protect data, deliver information to insurers correctly, and return proper pricing information to shoppers?
Health and Human Services excuses the debacle by saying it would take five years to build a site this complex and one to two years to test, while they only had two years to work on it.
Delaying the website and the mandate by a year to have a working website is infinitely better than sticking to a scheduled rollout and delivering a non-working product. And no number of press conferences and advertisements with athletes and pop stars will make anyone happy with two days wasted trying to get a price quote for a federally mandated product, when they were expecting a shopping experience more like Amazon or eBay.
Do real tests to reflect actual usage.
Reports have started to come in that when the Affordable Care Act sign up process was initially tested, they only tested several hundred simultaneous users. This is insufficient for a website expected to be used by millions. Then again, the site locked up with a few hundred simultaneous users. Even if these problems had been fixed, real testing should have gone on with 100,000 simultaneous users.
Don’t expect a crack team of experts to fix what took months to screw up.
Hundreds if not thousands of contractors worked for over a year to create its code. The workflows in the software are complex. There are many different interfaces, many of which are not working correctly, from people told they can’t get insurance because they are in jail (but have never actually been in jail) to insurers receiving incorrect info like spouses being listed as children.
Debugging code can be as time consuming as developing it. Bringing in a crack team to fix the problem will not yield immediate results. They’ll likely need months to identify all of the problems to fix them. Furthermore, solutions to these bugs require thorough testing, which adds additional time. It is unrealistic if not utterly naïve to expect a team of gurus to be formed immediately and fix in a matter of weeks something that took months to build poorly.
Make changes during requirements gathering, not right before go live.
One possible reason for the failings is the purported last minute change to hide prices, limiting the information to those who created accounts. Officials had concerns that that permitting people to see the high insurance prices would generate further backlash against the site. Instead of letting anyone get price quotes for health insurance through the marketplace, they had to create an account to see the prices. This created a bottle neck, with hundreds of thousands trying to create accounts just to shop around. Was the intent to force buy-in through time intensive data entry, so that users would feel compelled to buy Obamacare plans? Or is the goal to collect data for purposes of marketing, voter outreach and the generation of records the NSA somehow does not have? But by implementing a change that puts price information behind the account login, a major logic change was made that affected its functionality.