Contractors Who Built Healthcare.gov Website Blame Each Other For All The Problems
from the nice-try dept
With all the problems associated with the Healthcare.gov rollout, a bunch of fingers (including ours) pointed at the usual list of government contracting cronies who built the thing. The deal was done under an existing contract (so no open bidding) and involved the same "usual suspects" who have been connected to a number of other large government computer systems debacles. Not included anywhere in the list were companies with experience building large-scale web services -- which you'd think would be helpful here. However, in testimony before Congress, the contractors are insisting that it's not their fault. CGI Federal was the main contractor behind the site, and Cheryl Campbell, a senior VP from the company, is in charge of trying to point fingers elsewhere, mainly at the Centers for Medicare and Medicaid Services (CMS), which CGI Federal says was in charge of the actual building of the site.
CMS serves the important
role of systems
integrator or "quarterback"
on this project and
the end-to-end performance of
Basically: it's the government's fault. We just build the damn thing. If they didn't tell us to build the right thing, or test it properly, well, it's their fault. Also, someone else we won't name is really at fault:
was awarded the contract for
Hub portion of
the Federal Exchange.
Oh, and also another unnamed contractor:
The first set of issues
function provided by another contractor, which allows users to
create secure accounts.
Of course, it's not too difficult to figure out who the "other" contractor is. Because it's on the panel too. QSSI built the Data Services Hub and the "EIDM" functions mentioned, and QSSI is owned by Optum, whose executive vice president Andy Slavitt is testifying as well. And, you know, it's not his fault. First, he insists that the Data Service Hub worked splendidly throughout, no matter what anyone else might say. EIDM, of course, is having some trouble, but that? Why, other vendors are to blame there too:
to note that
the EIDM tool is
and access management
vendors and pieces of
While the EIDM plays an important role in the registration system,
developed by other vendors handle
functions such as the
user interface, the e-mail that is sent to the user
to confirm registration, the link that the user clicks on to activate the
account, and the web page the user lands on.
All these tools must work together seamlessly
to ensure smooth registration
In other words, if only those other vendors did their job right, the whole thing would work much better. Oh yes, also someone (nameless) decided to change the specs at some late date:
It appears that one of the reasons for the high concurrent volume at the registration system
was a late decision requiring consumers to register for an account before they could browse
for insurance products. This may have driven higher simultaneous usage of the registration
system that wouldn't have occurred if consumers could "window shop" anonymously.
The final note, going back to CGI Federal, is to remind Congress that building websites is really hard.
Unfortunately, in systems this complex with so many
concurrent users, it is not unusual to discover problems that need to be addressed
once the software goes into a live production
environment. This is true regardless of the level of formal
testing -- no amount of testing within reasonable time limits can
live environment of this nature.
That's true to some extent, but it doesn't excuse many, many of the overall problems with the system, which did not appear to be built with any recognition of how to build a high-traffic transactional website. While CGI Federal would like to point fingers at everyone else, it was its name on the contract, which it received through questionable means, and it should take at least some responsibility for it. Perhaps, if it was so "complex," it shouldn't have taken on the job.