Slashdot Mirror
Lessons From the Healthcare.gov Fiasco
Nerval's Lobster writes "In theory, the federal government's Health Insurance Marketplace was supposed to make things easy for anyone in the market for health insurance. But fourteen days after the Website made its debut, the online initiative—an integral part of the Obama administration's Affordable Care Act—has metastasized into a disaster. Despite costing $400 million (so far) and employing an army of experienced IT contractors (such as Booz Allen Hamilton and CGI Group), the Website is prone to glitches and frequent crashes, frustrating many of those seeking to sign up for a health-insurance policy. Unless you're the head of a major federal agency or a huge company launching an online initiative targeted at millions of users, it's unlikely you'll be the one responsible for a project (and problems) on the scale of the Health Insurance Marketplace. Nonetheless, the debacle offers some handy lessons in project management for Websites and portals of any size: know your IT specifications (federal contractors reportedly didn't receive theirs until a few months ago), choose management capable of recognizing the problems that arise (management of Healthcare.gov was entrusted to the Medicare and Medicaid agency, which didn't have the technical chops), roll out small if possible, and test, test, test. The Health Insurance Marketplace fiasco speaks to an unfortunate truth about Web development: even when an entity (whether public or private, corporation or federal government) has keen minds and millions of dollars at its disposal, forgetting or mishandling the basics of successful Web construction can lead to embarrassing problems."
And you have to realize that not everyone on the team has the same goals.
How much do the contractor companies get paid for overtime or change requests?
When I'm a contractor I will tell you what problems there could be that I can see. But if you tell me to do it your way I'll do it your way and collect my check.
Part of the problem is the usual problems with large-scale IT projects: it's not until you're well into it that you really get a grasp of what's involved. Nothing government-specific there, that plagues all large IT projects in private industry. Part of the problem, though, lies exactly in the fact that contractors were used. Contractors are mercenaries. They're here to deliver this project, and once they get their paycheck they're on to other work. They won't be around to deal with the fall-out and maintenance headaches from their work, and they don't have any vested interest in the quality of their work as long as it's good enough to pass review and get their payment check cut. In fact, poor quality is actually an opportunity to get paid twice since fixing the problems is a new project. Full-time permanent employees may not be as efficient as contractors, but on the other hand they've got a vested interest in making sure the system doesn't create any more problems than necessary because they know they're the ones who're going to have to clean up the messes. Long-term employees also have a better grasp of what's already involved in the current system, which translates directly into a better grasp of what the new system will need to do. They're less likely to miss major complications because they already have to deal with them.
Part of the problem with contractors is also the fact that large organizations like governments limit themselves to Tier 1 contractors. And there aren't a lot of those. So it rapidly becomes a situation where the Tier 1 contractors aren't really concerned about quality and results, because they know their customers will by policy refuse to consider any alternatives outside a small set and those others aren't any better about quality. If the government switches from contractor A to B, that means B can't take on another customer who takes their business to A (because A and B are the only Tier 1 firms and the customer can't consider anyone who isn't a Tier 1 firm) and it's a net wash for A.