Healthcare.gov & Why Enterprise IT Projects Keep Failing
by Tom Wentworth
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.