Nothing in recent memory has focused attention on the need for wholesale reform of the government IT procurement system more than the troubled launch of healthcare.gov.
There has been a myriad of blog posts, stories and articles written in the last few weeks detailing all of the problems that led to the ignominious launch of the website meant to allow people to sign up for health care coverage.
Though the details of this high profile flop are in the latest headlines, the underlying cause has been talked about many times before – the process by which governments contract with outside parties to obtain IT services is broken.
The process clearly does not work well for governments – and many would argue that it does not work well for vendors either. Typical government procurement rules shut out many small firms that may be well positioned to execute on a government IT project but lack the organizational endurance to make it through the selection process.
What are the problems with the government procurement process and how can we fix them? How can we foster more participation in the procurement process by more firms that are qualified to do work? How can we lower the prices that governments pay for IT products and services and help ensure better quality?
Here’s my take on the major problems with the current system, and five recommendations for how we can start to fix them.
The procurement process is too costly and complex
The most under-appreciated characteristic of the government procurement process as it exists today is that it’s current design is largely intentional. Much like the federal and state income tax systems, we imbue a number of values deemed important into our procurement processes in the hopes of fostering favorable outcomes.
Requirements for women and minority-owned business participation; requirements that governments utilize local vendors; requirements that governments favor vendors that have any number of different traits or qualities – no one would argue that these requirements are aimed at producing positive outcomes. But the price of using the procurement system as the vehicle for achieving these ends means that the process is more complex for all participants. This is true, even if the positive outcomes desired are not realized, or realized to a lesser extent than hoped for.
The added complexity borne by all participants doesn’t guarantee the intended results.
Probably the most overarching value we imbue in the procurement system is risk aversion – in fact, much of the complexity and cost of the current system (for both governments and vendors) can be attributed to the desire to reduce the risk assumed by governments when partnering with outside firms.
Requirements like proposal and performance bonds, professional liability insurance coverage and the submission of audited financial statements (sometimes several years worth) – to name just a few – are all meant to offset the risk governments assume when they outsource work to a vendor. In some respects, these requirements can be deemed beneficial to governments and indicate prudent stewardship of public resources.
However, the widespread use of these and similar requirements by governments at all levels doesn’t seem to have lessened the incidence of IT project failures, and they can drive up the cost of IT projects by pricing smaller firms out of the bidding process. For example, many small firms argue that the bond industry doesn’t have a good understanding of how to underwrite IT projects, so it can be difficult to get a performance bond as part of a bid response. The result – many smaller firms that may be well qualified to do work simply walk away from the process. This is true even of these provisions don’t lower the actual risk assumed by governments as part of large IT projects.
Again, the added complexity and cost borne by all participants doesn’t guarantee the intended results.
The use of these risk mitigation provisions at all levels of government helps highlight a more fundamental problem that is at the heart of the broken procurement process in government – a shocking lack of IT knowledge within government.
A better much way for governments to hedge against the risks inherent in any large project – particularly IT projects – is to develop the internal capacity to manage and implement them successfully.
The procurement process moves too slowly
This is actually a fair criticism of government in general, but it is a particularly acute during the procurement process. To illustrate the magnitude of the issue, consider that in the City of Philadelphia the period between a contract award (a vendor gets selected to work on a project) and the final execution of that contract (the beginning of actual work) can take an average of four months for some projects.
We can make the same observation about the pace at which governments operate that we have about the procurement process – much of this is by design. But long procurement and budget cycles can drive away smaller firms that can not afford to invest significant resources in projects that don’t provide a return for months on end.
There are usually requirements for government RFPs to be posted publicly and widely advertised, and that all interested parties have an equal opportunity to participate through public bid notices and open vendor meetings. All of these requirements are meant to enhance the transparency of the bidding process but they can also add to the time it takes to select a vendor for a project, and for the vendor to begin work.
An emphasis on transparency in the procurement process is undoubtedly a good thing. But there are other steps that governments can might to dramatically enhance the transparency of the public procurement process without adding steps that slow the process down and discourage many prospective vendors from participating.
Some things we can do to make procurement better
With all of this in mind, here are – in no particular order – five suggested changes that can be adopted to improve the government procurement process.
Raise the threshold on simplified / streamlined procurement
Many governments use a separate, more streamlined process for smaller projects that do not require a full RFP (in the City of Philadelphia, professional services projects that do not exceed $32,000 annually go through this more streamlined bidding process). In Philadelphia, we’ve had great success in using these smaller projects to test new ideas and strategies for partnering with IT vendors. There is much we can learn from these experiments, and a modest increase to enable more experimentation would allow governments to gain valuable new insights.
Narrowing the focus of any enhanced thresholds for streamlined budding to web-based projects would help mitigate risk and foster a quicker process for testing new ideas.
Identify clear standards for projects
Having a clear set of vendor-agnostic IT standards to use when developing RFPs and in performing work can make a huge difference in how a project turns out. Clearly articulating standards for:
- The various components that a system will use.
- The environment in which it will be housed.
- The testing it must undergo prior to final acceptance.
…can go a long way to reduce the risk an uncertainly inherent in IT projects.
It’s worth noting that most governments probably already have a set of IT standards that are usually made part of any IT solicitation. But these standards documents can quickly become out of date – they must undergo constant review and refinement. In addition, many of the people writing these standards may confuse a specific vendor product or platform with a true standard.
Require open source
Requiring that IT projects be open source during development or after completion can be an effective way to reduce risk on an IT project and enhance transparency. This is particularly true of web-based projects.
In addition, government RFPs should encourage the use of existing open source tools – leveraging existing software components that are in use in similar projects and maintained by an active community – to foster external participation by vendors and volunteers alike. When governments make the code behind their project open source, they enable anyone that understands software development to help make them better.
Develop a more robust internal capacity for IT project management and implementation
Governments must find ways to develop the internal capacity for developing, implementing and managing technology projects.
Part of the reason that governments make use of a variety of different risk mitigation provisions in public bidding is that there is a lack of people in government with hands on experience building or maintaining technology. There is a dearth of makers in government, and there is a direct relationship between the perceived risk that governments take on with new technology projects and the lack of experienced technologists working in government.
Governments need to find ways to develop a maker culture within their workforces and should prioritize recruitment from the local technology and civic hacking communities.
Make contracting, lobbying and campaign contribution data public as open data
One of the more disheartening revelations to come out of the analysis of healthcare.gov implementation is that some of the firms that were awarded work as part of the project also spent non-trivial amounts of money on lobbying. It’s a good bet that this kind of thing also happens at the state and local level as well.
This can seriously undermine confidence in the bidding process, and may cause many smaller firms – who lack funds or interest in lobbying elected officials – to simply throw up their hands and walk away.
In the absence of statutory or regulatory changes to prevent this from happening, governments can enhance the transparency around the bidding process by working to ensure that all contracting data as well as data listing publicly registered lobbyists and contributions to political campaigns is open.
Ensuring that all prospective participants in the public bidding process have confidence that the process will be fair and transparent is essential to getting as many firms to participate as possible – including small firms more adept at agile software development methodologies. More bids typically equates to higher quality proposals and lower prices.
None of the changes list above will be easy, and governments are positioned differently in how well they may achieve any one of them. Nor do they represent the entire universe of things we can do to improve the system in the near term – these are items that I personally think are important and very achievable.
One thing that could help speed the adoption of these and other changes is the development of robust communication framework between government contracting and IT professionals in different cities and different states. I think a “Municipal Procurement Academy” could go a long way toward achieving this.
Look for more details on a Municipal Procurement Academy – to train state and local officials on best practices for IT procurement – in a future post.
[Note – picture courtesy of Flickr user Curtis Perry]