Lessons from HealthCare.Gov

Healthcare.gov

Lessons from HealthCare.Gov

November 22, 2013  |  Development

I simply cannot fathom the technical hurdles involved with building thousands of integrations to ancient, pre-XML, proprietary interfaces that were developed in COBOL 30 years ago that I assume to be common in the insurance industry. Apparently few architects involved in the HealthCare.Gov debacle did either.

Elise Hu recently shared McKinsey & Co’s assessment of the system development progress that was delivered back in March.  This report fully foreshadowed the failures of a system that accepted only six American enrollments on day one despite the $600M price tag.  Oops.

Here is the fun part of the political game: where does the finger point?

Republicans are blaming Democrats.  Democrats are blaming Republicans. Some politicians are falling on their own sword.  Government is blaming the contractors.  Contractors are blaming the government.  This he-said-she-said is just another day in Washington.

The interesting blame being thrown around, especially in Hu’s case, is the employment of waterfall over agile project lifecycle as the culprit.  The assumption in Hu makes is continuous testing inherent in agile methodology could have identified roadblocks earlier in the delivery process and allowed CGI Federal a better chance of overcoming those hurdles.  Hu blames the method of project management for creating such a catastrophe.

I have a gut feeling that most in the tech community want to point a finger at the waterfall methodology.  The waterfall product delivery life cycle leads itself to bloated timelines, massive budgets, and general waste.  Waterfall methodology also tends to segregate business need away from difficulty of feature implementation.  This is a very key point that needs to be addressed with a Lego analogy.

Let’s say that Charlie, a 4 year old with an insufferable need to play with toys, wants you to build him a model car out of Legos.  He loves red cars. And his birthday is tomorrow.  You ask him whether he has any red Lego bricks to use, and Charlie says yes! He brings you his toybox full of Lego’s, and you promise him that you will build him the best red sports car he’s ever seen. You just made Charlie’s day.

You go back home, and rummage through all of the Lego’s determined to build him the red sports car of his dreams. After 20 minutes, you look down at the glorious pile of red pieces. Every red piece he has is a fence! You cannot build a car with those!

You falsely assumed in Charlie’s case that he would have a wide variety of red pieces that you could use for his car.  Your analysis of the situation prior to promising Charlie a new toy was wrong.  Now you need to either buy new Lego’s or spend a long time trying to make the red fences work.  Both of these options add cost and time to an otherwise simple project.

The analysis team of a waterfall project has an enormous task with high risk to make the proper assumptions. Many solution architects would agree that an agile approach around a unified service layer would have been a solid technical approach to solving Healthcare.Gov’s requirements, Hu’s argument. The agile approach could have taken project risk off of the complexities of individual integration points with insurance vendors. But what is missing from the whole picture is the thick line between the sales process and the delivery process of an engagement: the promise and the creation make progress at the other’s detriment.

I believe the real problem may be the relative ease of writing waterfall contracts versus agile contracts. Even empirically proven wrong, the perceived risks of an agile project in contract negotiation are much higher. Big consulting companies like multi-year waterfall contracts that allow for steady income quarter to quarter. And clients like the cushy feeling that they have negotiated for every feature when they sign the dotted line; they also have the ability to sue if a feature is not met. In the case of a government client, the relative ease of contract writing may be multiplied by a billion. I truly hope we can find a way to do this better.

Disclaimer: All thoughts expressed are mine alone, and do not reflect the views of any employer or client.

  • Mr. Mathew

    Great analogy. I’m sure I don’t understand all the heavy tech-side stuff, but this helps me understand what the options are regarding the roll out, and also maybe why the problems aren’t as simple to understand as the news bites would have you believe. I would understand enough to put this in front of an ITGS class now, thanks to your writing.

  • Jeff

    Given a huge problem, such as creating a healthcare policy directory, there seems to be two different ways of approaching: waterfall and agile. Waterfall is the idea of tackling the whole problem at once. Agile is the idea of breaking the problem into many smaller, manageable sub-problems.

    The agile approach to problem solving is becoming more highly regarded in software development communities. However, consulting companies, which operate very differently than software companies, are really struggling to incorporate agile methodology into practice.The distinction that I make, in more technical terms, is that sales people in consulting try to sell the whole solution at once because it is a bigger sale. When a piece of the solution fails, the whole thing topples over and becomes very pricey.

    More importantly, are you teaching ITGS again?!?!?!?

  • Jeff