This article is written by Nicolás Díaz, Master in Public Policy at Harvard Kennedy School, former Bloomberg Harvard City Leadership Initiative Summer Fellow and former Coordination for Innovation and Modernization at Santiago City Hall

“It’s no longer just a matter of what we buy; what also matters is how we buy things, how quickly we buy them, whom we buy them from, and how quickly and creatively we’re able to upgrade them and repurpose them to be used in different and innovative…” — Ash Carter, 25th United States Secretary of Defense

“Governments write specifications like they are building the first BlackBerry. By the time the contract is awarded, the iPhone 12 will be out” — Oscar Hernández, Open Contracting Partnership, in a recent phone call where we talked about procurement

In 2019, the United States federal government spent billions of dollars buying technological products from the private sector.

More billions are spent at the sub-national level. And while not all digital disasters are as publicised as the Healthcare.gov debacle, it is believed that many of these investments are wasted in the maintenance of old legacy systems or through the creation of clunky new services that do not really meet user needs. And that’s because public sector procurement regulations were written with the goal of preventing fraud, not to ensure quality services.

They are aimed at making government contracting a uniform process, not on delivering the most value for citizens. But there are other reasons that make procuring technology especially hard for governments.

Why is this so hard?

Government agencies may purchase technology and digital services for a variety of reasons, from redesigning their main website to acquiring licenses to word processing software, to maintaining Customer Relationship Manager (CRM) systems.

Procurement is a complex multi-step process — this often makes digital services outdated even by the time they are approved

Some of these products are straightforward, simple and the market already has ready-made solutions available (this is often referred to as “off-the-shelve buying”). However, as the required products purchased get more complex, so too do the considerations for procurement turn more complicated.

The TechFAR Handbook, a guide created by the US Digital Service (USDS) to help federal agencies buy technology products, emphasises the need to include practices such as an agile methodology and user research in order to “[deliver] better results to our citizens and [improve] the way we deliver digital services to better serve the American people”.

In practice, the procurement of technology runs into issues when going through the usual process that a government goes through, especially for more complex projects. The Healthcare.gov portal, which had to be rescued after a disastrous launch, is the prime example. Here are some of the reasons why this is so hard:

  • Procuring takes time. Procurement is a complex multi-step process. This often makes digital services outdated even by the time they are approved. In Boston, for example, Angelica Quicksey, a service designer for the computer software firm Nava, identified that under the Massachusetts General Law, all procurements over $35,000 must compete through Request for Proposals (RFPs). These take a minimum of 65 steps and must be reviewed by at least four different offices. On average, this takes 133 days.
  • Government RFPs have highly specific requirements. When writing RFPs, procurement officials are used to specifying whatever service is being bought with as much detail as possible, in order to avoid contractors skimping on a part of the product. For example, if buying vehicles, they will detail the specific car model and even the type of tires. When buying services, the specification often comes in the form of how many hours of labor are requested (i.e., 20 hours of a web designer). The American venture capitalist Trae Stephens argues that this “commodification of engineers” puts efficient and talented development teams at a disadvantage while stifling innovation.
  • Agile increases transaction costs and requires a culture of collaboration that is open to user testing. According to the TechFAR Handbook, effective implementation of Agile methods will require more collaboration. “Acquisition personnel – and other stakeholders – should expect that Agile is a cross-functional and highly interactive process – both between agency team members and with the contractor.” Most governmental agencies do not have an organisational culture used to working across silos.

More active management and a turn towards results-driven government contracts will produce more value for citizens and government agencies

  • Procurement officials are often unable to make decisions about buying off-the-shelf or custom products. The complex multi-step process of procurement mentioned above also has the feature of splitting the role of the buyer. A line department may make the initial request, then another procurement specialist approves the requirement, and yet another awards the contract. As Oscar Hernandez, coordinator at the Open Contracting Partnership, told me on a phone interview, where we talked about his experience in procurement in Latin America and beyond, that this disconnect gives power to procurement officials who do not understand the market well and do not have adequate information to make decisions on whether to buy off-the-shelf or request a custom service.
  • Budgeting rules incentivise costlier contracts. Many agencies operate under a “use it or lose it” budget, which does not incentivise a decrease in contract prices. Trae Stephens points out that “if a government budget manager has a choice between building a program from scratch for an astronomical amount of money or buying that technology off the shelf for a fraction of the cost, they are strongly incentivised to do the former.”
  • Lobbying of the status quo. Finally, it has also been argued that the current normative framework heavily favours a number of powerful players – namely system integrators. It has been argued that intense lobbying keeps the current system running. Stephens writes: “There are political challenges/pressures as well. Take the F-35 program, for instance. The F-35 is being built by literally hundreds of sub-contractors who collectively represent 127,000 jobs in 46 states. It’s a logistical nightmare and (simultaneously) a governmental affairs wet-dream.”

Three innovations to improve tech procurement

Advocates of government procurement reform argue that more active management and a turn towards results-driven government contracts will produce more value for citizens and government agencies.

The Brookings Institute makes the case that development practitioners must look at reforms to make “procurement policies [that should] be evaluated based on how they have contributed to outcomes, rather than how efficiently they have mobilised inputs.” The Government Performance Lab at Harvard Kennedy School makes a similar argument for city governments to move towards results-driven procurement by avoiding “overly specific requirements for goods or services in procurements left little flexibility for contractors to design new solutions.”

There is indeed a path forward to make government more effective at procuring technology

Though using a different language, USDS’s TechFAR handbook tries to get at the same point through Agile: “software development starts with a Product Vision and does not specify exact system features but addresses the desired high-level functionality of the system (not the specific system features to achieve that functionality).”

The City of Boston turned towards results-driven procurement

The City of Boston has been at the forefront of results-based procurement for technology challenges. This means writing their RFPs with a focus on what the intended outcome of the project is. One example comes from a recent process for building an analytics data warehouse to connect data platforms across the entire city, which I was made aware of when I was doing another piece of research on city data analytics teams.

This is a vastly complex project. A sample of some of its language in the first page is shown in the next box, which showcases how the RFP begins with some of the needs that the product needs to fulfil (it needs to be scalable, it needs to allow for concurrent usage, it needs to be available, etc.). As the document goes on, it gets into more detail of what it means by each one of these metrics. It asks for clarification on how many people will work on this project, but it does not mandate specific roles or amount of hours — thus giving room for vendors to find the most efficient ways to create value.

Results-based RFP language in Boston

ANALYTICS ​DATA ​WAREHOUSE ​PLATFORM
REQUEST ​FOR ​PROPOSALS

“…the Department of Innovation and Technology plans to build a new Analytics Data Warehouse Platform (“the platform”). Our goal for the platform is to combine modern, scalable, cloud-based data warehousing technology with tools that make it easier for team staff to develop and use the data we collect. The platform will build upon existing technology and infrastructure already in use to provide greater value to the City across a variety of metrics:

Scalability:​ The platform will be able to scale incapacity to meet the team’s
current and future data warehousing needs, allowing the team to centralise
all of its data in a single platform.

Performance:​ The platform will provide a level of performance which is
sufficient to enable concurrent usage in a variety of ways (including ETL,
interactive or exploratory analysis, dashboarding, and automated reporting)
without substantial impact on the typical user experience.

Availability:​ ​The platform will use technology which is designed for a high
level of availability and efficient recovery in the case of problems, in order to
enable reliable service levels for mission-critical applications.

3.4 ​STAFFING ​AND ​KEY ​STAFF ​QUALIFICATIONS

Describe the team that would work on this project. Include a list of key team
members. Make the case for why they will be great partners on this project. Note if
any staff will be located in the greater Boston area and their general availability to
the City staff on this project.

The Department of Veteran Affairs (VA) ran a coding challenge before awarding a contract

In collaboration with Nava and USDS, the Department of Veteran Affairs (VA) innovated through a new way of assessing the talent of prospective vendors to modernise its highly complex appeal processing system. The vendors were invited to take part in a simultaneous 72-hour challenge, where all teams presented their work through GitHub. The winner of the challenge, the one that came up with the most reliable and effective piece of code, was then awarded the contract. As Nava write in their blog, the exercise was a huge success:

“A year into the contract, the team currently has launched and maintains a suite of applications for VA, including a tool to check that appeals are ready for review to reduce data errors, another tool that speeds up downloading the documents in a Veteran’s file, and others that automate various parts of the appeals process. […] In April 2017, following one tool’s launch, a subset of appeals that historically experienced long delays saw their time in a crucial step of the process decrease from 25 days to 8 days.”

The Massachusetts Digital Service created a new procurement vehicle to work with select vendors

The Massachusetts Digital Service has worked closely with the procurement office at the state government to work more effectively with vendors of digital services. According to Julia Gutierrez, an engagement manager I interviewed to understand how state governments are thinking about these challenges, the theory of change at the organisation is that product management should be in the hands of the government. Thus, the Digital Service will establish clear roadmaps of where each of their products needs to go and then establish some basic standards that the vendors must meet to be hired (i.e., they need to do Agile, they need to conduct user-research, they need to work with open-source interoperable solutions).

This method of working is different than other sub-national governments business-as-usual in at least three ways:

  • It necessitates a centralised agency that establishes strategic priorities and a roadmap for most of their products, how they all fit together and what should be bought versus built in-house
  • It establishes a new statewide procurement vehicle which creates a shortlist of vendors that meet standards that are on hold for the duration of the contract
  • It requires being active in reaching out to vendors and communicating with them

Change is possible

The above innovations reflect that there is indeed a path forward to make government more effective at procuring technology. However, two important questions sprout out of this research. First, to what degree can governments improve their practices while complying with their regulatory framework? On one end of the argument, one could argue that the current rules and regulations have sufficient flexibility to adopt agile practices. On the other, one could argue that trying to go around these regulations without reforming the underlying logic of procurement is moot. The answer probably lies somewhere between these two extremes.

Second, innovations in procurement such as the one put in practice by the State of Massachusetts rely heavily on active participation in the contracting by its digital service team. More research is needed on which of these innovations can incentivise better tech procurement across the entire organisation, without the active participation of a centralised digital team. Many public entities do not have the resources to establish a digital service team. Understanding which innovations allow for better tech procurement in a decentralised way would be useful for when resources are scarcer. — Nicolás Díaz

(Picture credit: Unsplash)