Thursday, November 7, 2013
Why ObamaCare O'Bombed so badly
ObamaCare - Over 6 people Served.
I've been in Information technology most of my working life so I understand it's complexities.
The inevitable failure of ObamaCare, and of every other "overly ambitious to the point of being fictitious" software project, is due to stupid management. In this case, self centered ideological Politicians who set a deadline in stone, based on a bill which no one read, for a system that no one understood.
It was all wishful thinking, with time and costs pulled out of thin air, to sell the project and get Politicians elected. There is zero chance of fixing the system in the five weeks they promised; The work will go on and on and the real costs will be in the billions and then many times over again in maintaining the system for every change in the ACA.
But if people knew there were problems, why was the project allowed to bomb so badly?
Risk management expert Robert Charette:
This is all about plausible deniability. Once it was real apparent that this thing was going to be a turkey, nobody wanted to say a thing.
You’ve got these different groups that were in charge of different portions of the ObamaCare website, each hoping that the others were going to admit that there was a problem. And when none of them admitted it and the thing blew up on 1 October and the days following, everybody said, "Well, we didn’t know." I wonder if they really think we’re all that stupid.
HealthCare.gov is a huge system of systems and it’s extremely difficult to manage these things even in the best of times. You have so many different interfaces with so many different assumptions controlling how the individual systems operate. And they’re rarely built with enough flexibility to be used by lots of other systems...IRS systems, the Department of Homeland Security systems, or any of the other ones we’re talking about...were never created to be connected to something like HealthCare.gov. ... Imagine being given Lincoln Logs, an erector set, and Legos and saying, "I’m gonna make something where everything fits properly." That’s not likely to happen. It takes a tremendous amount of time just to understand how things operate, so that when you begin to design things, you can actually have information pass through all these interfaces seamlessly. Any problem at any one of these junctures will cause a person’s application to stop.
What you don’t want is somebody making a change that nobody else knows about. Just getting hold of who’s doing what to what, and understanding what the implications are is itself going to be a huge undertaking. For every bit of software, you want to have some release control. I haven’t seen anything to suggest that type of management.
How much will it really cost?
It’s likely to be in the billions by the time everything is said and done. It’s hard to give an exact figure because of the way the contracts are managed. There’s a lot of ways to put money toward Obamacare IT but not have it ever show up as such. So it’s going to take a long time for even the government auditors to figure out how much money is being thrown at this thing. The bigger issue to me is not the rework cost, but how much money is going to be spent maintaining this thing. Changes to the law will have ripple effects across every one of the interfaces in this system of systems, which will mean changes, the possible introduction of errors, and end to end testing. If we extrapolate, the maintenance cost is likely to be three to five times higher than the development cost over the next 10 or 15 years.
Learn your lesson.
Even if they fix ObamaCare, the government system will still remain completely and irreparably broken. See www.TheSocietyProject.org for why, and how, we must use the Amendment Process to fix it.