Home / Comment permalink

Healthcare.gov & Why Enterprise IT Projects Keep Failing

You would have to be living on another planet to not to have heard about the failures of the healthcare.gov site. It seems like every day, there's another high profile failure, where the site doesn't work, or its hosting servers go down. It's been great fodder for late night comedians. Last weekend, even Saturday Night Live got in on the action. My favorite two quotes from the skit:

  • “A lot of folks have been talking about our new healthcare enrollment site, how it’s been crashing and freezing and shutting down and stalling and not working and breaking and sucking. Millions of Americans are visiting healthcare.gov, which is great news. Unfortunately the site was only designed to handle six users at a time.”
  • “And if our site keeps freezing, we’ve also provided links to other helpful websites such as kayak.com where you can purchase airline tickets to Canada and buy cheaper prescription drugs.” 

Those of us in the technology sector know that healthcare.gov is just another in a long line of failed IT projects. A 2012 McKinsey study revealed that 17% of lT projects budgeted at $15 million or higher go so badly as to threaten the company's existence, and more than 40% of them fail. The healthcare.gov implementation team is, unfortunately, in great company. 

I trace the healthcare.gov failure back to a completely broken IT procurement process that ensures companies (and governments) often end up with the wrong technology. The enterprise IT sector is still dominated by big technology vendors like Oracle and IBM, and their personal relationships with technology decision makers. Often technology selection decisions are made on personal relationships and blind faith, not by properly matching business needs to specific technologies.

The result? Huge vendor software + professional services contracts, which put nearly all of the risk on the customer. The vendor takes their cut in the form on an up-front perpetual software license, often millions of dollars, and a large services contract. The services contracts are often scoped well before the customer has any idea of what their project and requirements really look like, in the form of a "waterfall" proposal - filled with requirements, deliverables, and milestones. And when requirements change (and they always do), or when new deadlines must be hit (and they must), the customer absorbs all the additional cost.

Speaking of cost, according to testimony from Health and Human Services Secretary Kathleen Sebelius, healthcare.gov has cost $174m(!!!!) so far. Just to build a website. For that cost, the government could have built Facebook, Spotify, Instragram. You get the point... 

I don't blame the technology vendors for these deals and resulting failures. They are doing whats in the best interest of their shareholders, driving revenue growth. I blame the legacy technology selection processes and old school project management mentalities that lead to these broken technology selections. As Matt Asay points out, the solution is open source and more importantly, open, agile processes:

According to Asay, "In general, open-source code will be better for projects like this because it involves open source process. But even where both open-source code and open-source process are involved, choosing the right code and right process isn't as easy as just blindly saying open source."

Had the healthcare.gov team taken an agile approach of "built-measure-learn-iterate", they would have been able to break the massive project into much smaller chunks that could have been properly architected, developed, and tested throughout the process not 4 days before launch. Instead of starting with the technology selection, the team could have selected the right combination of open source (and maybe proprietary) technologies at each stage in the development lifecycle. Failures would have still happened, but they would have happened faster, and at a smaller scale, minimizing cost and risk.


Posted on by Anonymous (not verified).

I thought this whole deal was open source- maybe not Drupal but open source?

Posted on by Tom Wentworth.

Parts of the project were open source (not Drupal), specifically the front end. By all accounts, the front end development went really well. It was developed on GitHub, but was suspiciously removed after all the problems started emerging.

It's all the back-end integration pieces with all the legacy systems that were developed in a closed, "waterfall" methodology.

Posted on by James Carney (not verified).

The problem was the selection process, and as you have put it, the broken legacy selection process. The project was completely based on price alone, where a Canadian based company was able to snatch up the contracts while the Federal government looked at the price and bought right in.

Projects need to be done by selecting agencies and firms that act like partners and that fit the company perfectly for the project. Although it sounds cliche, a company that sees(and may even need) the project to succeed would ensure a perfect product is delivered every time.

A project like this really should never been scoped and selected solely based on price. So it was doomed from the beginning. Yet another runaway IT project train fueled by large revenue size, driven by silo'd companies whose right hand doesn't know what the left is doing.

Just goes to show that having 1 central company to work with, who will ensure the project is on track every step of the way is paramount.

Posted on by Anonymous (not verified).

So you are really critiquing the methodology and not the architecture per se?

Posted on by Pabbas Ice Crea... (not verified).

Impressive.. Keep it up..

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.