# Request for Awesome ## Helping Governments Use Non-Traditional Vendors at Low Dollar Amounts [*Want to read an example background story? Click here.*](#background) ### The Problem There is a thriving community of civic technologists — people who apply internet technologies to governance problems. These people often work outside of government as volunteers, NGO staff, or entrepreneurs. They are well positioned to provide rapid, inexpensive information technology solutions directly to governments at all levels. The potential for cost savings, efficiency gains, and superior software results is powerfully attractive to many public servants. However, civic technologists and innovative public servants often find that procurement policies create a powerful obstacle to working together. Lightweight procurement of simple, low-dollar technical projects is challenging for government entities at every level, even when public officials are eager to engage. This is even more true for zero-dollar efforts to volunteer or donate specific useful software to governments. Procurement processes are generally optimized for major vendors working on very large projects. These processes are a bad match for lightweight projects that can be completed quickly by nimble teams. It should be easy for government entities to bid out the sort of small projects that dot the landscape of open data: projects that are often developed iteratively, based on specifications that may change substantially over their brief life cycle. Instead, these projects either do not get done, or they turn into much more expensive projects at the hands of entrenched vendors who know how to navigate the RFP process. ### The Solution Government agencies need a policy vehicle to bid out lightweight, low-dollar technical projects, and to attract bids from startups and other small, nimble tech organizations. This need not replace existing RFP processes—instead, it can complement existing systems. A simplified RFP process should make it easy for civic technologists to discover the opportunities that exist, streamline bidding, contract negotiation and payment, and allow for low-cost, low-stakes experimentation, failure, and learning. We call this tool a **Request for Awesome**, because that’s what it will let government procure. Although the specifics would surely vary between implementations, some of the best practices might include: - a born-digital process for submitting bids - a discovery interface for advertising RFPs - a minimum of confusing governmental procurement jargon - institutional support for applicants’ limited procurement experience This class of solution is sufficiently attractive that the White House appears to be experimenting with it, with a yet-to-be-defined system that they call "[RFP-EZ.](http://www.whitehouse.gov/innovationfellows/rfpez)" A similar effort may be warranted for government at all levels. Existing RFP processes are designed to protect against unfairness in procurement, and to ensure that public spending decisions are made in a cost-effective fashion based on objective criteria rather than personal favoritism. (This is one factor driving the cost and delay often associated with today's RFPs.) To protect against these same risks, any new procurement vehicle will need to have transparency and accountability designed in to it from the start. This is easy to achieve in a born-digital process -- done right, such a system is not only easy to use, but also easy to monitor, without much added cost or delay. Existing RFP systems can be opaque, obscure, and intricate, which sometimes cuts against the values they aim to protect. From a fairness perspective, it makes sense to try a new appraoch. **If you are a CIO/procurement officer and you would like to give us feedback please [open an issue](https://github.com/maxogden/request-for-awesome/issues)** *There is more to learn about this problem, and more to do to address it. We will update this page as our thinking evolves.* — Authored by: Esther Dyson ([@edyson](http://twitter.com/edyson)), Tim Hwang ([@timhwang](http://twitter.com/timhwang)), Waldo Jaquith ([@waldojaquith](http://twitter.com/waldojaquith)), Max Ogden ([@maxogden](http://twitter.com/maxogden)), Christine Outram ([@cityinnovation](http://twitter.com/cityinnovation)), David Robinson ([@dgrobinson](http://twitter.com/dgrobinson)), Christina Xu ([@chrysaora](http://twitter.com/chrysaora)) Thanks to Peter Koht ([@YuriAleks](http://twitter.com/YuriAleks)) for valuable feedback. Aspen Institute Forum on Communications and Society August 2012 Version 1.0, last modified August 7, 2012. The source code for this page is available [on Github](https://github.com/maxogden/request-for-awesome). ## A Case in Point: The San Francisco Experience In the summer of 2011 a small non-profit in San Francisco, the Gray Area Foundation for the Arts, ran a series of civic hackathons collectively dubbed “The Summer of Smart.” The idea was simple: bring together a variety of stakeholders to build prototype solutions to the city’s most pressing challenges—in one weekend. One of the most compelling outcomes was an application named “SMART Muni.” The app used GPS technology to track all of the city’s buses, allowing transit managers to monitor problems and delays in real time, a significant improvement over the walkie-talkies and paper clipboards that were used to track issues at the time. Senior leadership at San Francisco’s Municipal Transit Agency were thrilled. Candidates running for mayor were equally excited. The local news even ran a story celebrating the fact that a technology problem that the city allocated 5 years to solve was prototyped in 48 hours. There was just one problem. Even though SMART Muni was cost-effective, implementable and ready for a pilot program, the city had no way of adopting it. The traditional RFP program favored large established vendors and there was simply no way to procure a lightweight solution on a trial or permanent basis. One year later, the project remains incomplete. San Francisco has no method of engaging developers at the scale of the Smart Muni project, and the city’s poor financial state combined with their RFP process provides no path forward. Although all parties involved would like to proceed, there is no method to do so. Everybody loses: the Municipal Transit Agency, the app developers, and the citizens of San Francisco. *[Back to top](#top)*