Civic Innovations

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.

Participation in government IT projects tends to be constrained to a subset of larger firms that regularly compete for contracts, while smaller, more nimble firms get squeezed out. In addition, the mechanisms meant to mitigate risk in government IT projects all too often seem to miss the mark in preventing technology projects from being delayed, going over budget, or failing altogether.

Clearly there is a need to redesign government IT procurement policies to more frequently produce the outcomes we desire.

In order to do this, government officials will be faced with some hard choices.

Time is of the essence

One of the most common complaints about the current technology procurement process is simply that it “takes too long.” Interestingly, you can hear this complaint from both government officials and vendors.

The length of time it takes for the procurement process to finish is a particularly acute one for technology projects. Smaller firms which may be proficient in the latest platforms and development methodologies can get squeezed out simply because they do not have the resources or the institutional endurance to go through the process.

In addition, the technology landscape can change quickly with new ways of building powerful solutions emerging every day. Governments are often saddled with obsolete technology and long procurement cycles can exacerbate this problem.

Why does the public procurement process seem to take so long?

If we look closely, we can see that the specific design elements that have been engineered into the technology procurement process to support the goals of transparency and risk mitigation are almost always time intensive.

An abbreviated solicitation may mean less time to get the word out to prospective bidders, or complaints that not everyone was aware of a specific procurement opportunity. Utilizing a fixed schedule for vendor meetings, responding to questions about a solicitation, reviewing bids, and announcing a selected firm can sometimes take months.

Even after an award has been made, the process can take several months before work actually begins. To illustrate the magnitude of the issue, consider that in the City of Philadelphia—where I once worked—for technology projects, the period between a contract award (when a vendor gets selected to work on a project) and the final execution of a contract (the beginning of actual work on the project) takes an average of four months.

This period of time is often used to review terms and conditions, legal stipulations, critical milestones and other issues that will govern the project as work gets done—all of which are meant to insulate the government from unforeseen risk.

So if time is the essential ingredient used to ensure that the procurement process is open and transparent, and also the primary tool used to ensure risk mitigation for governments then procurement reformers have some tough decisions to make. Reformers—and government officials—must either be willing to accept less openness and transparency (or, at least, the perception of it) and more risk for governments to expedite procurement cycles.

These don’t seem like the kind of tradeoffs that will be palatable to policy makers. We need new techniques for promoting openness and diminishing risk in the technology procurement process.

DESIGNING NEW STRATEGIES

One of the entities developing new techniques for mitigating risk in the technology procurement process is18F.

18F is a new group formed in the wake of the Presidential Innovation Fellow program within the General Services Administration (GSA). The organization, which focuses on bringing 21st Century digital practices to the federal agencies, takes its name from the location of GSA’s offices in Washington D.C.,at the corner of 18th Street and F Street.

Earlier this year, 18F began work on a new process for agile technology services for federal agencies. Interestingly, in developing this new approach the group zeroed in on the time component of the procurement process and articulated how this can often be a detriment to efficient technology acquisitions:

The reality is that business priorities, user needs, and technologies evolve and emerge on a continual basis. To keep pace, software acquisitions need to move at the speed of agile development cycles. Ideally, this means less than four weeks from solicitation to contract kickoff, and from there no more than three months to deliver a minimum viable product (MVP).

One of the more interesting aspects of this new approach from 18F is that it employs a new technique to help mitigate risk. Participating vendors are required to show their work in advance to demonstrate competency:

We’re requiring vendors to submit a working prototype based on a public dataset and show their work in a publicly available git repository. We’re also requiring ourselves to adopt a rigorous evaluation methodology to ensure that the vendors can meet our needs.

This approach is similar to one that was tested by the City of Philadelphia in 2013, and it’s easy to see how it could be a much more effective way to mitigate risk in government technology projects. Requiring prospective vendors to submit an example of their work in a public git repository promotes transparency and provides and an advance view of the quality of their work. In addition, it can help ensure alignment with the agile principles that 18F is trying to implement.

Some have criticized this approach because—for now—it is only available to vendors that are already on the federal Schedule 70 for IT services, and does not expand the universe of potential vendors to include firms that ordinarily might be shut out of the process. But I think this is exactly the kind of approach that is needed to redesign the way that governments procure technology services and solutions. The process of change has to begin somewhere, and as a first step 18F’s Agile Delivery BPA is impressive.

Though a relatively new organization, it’s worth noting that some have been more broadly critical of the efforts of 18F and have questioned the organization’s potential for lasting impact. Most of this criticism tends to focus on a lack of tangible projects that the group—as yet—can point to as indicators of change to the way that federal agencies deploy technology solutions.

But as important as individual projects that can be listed in a press release are, it is equally important that this group—and others working within the federal government—change the culture and processes that have for so long hindered the way that agencies use technology.

If the Agile Delivery BPA is any indication, 18F is an organization that will have a fundamental and long-term impact on how the federal government does business.

[Note – this piece originally appeared in Civicist]