After implementing over 400 software fixes and major hardware upgrades, the Obama Administration says it has achieved its goal of making the Healthcare.gov web-site “work smoothly for the vast majority of users.” Even if that assertion is true, it doesn’t mean the site is truly fixed, because beneath its bland homepage lies one of the most complex on-line experiences ever devised. There are over a thousand screens in the system, and a typical user might need to navigate 75 of them. When’s the last time you needed to navigate dozens of screens to accomplish an online task?
Probably never, because this is the first time anybody has ever tried to create a web-site where diverse users would (1) create an online identity, (2) review healthcare insurance options, (3) enroll in the selected plan, and (4) determine eligibility for federal subsidies. In order to make that possible, at least hypothetically, the government had to enlist five federal agencies, 36 states, and 300 insurers offering over 4,000 separate plans. It hired 55 different contractors to execute various facets of the site, and then — just to make it really sporty — decided that the government customer would be the final integrator of all these pieces.
Oddly enough, the system didn’t work so well when it debuted. Healthcare.gov had some roll-out issues and still has a few technical issues. It probably never will function properly for users who aren’t computer savvy, which is why the government is now making a greater effort to divert users to other ways of enrolling, like old-fashioned paper applications. But the Center for Medicare & Medicaid Services (CMS) that oversaw design and implementation of the site certainly didn’t help matters when it missed deadlines, imposed arbitrary design features, issued contradictory guidance, failed to establish clear lines of authority, ignored warnings about problems, and chose to go live without end-to-end testing.
Obamacare Contractor Accountability Following the Launch
The initial congressional response to the Obamacare web-site issues was to blame the companies for performance issues, without inquiring very deeply into why the companies might have had problems implementing their parts of the puzzle. For instance, a company called CGI Federal was raked over the coals in congressional hearings because it was responsible for the portal — even though many of the early problems with its part of the project were traceable to a front-end feature assembled by a different healthcare.gov contractor for which CGI wasn’t responsible. The fact CGI had successfully implemented many other healthcare projects for the federal and state governments was largely ignored.
Maybe it isn’t realistic to expect congressional objectivity on such a politicized project. Many legislators don’t want Obamacare to work at all, so they’re happy to highlight everything that is wrong with the web-site. When the site is optimized, these critics will simply move on to other complaints, like the cancellation of preexisting insurance plans or security concerns. But if there is any justice in the world — or any willingness in Washington to learn from mistakes — then we ought to take the time to say who was really to blame for this debacle. It was the government’s fault, pure and simple. CMS competitively hired the best IT talent in the world, and then broke every rule in the book for how to get good results.
Healthcare.gov: Contractors on the Project Warned the Government About Potential Malfunctions
Rule Number One is that the government is not a competent system integrator. Anyone who has followed the history of Pentagon weapons programs knows that. Therefore, when you are standing up a really complicated web-site like Healthcare.gov, with half a dozen discreet systems and five federal agencies involved, you hire an outside company to manage all the subcontractors. Rule Number Two is that you establish unambiguous lines of authority within the government as to who makes the final decisions. Rule Number Three is that you give the contractors the time they say they need to thoroughly test the new product before it becomes operational.
What went wrong with Healthcare.gov?
CMS broke these and a dozen other rules. The record shows contractors and outside experts repeatedly warned that features of the system CMS demanded were prone to malfunction, that guidance from the government was inconsistent, and that more testing was needed. CMS decided to go live anyway, and the result was a disaster for the Obama Administration’s signature policy initiative. It’s easy to point fingers at the contractors when things go wrong, but IT projects almost always go awry when the government designates itself as the final integrator, and blaming the companies raises the obvious question of why they have executed other projects so well and then didn’t succeed on this one. Any way you look at it, the government bares most of the blame for this embarrassment.
Find Archived Articles: