Why the Cheapest Contractor is not always the best.

As we all know, the Healthcare.gov website seemed like an absolute, miserable failure within the first few weeks of it launching. Although Healthcare.gov was launched on October 1^st, the same day as the government shutdown, it was still one of the few federal government websites that remained open. However, visitors were met with a substantial amount of errors, and numerous technical problems. Some estimates stated that only “1 percent of the 3.7 million people who tried to register on the federal exchange in the first week actually managed to enroll.” (Source) You can’t always blame a service for not working perfectly on its first few days of launch, but 1% is just abysmal, and unacceptable for a government service. One of the main reasons Healthcare.gov was almost a complete failure was because of the unexpected high traffic during the first couple of days of launch. The U.S. Chief Technology Officer Todd Park said that the government expected to draw 50,000 – 60,000 simultaneous users, but instead drawn more than 250,000.  However, the former national coordinator of health care information technology stated “Whoever thought it would draw 60,000 people wasn’t reading the administration’s press releases. The Medicare Part D site was supposed to have 20,000 simultaneous users and was (built for) 150,000, and that was back when computing was done on an abacus. It isn’t that hard.”(Source) I can continue further in listing the various ways why the Healthcare.gov website was initially a train wreck, but I think the public’s attention would be better focused towards the process behind getting a project like this started. In particular, I am more upset with the government’s process of contracting the companies to set up a service like this.

It’s no secret that the government relies heavily on contractors to handle its larger projects, which is something I am not always fond of. To handle the back end systems of Healthcare.gov, the government contracted the fairly unknown IT company CGI Federal  back in 2011. CGI Federal had an initial bid of $93.7 million, but today, government records show that to fix the numerous problems with Healthcare.gov, the government had to pay CGI Federal more than $600 million. (Source) There is no better proof to show that the cheapest service is not always the best, and although the initial set up fees might be low, the resources needed to maintain a poorly set up service increase exponentially over time. In an article that addresses this issue from a developer stand point called What Developers Can Learn from healthcare.gov, the author states:

The biggest takeaway though, is that the way that the federal government bids out software is fundamentally broken. There are clearly companies in the industry who understand exactly the kind of problems that healthcare.gov needed to address. Intuit’s online TurboTax is much more complicated than the sign-up process for healthcare, and it works under heavy load. Amazon and Google both handle crushing loads gracefully as well. Why can’t the government draw on this kind of expertise when designing a site as critical to the public as healthcare.gov, rather than farming it out to the lowest bidder? (Source)

The way in which the federal government hires contractors needs to be drastically changed, and there needs to be some element of accountability. With a service already so poor at close to $100 million, why should the government have to pay an additional $500 million? Moreover, imagine the in house development team you can hire with $600 million? Not only would it create more jobs, but the government would no longer have to pay for additional maintenance since it is all done in house. I feel that the government should take this approach for a lot of other projects as well. By offering competing salaries against popular contractors, the government can acquire better talent to handle its in-house development. It would cost a substantial amount to begin with, but I feel that you would save more time, resources, and money in the long run, as well as creating new fields for the work force. I agree that there are probably fields where contractors would be best, but for developing new technologies or software, where the requirements change constantly, new ideas are being passed around, and all-around maintenance is required, I feel the government can only benefit from allocating the necessary resources to create their own in house development teams.