HealthCare.gov: Too Big to Succeed?
There's a simple but somewhat overlooked explanation for the debacle that is HealthCare.gov: It was so big that it had to fail.
Some unique insight into the Obamacare website's difficulties can be found in the "Chaos Manifesto," a treatise on tech failure by the Standish Group, an IT consulting company that collected data from 90,000 projects spread out over 18 years.
"Very few large projects perform well to the project management triple constraints of cost, time, and scope. In contrast to small projects, which have more than a 70 percent chance of success, a large project has virtually no chance of coming in on time, on budget, and within scope. Large projects have twice the chance of being late, over budget, and missing critical features than their smaller project counterparts. A large project is more than 10 times more likely to fail outright, meaning it will be cancelled or will not be used because it outlived its useful life prior to implementation."
Humans have a limited capacity for managing complexity. This makes intuitive sense, but hubris often trumps intuition. The only antidote is data, which might force overconfident managers to recognize the true probability of success.
Standish Group founder Jim Johnson recently told Computerworld that of 3,555 projects from 2003 to 2012 with labor costs of at least $10 million, only 6.4 percent were successful. An additional 52 percent were "challenged," meaning they were overbudget, behind schedule or lacking in functionality. The rest were scrapped or had to be started from scratch.
New Zealand, which, along with the U.S., is ranked by the United Nations among nations with the best e-government, funding decisions for technology projects are made using a risk-based system. Each potential risk is quantified to see whether the project should be implemented. Under such a system, Johnson's data would have killed the Obamacare website project before it even started.
Would health-care reform then be dead in the water, too, because the technological implementation posed too big a challenge? Absolutely not, says the Chaos Manifesto.
"It is very clear that reducing scope and breaking up large projects are difficult tasks. However, the rewards and benefits are quickly evident when the organization starts to receive value early in the project cycle. We, the writers, also have come to believe that there is no need for large projects, and that any IT project can be broken into a series of small projects that could also be done in parallel if necessary."
This is akin to the so-called agile approach, which breaks projects down into small, simultaneously developed, easy-to-test modules that do not require long-term planning. Matthew Douglass, the tech brain behind electronic medical-records company Practice Fusion, wrote recently that HealthCare.gov's problems could have been averted had the contractors taken "a gradual, agile approach." Practice Fusion, a large, complex platform used by more than 100,000 doctors with 50 million patients, employs the methodology.
So why can't the Obamacare contractors try such an approach? Actually, they did: Developer documentation includes discussions of work broken into small, quickly executable pieces, and of incremental testing -- both hallmarks of agile practices.
The project's troubles are related more to ideology than to the failure to follow a fashionable methodology. There would have been nothing wrong with rolling out the system area by area, even where states passed on setting up their own insurance marketplaces. Statewide sites like Covered California, Kentucky Kynect, Access Health CT and Washington HealthPlanFinder work better than the federal one because they are smaller and all the bugs were fixed in the first days of operation.
Functionality, too, could have been added gradually. The site could have initially allowed only browsing and calculating the cost of a health plan. Registration could have been added later. That way only those people who really wanted to buy insurance would need to register, and the servers would not have been overloaded when registration was finally available.
The rollout of a complex service like a new health insurance system for an entire nation is as much a logistical task as a technological one. Step-by-step implementation could have made it easier to break down the programming job into manageable modules. There would have been no single, enormous project with virtually no chance of success. It's the bureaucratic implementation that needed to be agile. The technical part would have followed.
(Leonid Bershidsky, an editor and novelist, is a Bloomberg View contributor. Follow him on Twitter.)