Some great insights into how a dysfunctional US government IT procurement system helped ruin the launch of healthcare.gov have been penned recently by the likes of Mark Headd, Alex Howard, and Clay Johnson. The basic thrust of these analyses is that balky and process-heavy IT procurement rules and habits led to the selection of slow, risk averse vendors who in turn cranked out unimaginative, delayed and non-functional products. Healthcare.gov’s woes are thus as much a result of process design fails as bad code. All three pieces deserve a read.
Also touched on briefly in these (and other) posts is the tension between well-intentioned transparency and anti-corruption efforts and these cumbersome procurement rules and regulations. As an anti-corruption and transparency practitioner, I thought that tension deserved a little more unpacking.
The interesting part of the debate, from an anti-corruption perspective, is that requirements for things like publicly open (and long) RFP periods, exhaustive requirements-first methodologies for soliciting and building software, and opportunities for losing bidders to protest results are all classic components of any anti-corruption framework. For better or for worse (arguably for worse in the healthcare.gov example), these are not arbitrary rules put into place by crusty bureaucrats looking to justify their paychecks. They are instead tried and true methods for limiting collusion, patronage, and influence peddling.
But do they really work in the contemporary era, especially in a fast-moving sector like IT? That’s the more interesting question. Corollary to that question, are there acceptable trade-offs that would promote more efficient IT product delivery without opening the spigots to rampant corruption in IT procurement?
The traditional anti-corruption cocktail of bureaucratic processes — including extensive public calls and competitions for public contracts as well as requirements-focused procurement methods — is rooted in the equation developed by scholar Robert Klitgaard to define where and when corruption might be more likely to occur: C = D + M – A (Corruption = Discretion + a Monopoly over information – Accountability). Basically, give a Federal IT buying officer the discretion to buy what she wants plus complete control over the process with no threat of being held accountable and you’ve teed things up for a corrupt act. This makes plenty of sense and explains the intent of the current rules.
Are there ways to soften and/or nuance the process so that we could achieve much or all of the C = D + M – A intent without the negative impacts witnessed in healthcare.gov? I think it’s possible. Here are a few ideas worth exploring:
- While open and competitive bidding processes are essential for anti-corruption reasons, we can at least give small and disadvantaged firms some help in leveling the playing field with large, incumbent IT contractors. Instead of arbitrary set asides for small businesses and minority-run firms, I’d rather see those dollars spent on government-paid handlers and process gurus who know how government IT procurement works and can help those firms punch above their weight when going up against the Booz Allen Hamiltons and CGIs of the world. In other words, consider giving these firms a taxpayer sponsored body or two to help them navigate the process more competitively rather than overhauling the rules of the game from scratch. This would also give buying managers the freedom to select smaller, more nimble firms for two reasons: 1) those firms would actually be eligible, having mastered the process thanks to their handlers, and 2) getting rid of set asides would allow more contracts to be awarded on pure merit rather than affirmative action.
- If we begin a move towards output-focused IT procurement and away from requirements-first methodologies, then we really need to ratchet up the accountability when things go wrong. Specifically, this means that government IT buying managers need to get demoted or fired if they embrace an agile process that goes spectacularly wrong, and their vendors need to be blacklisted from future government work. That’s a fair trade-off in my mind. Agile processes are great for many reasons but open the door to high levels of discretion, which we know is one of the key ingredients for corruption. Balancing a larger “D” in the formula with a larger “A” is the best way to make agile a wash from an anti-corruption perspective.
- Be realistic about who engages in these procurement process. Tip: it’s not “the public” or some large, unnamed swath of the American private sector. Instead of designing the transparency and participation elements of government IT procurement around a flawed notion that my mother spends an hour each evening reading the Federal Register, let’s look to streamline public announcement and commenting periods both in duration and venue. On any given procurement there may be no more than dozens or hundreds, not tens of thousands, of vendors potentially interested and qualified to compete. Let’s not assume it takes four months to receive 13 comments on a draft public RFP. At the same time, let’s be more proactive in targeting that small, specialized community in ways that are meaningful to them — try a Twitter chat instead of a public Q&A message board.
(Disclosure: Eric Gundersen, a Global Integrity director currently on leave from the board, runs Development Seed, one of the contractors involved with building healthcare.gov. Development Seed built the one part that actually works – the front end web framework.)
