Responsibility for Healthcare.gov's IT problems lie with dot gov
This was a management not a technology failure. Obama's error was not to empower technologists to tell him the truth
The launch of Healthcare.gov has not gone well. This is the Obama administration's fault.
In the immediate aftermath of the 1 October launch, it looked as if the problems were caused by a surfeit of interest. As the days went on, however, the problems persisted. The site's most basic interactive operation was creating a new account. This was required for all subsequent uses of the insurance market, but something like nine out of ten attempts failed. By the middle of the month, Consumer Reports was telling its readers "Stay away from Healthcare.gov for at least another month if you can", because the site could not perform, even under the conditions its designers imagined.
Much of the resulting "What went wrong and what now?" conversation has focused on the difference between the world-beating mastery of technology for Obama for America (OfA)'s re-election effort v the subsequent administration's considerably more plodding use of technology after taking office.
Several people central to OfA have pointed out that their work was, in many ways, easier than Healthcare.gov's. They could start from scratch, did not have to coordinate with as many outside entities, and could hire anyone they wanted, and work in any way they liked. Everything about the way the government builds large technical projects contrasts unfavorably, from specification to procurement, to hiring, to management.
But the most important distinction between OfA and Healthcare.gov isn't about how each project dealt with technology. It's about how each project dealt with reality.
Obama's re-election team developed new technology, which they tested early, often, and aggressively (very aggressively). The team working on Healthcare.gov tested it late, infrequently, casually. Most importantly, when testing at OfA showed something was broken, they fixed it. When the little testing they did showed parts of Healthcare.gov were broken, they launched it anyway.
Building a bad website is a technology failure. Launching a bad website is a management failure.
Many people in Democratic politics-tech circles are now suggesting that Healthcare.gov is the best anyone could have hoped for, by pointing out how cumbersome rules for procurement, hiring, and management are inside the government. All of these problems are real, but every one of those difficulties existed the day the Affordable Care Act was signed. (As Rusty Foster pointed out at the New Yorker, IT disasters aren't late-breaking events. The people working on the project know how its going.) Henry Chao, a deputy CIO at Health and Human Services and one of the only people with a clear-eyed view of the problems, had understood what was happening, and not happening, by March this year; yet, his superiors are said to have downplayed his concerns.
And it's visibly not true that the government is destined to fail. As Merici Vinton of the Consumer Financial Protection Board points out, when you have a process that prevents you from launching a big, critical site all at once, you just don't launch it all at once. Knowingly building a key part of an important initiative using a process you believe will fail is almost the definition of a bad decision.
It's possible to argue that in the current partisan atmosphere, denying the Republicans any fodder for complaint during the design of the insurance exchange was paramount. It is not possible, however, to argue that this strategy worked well. The same techniques used to avoid small early failures, like delaying specifications or avoiding partial rollouts, were the very things that created the large, late failures of the launch. The political strategy created a larger version of the very problem it was designed to avoid.
So, now what?
The obvious thing is to fix the site so that it performs its core functions. This work is already underway, though expectations of a "tech surge" are overblown. One of the most widely understood dynamics of complex software projects is that adding more workers tends to delay things, as the complexity of additional communications swamps the boost from having extra help.
But even after the site works, the underlying management problems are still there, and those should alarm us Democrats. The lesson from this launch isn't just about technological management; it's about the ability of officials to receive and act on bad news – surely, a core function.
Before Obama's remarks on launch day, someone should have said:
Hey, chief, say it's a soft launch, or the first day of public testing. Say we need feedback, or that the we're going to fine-tune it. Say anything but "Come and get it."
That, of course, didn't happen. Instead, Obama compared the site to Amazon.com – an irresponsible comparison, even if things were going well – and invited all comers to take a look. ("You don't have to take my word for it.") As bad as the site was on the morning of 1 October, Obama made it worse that afternoon, by raising both expectations and traffic.
Why would he do something that counter to his own interests? Because no one was in a position to warn him not to. Chao had been worrying, for over six months, that the experience was going to be "third world", but (as we now know from the first congressional hearing) responsibility was so diffuse, and the people who knew it was going badly lacked either the authority or the access to tell the president otherwise.
An organization paralyzed by the inconvenience of reality is having more than just procurement problems.
One obvious response is that the president of the United States shouldn't have to spend his time dealing with the launch of a website. But Obama and his team will now spend more time in the next 90 days talking about Healthcare.gov than they would have spent over the last 90 days, if they'd taken more time to understand how it was going. You can't make a piece of technology central to the most important achievement of your administration, and then let people run it without telling you the truth about its progress.
The business of government, from information-gathering to service delivery, will be increasingly mediated by the internet. As that becomes clear, we are at last having a conversation about how the government can get good at that. But as long as senior management believes that postponing failure is the same as avoiding it, and that not talking about a problem is the same as solving it, all the talented programmers and flexible work rules in the world won't be enough.
guardian.co.uk © Guardian News and Media 2013