Hacker News new | ask | show | jobs
by 3minus1 4630 days ago
Hi, I actually work for CGI Federal on a closely related website to healthcare.gov. There's some inaccurate speculation going on in this thread that I want to correct. Employees at CGI Federal are not payed hourly. Also, a lot of people have mentioned cronyism, which I think is baseless. CGI Federal already had contracts for Medicare.gov and CMS.gov, so when CMS had to build healthcare.gov, CGI was an obvious choice.

edit: Also, the projects I work on are Agile and I get to use other technologies besides .Net framework (e.g. node.js and backbone.js)

5 comments

>Also, a lot of people have mentioned cronyism, which I think is baseless. CGI Federal already had contracts for Medicare.gov and CMS.gov, so when CMS had to build healthcare.gov, CGI was an obvious choice.

You may be correct, but arguing that "because we generally get these contracts, we were an obvious choice" does little to defuse assertions of cronyism.

> "because we generally get these contracts, we were an obvious choice"

There are good reasons a government body might want to give a contract to someone they worked with before. There's a previous track record of success, and they know that the company already has expertise/solutions for their specialized requirements (i.e. section 508 compliance).

> There's a previous track record of success

Where? Definitely not the Canadian Firearms Registry, or the sites listed previously.

Full Disclosure: I'm not certain who 3minus1 is, but I used to work on the project he/she works on.

There was content at Healthcare.gov prior to 10/1. The applications that delivered the content to the site had very similar function to the ACA application. Intaking consumer information and outputting potential insurance options. Also, gathering insurer data to do this. Not a full prototype, but damn close. I like how CGI Federal is taking it in the teeth when there are a number of contractors who worked on this. QSSI, Experian, Etc.

Elsewhere in this subthread I attest to medicare.gov's high quality.

But that said, why should your demonstrated competence translate into success in a program at its launch? Medicare and Medicaid were both established in 1965, long long before the web.

On the other hand, did you have the contract for medicare.gov when the Part D prescription program was launched in 2006? Given all the interfaces with providers that sounds vaguely comparable to this site.

I don't think you are going to win any points here considering the outcome.
Also, a lot of people have mentioned cronyism, which I think is baseless. CGI Federal already had contracts for Medicare.gov and CMS.gov, so when CMS had to build healthcare.gov, CGI was an obvious choice.

This is sort of like saying:

Also, a lot of people have mentioned nepotism, which I think is baseless. I've already done work for myuncleisgreat.com and myuncleiscool.com, so when my uncle had to build myunclerules.com, I was an obvious choice.

hahaha - very true
Do you fill out time cards with hourly sort of precision? Do you have to fill in exactly 40 hours, no matter what? (Yes, I've worked for federal contractors before in the dozen years I spent Inside the Beltway.)

As for cronyism, who's to say you got those other site honestly?

Not saying you didn't, just that you're not citing any evidence. I can: I'm disabled and therefore on Medicare since 2007, and use medicare.gov to both handle Part D annual prescription plan selection and signup, and to check Part B claims. Aside from companies sometimes lying through their teeth about the costs for various drugs (well, it looks like that), I have no complaints besides the site being a little clunky. It gets the job done and has never shown any signs of buckling under load.

Can you share any insight into what went wrong?
Any insider theories why this particular project became so expensive and non-functional?
I knew that it was a crazy project, with devs working ridiculous hours, changing requirements, etc. I was genuinely surprised when it performed so badly.