How Healthcare.gov Went Wrong
Here at DOBT we talk a lot about How To Fix Procurement, but you don’t hear a lot about why things go wrong. TheHealthcare.gov Fiasco is instructive in that it highlights every piece of our procurement process that’s broken. How, with a half-trillion dollar a year spend, could something like this botch even happen? Here’s how:
So why was it greased? Technically, “greasing” something means reducing its friction. Running a public procurement of this size, and visibility — it would probably take at least 18 months just to get through the procurement process and start the job. The awarded contract would almost assuredly get protested by those who didn’t win, and it would yield to a very public, very political, and probably very bad outcome.
So what they did instead, and very rationally, is they opted to take a contract that they already had — one with CGI Federal — and amended that contract to add the Healthcare.gov stuff onto it. CGI had already built some of the systems that Healthcare.gov would depend upon, and already had “boots on the ground” as it were. So giving the contract to this vendor for this kind of work “just made sense” if you wanted to get a website done in time.
The more likely answer is that the Affordable Care Act set a date in stone, and during the contentious passage of the bill, Congress and the President gave very little consideration to the federal procurement process. They wanted it done, and wanted it done sooner rather than later.
If you want an IT project to fail, allocate a bunch of dollars to it. If you want it to be a total disaster, do that, plus let Congress design the requirements and set the deadlines. The disconnect between Congress’ view of software and the developer’s view of software has never been more vast. Then you have a force multiplier: Congress’ seemingly willful ignorance over how the procurement process actually works.
Because that’s the way the regulation is written. Changing the federal acquisition regulation is a hard task, and it hasn’t been modernized in years. Frankly, I often wonder if the regulation could even keep up with the rapid developmental changes of the technology sector. As an example: today, in 2013, the regulation requires that all systems be Y2K Compliant.
The process leans towards a write-down-all-the-requirements-then-build-to-those-requirements type of methodology. That’s the kind of methodology you would use to build a space shuttle or a battleship, not the kind of methodology you’d want in building a website — the tools themselves may change over the course of the time it takes to build the site, and it becomes impossible to course-correct even if you know something’s going wrong.
The best source of contractor performance information to-date is probably the Project on Government Oversight’scontractor misconduct database. But this database only catalogs instances of misconduct, not poor performance. The federal government does keep a database of performance information, called PPIRS (hilariously pronounced “peepers”), but predictably, this database is closed off from the public.
But even as an internal tool, it’s inadequate. The GAO estimated that it’s actually used less than a third of the time. Why? Because the information in it is unreliable — and from what I’ve been able to determine from asking around inside the federal government, it’s because people are afraid of being sued by the companies for saying that they do a bad job.
Layered on top of the missing performance information is a complete lack of pricing information. The federal government keeps no central database of pricing information. You read that correctly: there is no database inside of the federal government that says “we paid X for Y.” This information is traditionally unshared because contractors view their pricing information as confidential, and while I might be convinced that it shouldn’t be shared with the public because of anti-trust/market coercion reasons, certainly we want federal buyers in good negotiation positions. There’s no reason this cannot be shared internally. Fortunately work on this has started, but I’m still shocked that it took 237 years to make it happen.
The White House has the power to do so. An executive order could be passed that would require an approval from the Office of Management and Budget for any IT integration over a million dollars. We already do so for every government form that gets created, as well as every high-impact regulation.
I think it’s time we very forcefully closed the book on this experiment of large federal IT integrations. The experiment has failed. Instead, let’s develop new ways to build software, and open the doors to the small to medium sized businesses who regularly do this job well, and at reasonable prices. America is the world’s hub for innovation, and we can do better than this.
A High-Friction, High-Overhead contracting process
The contract for Healthcare.gov wasn’t a fully competitive process. In fact, there was no competition for it at all. To get the work done, the Department of Health and Human Services used an existing contract it already had with CGI Federal to get the work done. The contract, as they say, was “greased.”So why was it greased? Technically, “greasing” something means reducing its friction. Running a public procurement of this size, and visibility — it would probably take at least 18 months just to get through the procurement process and start the job. The awarded contract would almost assuredly get protested by those who didn’t win, and it would yield to a very public, very political, and probably very bad outcome.
So what they did instead, and very rationally, is they opted to take a contract that they already had — one with CGI Federal — and amended that contract to add the Healthcare.gov stuff onto it. CGI had already built some of the systems that Healthcare.gov would depend upon, and already had “boots on the ground” as it were. So giving the contract to this vendor for this kind of work “just made sense” if you wanted to get a website done in time.
Requirements Written By People Who Don’t Understand Technology or Procurement
So, well, if it was going to take a long time to do a procurement, and to have an open competition, why didn’t they do that? Were they just lazy? Did they just not want to do the actual work of having a full, fair, open competition?The more likely answer is that the Affordable Care Act set a date in stone, and during the contentious passage of the bill, Congress and the President gave very little consideration to the federal procurement process. They wanted it done, and wanted it done sooner rather than later.
If you want an IT project to fail, allocate a bunch of dollars to it. If you want it to be a total disaster, do that, plus let Congress design the requirements and set the deadlines. The disconnect between Congress’ view of software and the developer’s view of software has never been more vast. Then you have a force multiplier: Congress’ seemingly willful ignorance over how the procurement process actually works.
Building a Battleship like a Website
Healthcare.gov isn’t a book by itself. It’s a chapter in an epic saga of large IT implementation screw-ups. FromSAM.gov to the DoD’s electronic healthcare record problem, an IT project’s probability of failure is positively correlated with the amount of dollars allocated to it. This experiment has failed. So why does it continue to happen?Because that’s the way the regulation is written. Changing the federal acquisition regulation is a hard task, and it hasn’t been modernized in years. Frankly, I often wonder if the regulation could even keep up with the rapid developmental changes of the technology sector. As an example: today, in 2013, the regulation requires that all systems be Y2K Compliant.
The process leans towards a write-down-all-the-requirements-then-build-to-those-requirements type of methodology. That’s the kind of methodology you would use to build a space shuttle or a battleship, not the kind of methodology you’d want in building a website — the tools themselves may change over the course of the time it takes to build the site, and it becomes impossible to course-correct even if you know something’s going wrong.
Lack of Pricing and Accountability
In a functional marketplace, companies that do a good job at a low cost grow. Companies that regularly do a bad job at a high cost shrink. In the federal IT marketplace this isn’t the case. This is for two reasons: the federal government has no idea how much stuff should cost, and the federal government does not do a good job at sharing performance based information.The best source of contractor performance information to-date is probably the Project on Government Oversight’scontractor misconduct database. But this database only catalogs instances of misconduct, not poor performance. The federal government does keep a database of performance information, called PPIRS (hilariously pronounced “peepers”), but predictably, this database is closed off from the public.
But even as an internal tool, it’s inadequate. The GAO estimated that it’s actually used less than a third of the time. Why? Because the information in it is unreliable — and from what I’ve been able to determine from asking around inside the federal government, it’s because people are afraid of being sued by the companies for saying that they do a bad job.
Layered on top of the missing performance information is a complete lack of pricing information. The federal government keeps no central database of pricing information. You read that correctly: there is no database inside of the federal government that says “we paid X for Y.” This information is traditionally unshared because contractors view their pricing information as confidential, and while I might be convinced that it shouldn’t be shared with the public because of anti-trust/market coercion reasons, certainly we want federal buyers in good negotiation positions. There’s no reason this cannot be shared internally. Fortunately work on this has started, but I’m still shocked that it took 237 years to make it happen.
Inappropriate relationships between Congress and Contractors
I’d be remiss if I didn’t finally mention that contractors are free to lobby the federal government. CGI Group, Inc,lobbied the federal government on the Affordable Care Act itself. Whilst there’s little data on what they lobbied for, or why they lobbied, it seems strange to me that the procurement process and the ethics process of government allows for this. The good point of the procurement process is that it divorces the buying decisions from the political decisions — meaning you can’t become president and then give all your buddies contracts. But this is a back-door way in to ensure it. No contracting officer wants a call from a Member of Congress asking why their backyard IT integrator wasn’t selected.Fixing it
These problems are systemic. I’m sympathetic to all the people involved in building Healthcare.gov — anybody that’s been following IT procurement knew it would be a disaster from the start. But at this point, it’s time we started fixing this stuff.The White House has the power to do so. An executive order could be passed that would require an approval from the Office of Management and Budget for any IT integration over a million dollars. We already do so for every government form that gets created, as well as every high-impact regulation.
I think it’s time we very forcefully closed the book on this experiment of large federal IT integrations. The experiment has failed. Instead, let’s develop new ways to build software, and open the doors to the small to medium sized businesses who regularly do this job well, and at reasonable prices. America is the world’s hub for innovation, and we can do better than this.
via A List Apart: The Full Feed http://blog.dobt.co/post/63655420372/how-healthcare-gov-went-wrong
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.