Search form

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.

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.

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.

Plain text

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.