Obamacare and the Project of Doom

| October 23, 2013

I hardly know where to start.

I just spent the last two days working on a matter involving a $100 million failed IT project, and it seems like a pleasant walk in the park compared to the news that keeps leaking out about the Healthcare.gov debacle.

Let me start by saying: there is no royal road to software. Good intentions, earnest efforts, and noble causes don’t count for jack. As I told John Fund over at National Review, saying (as SecHHS Kathleen Sebelius did), “We needed five years but only had two” boggles the mind. It is an admission, inadvertent or otherwise, of profoundly irrational and childish thinking, of magical thinking, if you will. “Clap! Clap to keep Tinkerbell alive!” That type of thinking.

Let’s quote from myself. Thirteen years ago, while a director at PricewaterhouseCoopers, I reviewed documents pertaining to 120 failed or troubled IT project that ended up in litigation, then wrote a white paper on the common patterns I found. In that white paper, I talked about the various software quality aspects that were important in a successful system. Here they are:

  • Reliability: the system must carry out its functions without causing unacceptable errors or having an unacceptable downtime.
  • Performance: the system must complete its various operations within time spans acceptable to the client.
  • Functionality: the system must offer sufficient usable features to meet the client’s needs.
  • Compatibility: the system must interact effectively with existing IT systems, including appropriate external systems under the control of other entities.
  • Lifespan: the system must continue to offer acceptable reliability, performance, and functionality over a sufficient period of time to warrant the cost to the client, including in many cases having the ability to grow with the client.
  • Deployment: the vendor must deliver and deploy the system, and the client receive its benefits (reliability, performance, and functionality), in a timeframe acceptable to the client.
  • Support: the system must have the capability to be upgraded and repaired over time.
  • Cost: the cumulative expense of developing, deploying, upgrading, and maintaining the system must appear to be justified in the eyes of the client.

From all the various reports about the Healthcare.gov development effort, as well from both firms and individuals trying to access the website and the associated Federal data hub, I think Healthcare.gov has serious problems in nearly every single quality aspect listed above. Not just little problems, or annoying problems, but major problems.

Keep in mind that I wrote this list 13 years ago; this is not cherry picked to slam Healthcare.gov. Also keep in mind that I wrote this list after that review of 120 failed IT projects, so it reflects the problems that most frequently showed up.

Now, let me list the six frequent patterns I identified in those 120 failed projects:

  • Faulty Towers: The client buys the system from the vendor. The client then claims that the system is defective, i.e., it has errors during operation, crashes, and so on. The vendor makes attempts to repair it, allegedly with limited and unsatisfactory success. In some cases, the client ends up returning the system and acquiring a new one from a different vendor.
  • Irrational Exuberance: The vendor makes claims for the functionality and/or performance benefits of the system. The client buys the system and has it installed. The client then believes that the system does not have the claimed benefits (performance and/or functionality). In some cases, the client ends up returning the system and acquiring a new one from a different vendor.
  • Three’s a Crowd: This pattern actually lumps together two sub-patterns. In the first, the client purchases an IT system from the vendor by way of a leasing firm. The client is dissatisfied with the system and stops payment, whereupon the leasing firm sues the client. In the second sub-pattern, the client hires a consultant to recommend, select, or add value to system(s), vendor(s) and/or manufacturer(s). Problems occur in the development, installation, and/or use of the selected and possibly modified systems and the client blames the consultant, who may in turn blame the vendor/manufacturer. In both cases, someone other than the client and the vendor is being impacted by alleged problems with the system.
  • The Never-Ending Story: The client contracts with the manufacturer to develop and install a system. The project starts. The completion date slips. It keeps slipping. Each time the adjusted delivery date approaches, the project slips yet again. At some point, one of three things happens: the manufacturer/vendor abandons the project; the client cancels the project; or the manufacturer delivers a system that the client terms wholly inadequate and unacceptable. In some cases, the effort has gone on for years, with millions of dollars spent and little to show for it.
  • Unplanned Obsolescence: The client buys a system from the vendor. Some time later, the client discovers that the system either no longer meet its needs or that the vendor/manufacturer will no longer support it.
  • Unintended Consequences: The manufacturer makes some change in the functionality or configuration of the system, which is already in use. The change results in unpleasant or unintended consequences for one or more clients.

Wow. I’m counting three-for-six, maybe four. I don’t think “Unplanned Obsolescence” applies. (Yet.) And we’d don’t really have “The Never-Ending Story” because the website was force into production by mandate — not because it was ready — on October 1st. There’s a good argument for “Unintended Consequences” — such as the bogus insurance data being given out because of a change to the website — but I’ll let that ride for now. But we clearly have “Faulty Towers”, “Irrational Exuberance”, and even “Three’s a Crowd”, though it’s really more like “Thirty Five’s a Crowd”, given the number of contractors who apparently worked on this.

All this, combined with the steady (but not steady enough) stream of leaks about the internal issues, and I’m ready to call it: the website, as a functioning health exchange, is dead. I no longer believe it can be fixed (though I was always a bit dubious). I think you’ll have to throw it away and start over. Note that “start over” isn’t starting from scratch — there is a tremendous amount of analysis, requirements, and regulations, not to mention existing interfaces to various systems, as well as all the nifty graphic design work for the website. But at this point, i’m pretty sure that the architecture, design, and implementation are sufficiently septic that it will be faster and cheaper to start over than to salvage any significant amount of the code base.

I also think the health care exchange portion will be down for three to six months. Depending upon how deep the septic rot goes — if there are inherent problems with the Federal Data Hub and/or the various Federal system, it could actually end up being longer. If the Obama Administration was smart, it would simply push everything back a year. As Fred Brooks — whose name is now on the lips (and fingertips) of journalists and pundits everywhere — also said in The Mythical Man-Month: “Take no small slips.”  In other words, if your software project is going to be late, don’t lie to yourself and others and say, “We’ll have it done in a month or two.” Say, “We’ll have it done in six months”, and then, by Jove, have the damned thing done in six months. Maybe even five or four.

I suspect there are some very interesting conversations and confrontations going on right now in Washington DC with the purported “A-Team”. The techies, at least those worth their salt, are going to be brutally honest about what they find and about how long they think things are going to take. The Federal officials are going to be absolutely aghast at what they hear and will be set on getting the system up at the soonest possible date, if it goes down at all. The Federal contractors are going to be pointing fingers and covering their collective butts. Possibility of rude awakenings all around.

Interesting times. ..bruce w..

P. S. Click here to see all my Obamacare posts.

 

 

Be Sociable, Share!

Category: 2014 Election, Creeping socialism, Healthcare Reform, Information Technology, Main, Moment of Clarity, Obama Administration, Obamacare

About the Author ()

Webster is Principal and Founder at Bruce F. Webster & Associates, as well as an Adjunct Professor of Computer Science at Brigham Young University. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at bwebster@bfwa.com, or you can follow him on Twitter as @bfwebster.