Next semester I’ll be teaching a course on why healthcare.gov initially turned into a disaster. Why? Because sadly, the failure of healthcare.gov was not special. Conservative estimates suggest over half of all IT projects are not completed on time or on budget. Others suggest the numbers are higher still. What did make healthcare.gov special was that its failure was so spectacularly public. As a result, unlike so many IT failures that stay hidden from public view, healthcare.gov is, somewhat paradoxically, safe to talk about. This makes it a wonderful case study to explore why so many large IT projects end in disaster.
Thinking about the course has me diving deeper into government IT procurement. Many of my colleagues in the civic tech space are convinced that procurement reform is critical to improving government IT services and fostering a better eco-system of IT vendors. I agree there is a great deal of good work that could be done to make procurement simpler and more effective. However, procurement is not a silver bullet. Indeed, I suspect that procurement reform, on its own, will have a limited impact, because it is not the central problem.
What procurement thinks it is trying to solve
There are two broad goals of government IT procurement policies that I think often get conflated.
One set of rules try to constrain and/or force people to make good technicaldecisions. Is the solution accessible? Is it secure? Does it protect privacy? etc…
The second goal is to constrain and/or force people to make good processdecisions. This is about ensuring fairness, accountability and broadly to prevent corruption. Did you get three bids? Have you laid out the specifications? Are you related to any of the vendors? Have the vendors donated money to any politicians? etc…
Both sets of rules have unintended consequences that make procurement slow and more difficult (although for many governments this can be a feature, not a bug, and making spending more difficult can be a net positive at a system level even if frustrating at the unit level).
The underlying assumption
Unpack these two goals — and particularly the first one — and you discover two underlying assumptions:
- IT implementations are treated like technical not adaptive challenges
The first assumption is that IT should be commoditized. While some IT purchases may be similar to buying a pencil, most are not. And if you are talking about an IT purchase that is custom build or the cost is north of $1 million, this is almost definitely not the case. Large IT implementations are complex with significant unknowns. It is impossible (despite organizations efforts) to spec out how all the problems will be solved in advance. Moreover this work takes place in dynamic environments where assumptions about the tech it will operate on, how users will interface with it and even what it product will need to do are dynamic. We treat IT projects like they are technical challenges — that we know exactly what must be done and that it can be all mapped out in advance — but they are almost always adaptive problems, where we don’t even know what all the problems are at the beginning of the process.
2. Effective process can force good decision making (or at least constrain bad ones)
Think of all the questions an enterprise — government or for profit — needs to assess: Will a solution work? Does it have a good user experience for our users? Can that UX evolve? Can the vendor adapt to unknown problems? Can they integrate with our current environment? To our future environment? Plus hundreds of other issues, all of which require nuance and knowledge.
But any set of procurement rules is about standardization process — so that the process can be evaluated, not the outcome. And this makes it harder to bring to bear these nuanced decision and knowledge because nuance, by definition, is hard to standardize. I fear that implicit in procurement reform is the belief that a good set of policies can design a process that, irregardless of who runs it, will prevent disaster and possibly even ensure an optimal outcome. If we assume procurement problems are technical problems for which the appropriate solution must merely be identified, then with the right “code” the machinery of procurement — regardless of who is manning it — should be able to select the optimal solution.
Both assumptions are, of course, patently ridiculous.
This is why I’m not confident that tinkering with the rules of procurement in the IT sector will generate much change. I certainly don’t think it will foster a new eco-system of service providers who will provide solutions that don’t fail 50% of the time. All the tinkering in the world won’t change the underlying issues — which is more than anything else: more than rules, oversight or the size of the ecosystem, is capacity of the people of running the procurement to evaluate technology and vendors capacity that matters.
I’ve seen terrible, terrible IT choices made by organizations and inspired decisions (like California’s Child Welfare Services RFP on which I’m writing a case study) be produced by virtually identical procurement rules and policies. The current rule set can allow a determined actor in government to make good choices. Could we do a lot better? Absolutely. But it is not the defining barrier.
This is, again, why I think USDS and similar digital service groups that try to attract talent that has worked on mass market consumer technology matter. Recruiting top technology talent into government is the single best strategy for ensuring better procurement. Deeply experienced people stuck with an okay rule set will be better than less experienced people stuck with an okay rule set.
And vendors generally agree. As a vendor, what you want more than anything is a capable, intelligent and knowledgeable buyer, not a set of rules that must be adhered to no matter the context.
And, to be clear, this is how the private sector does it. Ask Peter Thiel, Mark Zuckerberg, Elon Musk or Paul Graham (especially Paul Graham). None of them would outsource the technology choices for their start up or $1B dollar unicorn to a group of procurement officers equipped with even the most perfect set of procurement rules. Quite the contrary. They spend millions in stock options and money hiring amazing talent to make highly informed decisions to meet needs in a fluid and evolving environment.
So we should do Procurement Reform?
We should. We definitely should. But let’s recognize the limits. We should have rules that prevent corruption, nepotism or competitive practices. But unshackling people of rules may equip them to make more bad decisions as it does good ones. Let’s make rules that help people buy software and don’t make the process a burden, but our defense against poor outcomes shouldn’t be more rules, it should be an investment in pulling the brightest and best minds into government.
This is a problem I think digital service groups are trying to solve — creating a pipeline of talent that has worked with the latest tech and delivered solutions that have served hundreds of millions of users, flowing through government. So let’s just ensure that we invest in both. Procurement reform without the right people won’t get us there.