Obamacare and the 90% solution

| November 20, 2013


The first 90% of a software project takes 90% of the schedule.
The remaining 10% takes the other 90% of the schedule.
— The Metric Law of 90s

We’ve had a lot of percentages thrown around about the Healthcare.gov system lately: 30-40% remains to be done, 60-70% is complete, as of December 1st it will meet the needs of 80% of end-users, and so on. The problem is, these numbers are all being pulled out of hats (to put it politely) and have no apparent basis in any meaningful, objective metrics.

The inherent problem is that developing and debugging software is not a linear process. That is because we tend to complete the easy tasks, fix the easy bugs first, and defer the hard tasks and bugs for later. As I wrote five years ago (for Baseline.com) and recently reposted on my professional website:

A separate but equally common tendency in many large IT projects is to get a specific module or subsystem about 80 percent done — just to the point where it starts getting more difficult to push ahead — and then set it down to focus on another module or subsystem where you can zip along. Again, this gives the sensation of progress and allows you to report up the management chain how well things are going.

Make no mistake: In all this, you really are getting work done. Your user interface is visible and able to be evaluated by the eventual end-users; your modules and subsystems are all getting to the 80 percent-or-so completion point. You may be right on schedule or even a bit ahead, so everything’s looking great.And this is when the real problems start.

Because at this point, you find yourself dealing with all the hard-to-solve or hard-to-implement issues for the system under development. You may have calculations or data analyses that the system needs to make but you simply don’t know how to do it yet. You may have projected performance and throughput levels that your system can’t really handle yet. You may interactions with internal, back-end, and external systems that you’ve just implemented as stubs up until now. In short, you’re moving from the stuff that you know how to do to the stuff that you’re not sure how to do.

The real complication, though, is that you are facing these issues simultaneously for some, many, or even most of your different modules or subsystems. You can no longer put the hard work on hold and jump to an easy task, because all the easy work is done. Everything left to do is difficult and may require invention and creative breakthroughs. Progress suddenly slows down dramatically; the project schedule starts to slip, and slip significantly.

But wait! It gets even worse. Because you have deferred the hard work in different modules and subsystems across the board, you may now find yourself in a form of “solution deadlock.”

It works like this: Let’s say you have a hard problem X to solve in subsystem A; you also have a hard problem Y to solve in subsystem B. After brilliant work and brainstorming, you have come up with solutions to X and Y. The problem: the two solutions are mutually incompatible. In other words, the solution to X precludes the solution to Y, and vice versa. This may seem unlikely, but I have seen it any number of times, particularly where problem X is a functionality problem requiring intense data retrieval and processing, while problem Y is a performance problem requiring a much quicker response time or heavier load processing than the system can currently handle.

Now imagine that you have a dozen or so different “hard problems” to solve — with any number of interdependencies and exclusions — and you can begin to understand why so many IT projects get to the 80 percent to 90 percent “completed” stage and then get stuck there for months.

Now, from Henry Chao’s testimony yesterday (here’s a great summary by Jim Geraghty of National Review), the Healthcare.gov system isn’t even close to being 90% done, and they’ve definitely deferred some of the most difficult work. My sister and erstwhile colleague Deirdre Poeltler has been doing software engineering, software architecture, and IT project management for over 30 years. Here was her reaction:

Chao: “There’s the back office systems, the accounting systems, the payment systems, they still need be built.” As a former career Software Development Project Manager who once upon a time was responsible for the development of software accounting systems and payment systems, I’m stunned. That’s the hard part. You can’t get the money wrong.

Here’s what’s so tricky about the 90% solution: unless you have been rigorous in your internal reviews and testing, you may really think you’re 90% done, and that it will only take another 10% of the overall allotted schedule time to wrap things up. This is where it becomes very easy for the project to go into oscillation mode: always appearing to be just a few weeks or months away from completion, but not reaching that point for a long time. Like the torment of Tantalus, the fruits of success always appear to be close at hand but are perpetually out of reach.

In the meantime, the Administration appears to be following elements of what I said back on October 26th that I would do if I had just five weeks to get something working:

I would swap out the entire ‘Apply Now’ section (and the supporting backend) for a very simplistic information gathering system. This system would gather your information (including your estimated annual income, with no verification). That’s pretty much it. At some time later, the government would then send you — via mail or e-mail — some form of comparison chart or document showing available plans. It would also have instructions to have you call or contact the appropriate insurance providers or your state Medicaid provider directly. The document would also contain the ‘subsidy calculation’, which may be reduced to a simple comparison of  your declared estimated income against a chart/formula. This approach should cut out almost all the interfaces with existing Federal systems and with private insurance companies. It would also defer the sticker shock until you got that list of available plans in the mail/e-mail.

December 1st should be interesting. Pass the popcorn.  ..bruce w..

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


Be Sociable, Share!

Category: 2014 Election, Creeping socialism, Healthcare Reform, Idiot bureaucrats, Information Technology, Main, 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.

Comments (1)

Trackback URL | Comments RSS Feed

Sites That Link to this Post

  1. Obamacare and the Bursting Dam : And Still I Persist… | November 25, 2013