Contracting, Competence, and Healthcare.gov
The Times has a great piece today on why (as of October 13, 2013) the healthcare.gov exchanges are still not really working. Irrespective of the merits of the law itself, it’s fair to say that the exchanges have been an IT disaster so far for a wide variety of reasons. To my mind, here’s the key issue:
To avoid giving ammunition to Republicans opposed to the project, the administration put off issuing several major rules until after last November’s elections. The Republican-controlled House blocked funds. More than 30 states refused to set up their own exchanges, requiring the federal government to vastly expand its project in unexpected ways.
But the government was so slow in issuing specifications that the firm did not start writing software code until this spring, according to people familiar with the process. As late as the last week of September, officials were still changing features of the Web site, HealthCare.gov, and debating whether consumers should be required to register and create password-protected accounts before they could shop for health plans.
This is the worst kind of horrific IT malpractice. The one thing you cannot do if you want to have a successful IT launch is to issue specs too late, and God forbid going about changing specs when you’re two weeks before launch. The codebase for something like this should have been frozen weeks before launch for bug-hunting and stress-testing. That would be more than enough work for a broad project like this without having to worry about implementing new features or changing site architecture. Not all of this is the administration’s fault – Republican governor’s en masse decision to reject implementing their own exchanges forced a massive exogenous scope change on the program managers, who weren’t properly resourced – the original legislation envisioned a small role for the federal exchanges, and good luck appropriating additional funds for the change of scope. However, this didn’t just happen because of generic government incompetence, I think it’s best viewed as one of the “shadow costs” of a culture of contracting:
One highly unusual decision, reached early in the project, proved critical: the Medicare and Medicaid agency assumed the role of project quarterback, responsible for making sure each separately designed database and piece of software worked with the others, instead of assigning that task to a lead contractor.
Some people intimately involved in the project seriously doubted that the agency had the in-house capability to handle such a mammoth technical task of software engineering while simultaneously supervising 55 contractors. An internal government progress report in September 2011 identified a lack of employees “to manage the multiple activities and contractors happening concurrently” as a “major risk” to the whole project.
Excessive reliance on contractors has ruined government’s ability to manage projects like this. There simply isn’t the technical competence or depth of staffing in the government in order to either develop it in-house or to properly manage a gaggle of contractors. It’s almost certainly true that the government in this case should have appointed a systems integrator (lead contractor). The political appointees running the place simply didn’t understand the complexity of what they were dealing with. And of course, the endless government reliance on contractors has hollowed out most of the senior technical talent in the bureaucracy. The thing is, this isn’t something that has to happen!
This might sound like a nerdy candidate for high-school student council, but the White House should seriously consider creating a Department of Technology. The United States government is by far the country’s biggest consumer of IT contracting services, and by properly resourcing a central IT department they should be able to both improve project outcomes and save a large amount of money. It’s just ridiculous that you have all these bureaucracies sourcing and managing their own IT project when they very clearly don’t have the personnel resources to do so (except for the Pentagon). The Technology department doesn’t have to be large, but it does have to actually pay well enough to retain some talented employees – like the SEC, where the pay isn’t spectacular but it’s good enough to retain employees who might otherwise head to banks. In turn, it would manage IT contracting across the entire federal government to try to rein in costs and find efficiencies (e.g., implementing the same system at multiple Departments) and also act as an in-house contractor. Technology professional staffers (not political) would be deployed to manage complex IT projects instead of leaving that stuff to the political appointees.
Good luck getting that set up, though – all the contractors would be going balls-to-the-wall to stop it. Unfortunately, the rise of contracting created a political economy monster.