Why 18F’s New Approach to Procurement Reform Matters

Fast Track

Image courtesy of Flickr user lchunt.

In another recent post, I talked about how public sector technology procurement was not well suited for the digital age.

But there are some efforts underway that seek to identify new methods of procuring technology solutions for government. As these ideas start to take hold, there is hope that those in the govtech community will create a set of strategies for more successfully implementing public sector technology solutions.

Built to fail?

The design of procurement policies that are used by our federal, state, and local governments are meant to encourage broad participation by requiring things like public announcements of solicitations, open vendor meetings, and fixed deadlines for submitting responses. The hope is to make the process as predictable and transparent as possible, and to level the playing field so that any qualified vendor can participate.

Procurement policies are also designed to mitigate risk and to ensure that selected vendors are competent and capable of undertaking the work required in government IT projects. It is important that these policies be consistent with the government’s duty to be responsible stewards of public resources.

In light of this, there is a great irony in the outcomes that these policies often seem to produce.

Read More

GovTech is Not Broken

When we talk about the challenges that face governments in acquiring and implementing new technology, the conversation eventually winds around to the procurement process.

That’s when things usually get ugly. “It’s broken,” they say. “It just doesn’t work.”

What most people who care about this issue fail to recognize, however, is that while the procurement process for technology may not work well for governments or prospective vendors (particularly smaller, younger companies), it is not broken.

It works exactly as it was designed to work.

Read More

Hacking the RFI Process

rfi

The Seattle Police Department recently held a hackathon.

When the event was initially announced, there was a fair bit of skepticism in the civic technology community with more than a few people stating that the event would likely not be a productive one, for either the Seattle Police or those that chose to attend. I was one of those skeptics – I thought the event was too narrowly focused and that the problem that attendees would be working to help resolve wouldn’t appeal to a broad enough audience for it to work as the organizers probably hoped.

Read More

What if We’re Doing it Wrong?

Ever since the botched launch of Healthcare.gov, procurement reform has become the rallying cry of the civic technology community.

There is now considerable effort being expended to reimagine the ways that governments obtain technology services from private sector vendors, with an emphasis being placed on new methods that make it easier for governments to engage with firms that offer new ideas and better solutions at lower prices. I’ve worked on some of these new approaches myself.

The biggest danger in all of this is that these efforts will ultimately fail to take hold – that after a few promising prototypes and experiments governments will revert to the time honored approach of issuing bloated RFPs through protracted, expensive processes that crowd out smaller firms with better ideas and smaller price tags.

I worry that this is eventually what will happen because far too much time, energy and attention is focused on the procurement process while other, more fundamental government processes with a more intimate affect on how government agencies behave are being largely ignored. The procurement process is just one piece of the puzzle that needs to be fixed if technology acquisition is to be improved.

Right now, the focus in the world of civic technology is on fixing the procurement process. But what if we’re doing it wrong?

Things Better Left Unsaid

During the eGovernment wave that hit the public sector in the late 90’s to early 2000’s, tax and revenue collection agencies were among the first state agencies to see the potential benefits of putting services online. I had the good fortune to work for a state revenue agency around this time. My experience there, when the revenue department was aggressively moving its processes online and placing the internet at the center of its interactions with citizens, permanently impacted how I view technology innovation in government.

It’s hard for people to appreciate now, but prior to online tax filing state tax agencies would get reams and reams of paper returns from taxpayers that needed to be entered into tax processing systems, often by hand. Standard practice at the time was to bring on seasonal employees to do nothing but data entry – manually entering information from paper returns into the system used to process returns and issue refunds.

The state I worked for at the time had a visionary director that embraced the internet as a game changer in how people would file and pay taxes. Under his direction, the revenue department rolled out innovative programs to fundamentally change the way that taxpayers filed – online filing was implemented for personal and business taxpayers, and the department worked with tax preparers to implement a new system that would generate a 3D bar code on paper returns (allowing an entire tax return and accompanying schedules to be instantly captured using a cheap scanning device).

When these new filing options were in place, the time to issue refunds plummeted from weeks to days, and most personal income taxpayers saw their refunds issued from the state in just a couple of days. By this time, I had moved to the Governor’s office as a technology advisor and was leading an effort to help state departments move more and more services online. I wanted to use the experience of the revenue department to inspire others in state government – to tout the time and cost savings of moving existing paper processes to the internet, making them faster and cheaper.

When I asked the revenue director for some specifics on cost savings that I could share more broadly, his response could not have been further from what I expected.

He told me rather bluntly that he didn’t want to share cost saving estimates from implementing web-based services with me (or anyone else for that matter). Touting costs savings meant an eventual conversation with the state budget office, or questions in front of a legislative committee, about reducing allocations to support tax filing. The logic would go something like this – if the revenue department was reducing costs by using web-based filing and other programs, then the savings could be shifted to other department and policy areas where costs were going up – entitlement programs, contributions to cover the cost of employee pensions, etc.

All too often, agencies that implement innovative new practices that create efficiencies and reduce costs see the savings they generate shifted to other, less efficient areas where costs are on the rise. This is just one aspect of the standard government budgeting process that works against finding new, innovative ways for doing the business of government.

Time to Get Our Hands Dirty

A fairly common observation after the launch of Healthcare.gov is that governments need to think smaller when implementing new technology projects. But at the state and local level, there are actually some fairly practical reasons for technology project advocates to “think big,” and try and get as big a piece of the budget pie as they can.

There is the potential that funding for the next phase of a “small” project might not be there when a prototype is completed and ready for the next step. From a pure self-interest standpoint, there are strong incentives pushing technology project advocates to get as much funding allocated for their project as possible, or run the risk that their request will get crowded out by competing initiatives. Better to get the biggest allocation possible and, ideally, get it encumbered so that there are assurances that the funding is there if things get tight in the next budget cycle.

In addition, there are a number of actors in the budget process at all levels of government (most specifically – legislators) who equate the size of a budget allocation for a project with its importance. This can provide another strong incentive for project advocate to think big – in many cities and states, funding for IT projects is going to compete with things like funding for schools, pension funding, tax relief and a host of other things that will resonate more viscerally with elected officials and the constituencies they serve. This can put a lot of pressure on project advocates to push for as much funding as they can. There’s just too much uncertainty about what will happen in the next budget cycle.

Its for all of these reasons that I think it’s time for advocates of technology innovation in government to get their hands dirty – to roll up our sleeves and work directly with elected officials and legislators to educate them on the realities of technology implementation and how traditional pressures in the budget process can work to stifle innovation. There are some notable examples of legislators that “get it” – but we’ve got yeoman’s work to do to raise the technology IQ of most elected officials.

Procurement reform is one piece of the puzzle, but we’ll never get all the way there unless we address the built in disincentives for government innovation – those that are enforced by the standard way we budget public money for technology projects (and everything else). We’re having conversations in state houses and city halls across the country about the future costs of underfunding pensions, but I don’t think we’re having conversations about the dangers of underfunding technology with the same degree of passion.

Time for us to wade into the morass and come back with a few converts. We’ve got work to do.

Built to Fail

The great truism that underlies the civic technology movement of the last several years is that governments face difficulty implementing technology, and they generally manage IT assets and projects very poorly.

It can be tempting to view this lack of technology acumen as a symptom of a larger disfunction. Governments are thought to be large, plodding bureaucracies that do lots of things poorly – technology management and implementation are but one of the many things that governments do not do well.

But the challenges facing governments as it relates to technology are quite specific – there are a handful of processes, all easily identifiable, that work against the efficient adoption of technology by governments. Understanding why governments struggle to implement new technology requires us to understand what these factors are and why they negatively impact technology adoption so specifically.

The challenges that governments face in adopting new technology are not symptomatic of a larger disfunction – when it comes to the efficient adoption of technology, governments are built to fail.

The Government Procurement Process

Over the past year, primarily as a result of the botched rollout of the federal Healthcare.gov website, there has been significant attention given to the aspects of the government procurement process that hinder efficient technology adoption.

The process clearly does not work well for governments – and many would argue that it does not work well for technology vendors either. Typical government procurement rules shut out many small firms that may be well positioned to execute on a government IT project but that lack the organizational endurance to make it through the lengthy selection process.

The process is complex, costly and – most importantly – slow. To illustrate the magnitude of the issue, consider that in the City of Philadelphia the period between a contract award (when a vendor gets selected to work on a project) and the final execution of that contract (when the work actually begins) can take an average of four months for some projects. Some technology solutions have shorter release cycles than that.

This makes the government procurement process particularly ill suited (in its current form) as a means for governments to acquire technology. The pace at which new technologies mature is much more rapid, and the glacial pace at which the government procurement process moves can lock governments into outdated solutions.

The most under-appreciated characteristic of the procurement process is that it’s current design is largely intentional. Governments imbue the process with requirements and other stipulations that they hope will lead to outcomes that are deemed desirable. Each of these requirements adds to the complexity of the process and the burden of firms that choose to respond to government RFPs.

For example, almost every government has purchasing requirements for minority- and women-owned businesses, and many have requirements that local companies receive preference over firms from outside the jurisdiction. The objective is to drive more government procurement dollars to minority- and women-owned businesses and to local businesses that create local jobs and pay local taxes.

There are also larger, overarching values embedded in the procurement process. For example, fairness and transparency are values that inform requirements like the public posting of bids and related materials, ample public notice of vendor meetings, and the clear specification of when and how bids must be submitted.

Risk aversion is another value that impacts the complexity and cost of the public procurement process. It is this value that informs requirements like performance bonds, vendor insurance, scrutiny of company financial statements, and requirements for financial reserves—all things that seek to reduce the risk assumed by governments from engaging with a company to provide a good or service. Each of these requirements can make the procurement process more complex and burdensome for bidders, particularly smaller companies.

These features of the procurement process were designed with a specific intent, and few people would argue with the laudable goals they seek to encourage. Yet, one of the side effects of these requirements is that they make the process slower, more complex, and harder for smaller and more nimble firms to participate in.

In other words, the procurement process works largely as it was built to work, but its design makes it a lousy tool for acquiring technology.

The Public Budgeting Process

Perhaps more fundamental than the procurement process, the process used by governments to deliberate and adopt spending plans is deeply flawed as it relates to encouraging innovation generally and adopting new technologies specifically. There are built-in disincentives in the public budgeting process for agencies to demonstrate large efficiency gains that result in the need to outlay fewer dollars.

Public agencies that have unused allocations at the end of a fiscal year – money that is appropriated but not spent – inevitably see those dollars redirected to another agency or policy priority in the next budget cycle. Mayors, governors, and legislators see this as an effective way to allocate finite resources between competing interests. If an agency doesn’t spend down their entire budget allocation, they must not need it and a reduction is justified. In other words, the budget process works as government administrators have designed it to work – to reallocate resources away from agencies that don’t need them to agencies that do.

However, most agencies see this outcome as unfavorable – a diminution of their mission and a loss for the clientele that they serve and are advocates for. It can be a powerful disincentive for agencies to use new technologies to create efficiencies that result in cost savings.

Employee Recruitment & Retention

Most government employees – at the federal, state and local levels – are hired into an agency through a merit-based civil service system. The development of civil service systems, which are supposed to grant job opportunities on the basis of merit, were a response to widespread political patronage that was common long ago.

Most civil service systems have fairly rigid job classifications and salary structures, meant to provide transparency into what specific positions are paid and to place limits on the ability to reward specific employees because of political preference or for other reasons. There are typically requirements for public job postings, and advertisement of openings for specified period. Applicants are typically required to demonstrate fitness for a position and may often be required to take a civil service exam to demonstrate minimum competency on a particular subject.

Not unlike the procurement system, we imbue certain values into the civil service system in the hopes of fostering outcomes deemed favorable. For example, in the City of Philadelphia the children of police and fire personnel are given preference in the civil service process. This is not meant to suggest that granting such applicants a preference is inherently a bad thing, but (as with the procurement process) using the civil service system as a vehicle for fostering outcomes can come at the cost of making the process more lengthy and complex for all applicants.

Public sector salaries and benefits generally lag behind the private sector, and altering pay structures and adding new job classifications in response to changes in the world of technology can be difficult. This is particularly troubling for those interested in recruiting top IT talent into government because, unlike with many other kinds of government job types, governments are in direct competition with the private sector for IT workers. A “system administrator” or a “web developer” or a “project manager” requires largely the same kinds of skills and experience inside of government or outside.

Like the procurement process and the budget process, the civil service system works as it was designed to work. Unfortunately, the way that it works makes it ill suited for attracting and retaining a highly skilled IT workforce.

The Cost of Building to Fail

What’s particularly interesting is that even if the policies that underpin each of these processes doesn’t change at all in the next several years, the problems that governments face in adopting new technology will get steadily worse. That’s because the pace of change in the world of technology continues to accelerate – as it does, the difference between the rate at which new technologies mature and the rate at which governments can make budget or purchasing decisions, or reclassify jobs and salaries in response will get larger.

The old Hippocratic maxim of “first, do no harm” will be insufficient in addressing this problem. We absolutely must do better, and we must do it soon.

How Do we Fix It?

It’s important for advocates of successful technology adoption in government to understand why governments face so many challenges in acquiring and implementing technology. The processes that support paying for and acquiring technology, and the process for hiring IT workers are designed in a way that make them a bad match for the dynamics of the technology industry.

Knowing why governments face challenges in implementing new technology is important if we’re going to find ways to address the problem. When we examine the range of different approaches being advocated to help governments more successfully adopt technology, we should evaluate their merits based on the degree to which they address one or more of the processes detailed above.

For example, efforts to bring more highly skilled technology employees into government through groups like 18F in the US, or the Government Digital Service in the UK are meant to address the challenges faced in recruiting IT staff through traditional civic service channels. Projects like Screendoor are meant to address challenges that typically arise from traditional government procurement processes.

There are lots of other examples of efforts underway to help governments get better at implementing and using technology – too many to discuss fully here. But the ultimate success of each will be tied – I believe – to the degree to which they help address the challenges engineered into one of the three processes discussed above – procurement, budgeting and employee recruitment / retention.

Governments are not bad at adopting new technologies on accident. The processes that support the adoption of new technology were built to fail. Understanding this is the first step to fixing them.

Five Ways to Make Government Procurement Better

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.

broken-car

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]

The Case For Making Procurement Harder

Momentum seems to be building around public sector procurement reform.

Governments are starting to experiment with new ideas and new approaches to procurement that hold the promise of streamlining the process for bidders and producing better outcomes for public sector purchasers. Startups are emerging with new tools to make the procurement process easier, and the issue is on the radar of public sector innovators.

But with all of the focus on improving the procurement process – making it more transparent, more streamlined and simpler for bidders and governments – I think there is a case to be made that in order to improve the public procurement process we have to make the process harder. Let me explain.

How can governments responsibly evaluate proposals for work when they are not able to effectively and clearly articulate what it is that they want?

One of the biggest problems with procurement is how Requests for Proposals (RFPs) get written. Having written and responded to state and local government RFPs, and having evaluated more vendor proposals than I care to remember, I have a pretty good sense of how most RFPs get developed.

It essentially boils down to this: copy + paste.

Most government RFPs begin as a template that is provided by a procurement or legal department. Much of the content in these templates contains all manner of byzantine legal language that includes specific things vendors must do, information on how and when and in what manner to respond, etc. Much of this language will not change from RFP to RFP, and most governments typically employ language that is tailored to their own local processes and requirements.

The heart of any RFP is what is usually referred to as the “scope of work” – the section of the document that is added to the initial template that describes the specific deliverable(s) that a vendor is to provide. This is the most important part of the procurement document because it describes the thing (or things) that governments want to purchase with taxpayer money.

Yet all to often, this core piece of the RFP document gets cobbled together by looking at other RFPs that have been issued for projects that are further along in the development cycle. If another RFP – so the logic goes – was issued, received responses and has moved into the work phase then it might have language that can be reused in a new RFP, particularly if both are for similar kinds of projects.

So, for example, if a government agency or department wants to build a web or mobile app, construct a data warehouse or obtain an analytics tool they simply need to go and find and RFP that was issued for a similar project and use that as the basis for building the scope of work for a new project. And while there is some value in identifying RFPs for similar types of projects to help ensure that language used across different projects is consistent, I think this practice is dangerous and leads to bad technology choices.

Far too often, the process of writing what is essentially the heart of an RFP is done by simply copying and pasting text from other documents that have progressed to a later stage in the process.

This means the author probably has very little idea what they are really asking for – the process requires no effort on the part of the requesting agency to clearly describe what it is that they hope to get from the RFP. How can governments responsibly evaluate proposals for work when they are not able to effectively and clearly articulate what it is that they want?

This is the part of the procurement process that needs to get harder – we must avoid the temptation to create shortcuts that gloss over this important function of accurately and clearly describing what it is a government agency hopes to get from engaging with an outside vendor.

Part of the reason that governments are lousy at describing what they want – particularly from technology vendors – 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.

Until we find better ways to more broadly raise the technology IQ within governments – by bringing more hackers and makers inside government, or exposing those already inside to the hacker culture – we’ll continue to see copy + paste RFPs and poor technology selection by governments.

Experiments in GitHub Based Procurement

The City of Philadelphia is experimenting with some new ideas that we hope will change the way that city departments procure technology solutions. The “petrie dish” for some of the more interesting of these experiments is the social coding site GitHub.

The Background

GitHub logo

Philadelphia is looking for ways to partner more closely with local technology companies on small to mid-sized technology projects undertaken by city departments. One of the biggest challenges we face in creating these partnerships is our procurement process, which wasn’t designed in a way that is conducive to working with small companies and startups. This is not a new problem, and there are actually initiatives underway in Philadelphia to mitigate this challenge and create valuable partnerships with local startups.

One of the unique characteristics of Philadelphia’s procurement system is the process used for “Miscellaneous Purchase Orders” (MPOs). MPOs are are personal and professional services contracts valued at $30,000 or less for which city departments are required to obtain quotes from no less than three different vendors. Traditionally, the process of outreach to vendors for MPO projects has been decentralized and opaque. Department personnel would (and still do) reach out to vendors that they are personally aware of and obtain a quote for services.

This traditional practice is suboptimal for city departments because the pool of vendors from which quotes are obtained is limited. It is also not optimal for local vendors, many of whom may be qualified to provide the service desired but who may be unaware of the opportunity.

With the support of Philadelphia’s Deputy Mayor of Administration & Coordination and Managing Director, Rich Negrin, and at the direction of the Chief Innovation Officer, Adel Ebeid, we are experimenting with ways to change this practice for MPO projects (starting with technology projects), and we’re using GitHub to do it.

The Overview

$30,000 may not seem like a sizable budget for a big city project, but for some technology projects – specifically things like web site redesigns, mobile app development, etc. – this amount can go a long way, and provide ample funding for a small or mid sized effort. It’s probably not the right budget for larger companies but for small companies, or even freelance developers, this is nothing to sneeze at. It is these small companies that we want to create new partnerships with – today’s small startup is (potentially) tomorrow’s big company.

Philadelphia has a thriving technology community, and a robust network of developers and designers who would be ideal for many of the projects that city departments undertake as MPO projects. But until recently, there hasn’t been a mandate to rework how we conduct outreach for quotes on MPO projects. In addition, there hasn’t been the right concentration of knowledge within city government to think outside the box and try some new ways of doing old things.

The Managing Director and CIO have given the Innovation Management Team in the Office of Innovation and Technology latitude to try new things. A good chunk of this team is made up of former civic hackers, most of whom have collaborated on software projects with other developers in the past. When we got the green light to think of some new strategies, our collective interest settled almost immediately on GitHub.

The Experiment

We decided to try and use GitHub – from start to finish – as the mechanism for soliciting bids on a new technology project for the City of Philadelphia.

There are lots of reasons that we decided to use GitHub for this experiment. First, we wanted to utilize a platform that would resonate with technologists (duh, Github). Second, we wanted to have some insight into the quality of other work done by bidders – we expected that firms interested in bidding would already have GitHub accounts, allowing us to look at public repos to see what kind of solutions they were working on and how active they were in participating in other projects.

And finally, we were hopeful that by doing something different – something that potential vendors probably had not seen from a city government before – that we would encourage some “creative” responses.

To conduct our experiment, we needed the right project. The one we ended up choosing is called myPhillyRising – it involves the development of a mobile app to support the efforts of the PhillyRising Collaborative. PhillyRising is a “boots on the ground” effort that is run under the auspices of the Managing Director’s Office. It places city staff in some of the toughest neighborhoods in Philadelphia to support residents that want to bring together their neighbors and organize community events and address chronic neighborhood problems. The objective of the mobile app is to give both PhillyRising staff and residents in the neighborhoods they serve an easy to use tool for communicating, sharing information and organization events.

The first thing we wanted to do was to post the description of the myPhillyRising project publicly, to enable us to share it widely through various channels with our local technology community. We decided to use a simple GituHub Gist for this.

We asked interested parties that had questions to post them as a comment on this public Gist, allowing other interested parties to see both the question and our answers. For those that wanted to submit a response, we asked them to do one of two things:

  1. If they didn’t have a paid GitHub account, we asked that they create a private Gist containing their response and send us a link for review.
  2. For those with paid GitHub accounts, we asked that they create a new private repo containing their response and invite us to be collaborators on that repo.

While we anticipated that the process of using GitHub to solicit bids would be interesting, the response that we got from local vendors – and the nature of some of these responses – exceeded our expectations.

The Outcome

By the end of the submission process, we had received 9 high quality responses from local vendors – a number that far outstrips the number of responses received for similar MPO projects, and three times the number of responses required. This underscores the importance of publicly posting opportunities of this kind – if the city gives local technologists an opportunity to bid on work, local companies will respond.

In addition, several of the responses were highly creative – responding firms took advantage of the fact that the submission platform was a GitHub repo and made the most of the opportunity. One firm created a compelling webpage using GitHub pages to tell the story of Philadelphia residents who might use the new mobile app – they didn’t do this in addition to their standard response, this was their response. Another firm committed prototype code to their repo that let the evaluation team test drive how the proposed app might look and work on a mobile device.

Beyond the initial submissions from interested firms, we found that GitHub Issues were an effective means of interacting with respondents. We used this mechanism for followup questions, to request additional information and even to help us schedule in person meetings with finalists.

bug

question

Going into the final vendor selection, we expect to use the original GitHub repo that was set up to submit vendor responses as the mechanism for delivering the final working mobile application (and for all of the iterations and code reviews leading up to that point).

And ultimately, if we decide to release the code for the myPhillyRising app as an open source project, we can add the appropriate license and flip the winning vendor’s repo from private to public.

The Road Ahead

This experiment focused on a specific kind of city project. Even within the universe of MPO projects (which represents only part of the larger procurement picture), this effort was very narrowly focused on technology projects. This represents just a drop in the bucket of what the City of Philadelphia spends on technology projects.

That said, this exercise has given us valuable insights into ways that we can make the process of engaging with local technology companies easier and more efficient. The latitude provided by the MDO and CIO gave the project team room to try something that the city had never done before.

We are now expanding our efforts to reach out to local technology companies for small to mid-sized technology projects – aggregating new projects that have the right profile to a central website (a simple WordPress-based site) to make them easy to find and allow users to set up subscriptions for the kind of projects they are interested in. This will not be the last project to use GitHub as an integral part of the vendor selection process, and we are actively looking for ways to integrate GitHub into the processes used to interact with vendors on these projects.

We have much more work to do, but the steps that the City of Philadelphia is taking to engage more efficiently with small, nimble, local technology companies is really exciting.

It’s pretty cool to see GitHub being used as a part of these efforts.

Bizzaro Budgeting and Public Sector Innovation

Why is it so hard for governments to adopt innovative new technologies?

Why does the public sector lag so far behind the private sector in leveraging new technology to create efficiencies?

As an organization that works at the intersection of government and technology, these are questions we hear a lot at Code for America. Through our various program offerings, we are working to address the popular sentiments – and the underlying issues – that cause these questions to be asked so frequently.

Many observers point to the government procurement process as the chief impediment to adopting new technologies in government. I’ve made this same observation myself, and public sector procurement is an area ripe for reform and new thinking.

But looking more globally at the incentives that drive how governments apply resources to acquire technology we can see another area where reform is badly needed to encourage innovation – the public budgeting process.

Read More