After 400 software fixes and major hardware upgrades, the Obama Administration is claiming to have achieved its goal of transforming HealthCare.gov into a web-site that will operate smoothly for "the vast majority of users." That's important, because the site is central to implementation of the most sweeping reform of federal healthcare services in half a century. Whether the site is fixed or not, though, its faltering debut will probably be studied in business schools for decades to come as a classic example of inept project management.
Having made my career in the field of defense analysis, I have seen many such foul-ups in military acquisition projects. It's a rare weapon system that gets delivered on time, on budget, and with all performance specifications satisfied. The contractors always get blamed when weapon programs go awry, but usually it's the government customer who is really at fault, and that looks to be the case with HealthCare.gov too. The Center for Medicare & Medicaid Services (CMS) overseeing HealthCare.gov appears to have violated every principle of sound project management. Here's my personal list of what the government did wrong.
1. Unrealistic requirements. This is the first time anybody has ever tried to develop a single web-site where diverse users could (1) establish an on-line identity, (2) review hundreds of health-insurance options, (3) enroll in a specific plan, and (4) determine eligibility for federal subsidies -- all in real time. The way people have traditionally accomplished these tasks is to go to an insurance agent and work through the possibilities over a period of several days (if not longer). It probably wasn't realistic to expect that so many arcane functions could be accomplished in a couple of hours by users who lacked advanced computer skills or high-speed internet service. The improved homepage of HealthCare.gov alerts users to other options for enrolling, like old-fashioned paper applications.
2. Technical complexity. As often occurs with poorly-planned weapon projects, unrealistic requirements for HealthCare.gov resulted in an extraordinarily complicated system that is difficult to maintain. There are just too many moving pieces. A typical user might have to navigate 75 screens to get to their goal of obtaining insurance, and the whole system contains over a thousand screens. A total of 55 contractors were hired to produce the various pieces, and in order for all the steps to work CMS had to involve five federal agencies, 36 states, and 300 private-sector insurers offering well over 4,000 plans.
3. Integration responsibility. The government has difficulty maintaining organic expertise in information technologies, because the private sector often hires away the best talent. An executive at a big tech firm engaged in government contracting once remarked to me that whenever he meets with government project leaders, he always knows he is talking to the people industry didn't want. Despite weak organic IT capabilities, though, CMS decided it would take charge of integrating all the parts in HealthCare.gov, and testing the end product to assure functionality. The results show why the military almost always hires outside companies to serve as lead integrator.
4. Fragmented authority. There seems to have been a great deal of infighting within CMS over how the web-site would operate and what the user experience would feel like. With three different parts of the bureaucracy contending for control -- the IT shop, the policy shop, and the communications shop -- key decisions were often delayed, guidance to contractors was inconsistent, and nobody was truly in charge. Government employees appear to have concealed critical information from each other, and on occasion mandated that certain features be implemented or suppliers be used despite contractor warnings that problems would result.
5. Loose metrics. Perhaps the most important factor in keeping complex projects on track is for managers to utilize rigorous, unambiguous performance metrics in measuring progress. The government said in a report released on Sunday that it has made "improvements in the site's key operating metrics over the last several weeks," which is a tacit admission that it didn't initially have adequate ways of measuring progress. Absence of reliable metrics helps explain why federal officials didn’t realize until late in the game that HealthCare.gov might not be ready for prime-time.
6. Inadequate testing. The Washington airports authority announced this week that it would delay opening a new subway line to Dulles Airport so that additional testing of software could be conducted, stating that its overriding goal is "safety." The people overseeing HealthCare.gov clearly had a different management philosophy. Despite repeated warnings from contractors that more testing of system components was needed, CMS was determined to see the site go live on its planned debut date of October 1. Because important decisions about the site were still being made only days before this date, there was almost no end-to-end testing of the site before it became operational -- which is why hundreds of software bugs had to be found and fixed later.
7. Aggressive schedules. You wouldn't think that standing up a web-site after literally years of planning might entail overly aggressive schedules, but in the case of HealthCare.gov the disorganized bureaucracy took so long to make design choices that the back end of the project was way too hurried for comfort. When the Pentagon develops a missile-warning or weather satellite, it sometimes delays launches for years to make sure all software and hardware issues are resolved. One vital satellite called the Space Based Infrared System was delayed for over a year due to concerns about software glitches; when the satellite finally reached orbit, though, it worked perfectly. CMS chose to stick with its schedule even as problems multiplied, and got a site that didn't work.
8. Administrative blindness. The Center for Medicare & Medicaid Services may not have had good management practices or metrics for identifying problems, but that doesn't mean it didn't get plenty of warnings about potential problems with HealthCare.gov. Outside consultants and contractors on the project repeatedly warned government officials about functional difficulties with some features of the site, lack of adequate testing, poor protection of sensitive information, and the like. Sometimes CMS listened, but much of the time it was in denial about how defective the site was. It never adequately informed the White House about potential problems, and never subjected HealthCare.gov to systematic review until after the site went live and nearly collapsed.
These fundamental mis-steps explain why the government was able to competitively hire some of the best IT talent in the world, and still get sub-optimal results. The stringent demands of the military acquisition system exist in large part because the Pentagon wants to avoid the kinds of mistakes that CMS made in standing up the Obamacare web-site. It's likely that the administration will eventually fix the site or find work-arounds for its signature policy initiative, but it will probably never get back to where it could have been if competent government overseers had made sure HealthCare.gov worked right from Day One.
