We propose a new model for acquiring and operating custom software, in which a state or municipality builds in-house, and then sells to and adapts for other states and municipalities. A Government-to-Government (G2G) Sales model eases bureaucratic challenges associated with acquiring software, aligns incentives, and builds expertise and capacity within the state.
In the 21st Century, the visions of governments are carried out through software. When those capacities aren’t available as existing packages, the unique needs of the state require unique software. Unfortunately, acquiring custom software frequently involves total failure, years- or decade-long delays, massive cost overruns, or poor quality.
Typically, governments choose between building a solution in-house or commissioning one from an outside contractor. Insourcing requires extensive in-house expertise that not every state or local government will be able to acquire; outsourcing often requires years of paperwork and uncertainty. Paradoxically, overseeing the outsourcing of a large software project requires the exact expertise in project management that stymies insourcing attempts. In recent years, cooperative purchasing has become a popular third option, in which states or municipalities join together on a single contract. These agreements lighten the administrative burden of procurement, but contractors still often fail to deliver.
The model we propose—“Government to Government Sales”—is simple: First, a state or municipality solves a problem it has by building a solution in-house. Then, others with the same need buy it from the first, with adaptions as necessary. This approach combines the economies of scale of a shared approach with the aligned incentives of an in-house project.
G2G sales are contracts with governmental units, rather than private companies. As a result, it’s usually possible to avoid an RFP process entirely, as many state procurement statutes specifically exclude such deals.1 A G2G contract can be structured as an intergovernmental agreement, with the selling party offering services to the other party. In some cases, it may be advantageous to structure it as a consortium.
Notably, because the state government selling the software will also have the entire bureaucracy associated with using it, it may be possible in some cases for them to sell not just the software, but also the operation of it, allowing the purchasing state to outsource their entire department.
Unemployment insurance is one of the most procedurally complex uses of custom software in government. Many states, however, are using decades-old systems that require extensive manual input. At the start of the COVID-19 pandemic, unemployment benefit cases surged. Among 27 states using systems based on COBOL, there were widespread issues in providing reimbursements in time, leaving overall consumer spending 4.4% lower than non-COBOL states. This alone mapped to a $181B decrease in GDP.2 The states with legacy systems had rarely continued to invest in them—Colorado, for example, had a single COBOL programmer on staff.3
On the other hand, unemployment insurance systems are expensive to produce or modernize. As a result, the US Department of Labor encouraged the creation of intergovernmental “consortiums,” to build systems shared between states. Several are listed below:
| Consortium Name | Lead State | Successful rollout? | Model | Budget |
|---|---|---|---|---|
| ReEmployUSA | Mississippi | Mixed | Custom with Contractor | $100m |
| SCUBI | South Carolina | Yes | Off-the-shelf with adaptions from vendor | $50m |
| iUS | Idaho | Yes | Custom (In-House), G2G sales planned | $10m ($7.2m used) |
| MW | Maryland | Custom with Contractor | Still in planning |
ReEmployUSA’s has rolled out so far in Maine, which has been politically difficult, with complaints that the portal contains features based on Mississippi’s restrictive benefit laws, and has failed to pay out claims at all.4 In contrast, SCUBI has been somewhat more successful—possibly due to similarities between South and North Carolina’s needs.
IUS, however, is the most interesting. Idaho constructed the system for its own use for $7.2m—far less than any of the other systems, and $2.8m below budget—with a team of 12. The project took under 3 years—far less than the 9 for the original version of ReEmployUSA. In Idaho, it appears to have been an unmitigated success, with thousands of hours of labor and millions of dollars saved annually by the new system.5 Alone, this is a story of how insourcing with a capable and dedicated team can have large savings compared to an RFP process. With a consortium structure in place, however, Idaho is intent on selling the underlying technology to other states as well. In both legal and technical terms, IUS represents a model for other states as they expand their IT cost centers towards a G2G model.
As in the IUS case, states frequently insource major new capacities, and projects that are insourced are frequently more successful than ones sent to bid.6 However, most projects are still sent out to bid. As development appears to be a cost-center, software is often underfunded, causing stagnation and underinvestment in maintenance. As a result, states frequently fail to retain technical talent and expand their best technical teams to serve additional areas.
In contrast, the G2G approach should be sticky and spread virally—revenue-generating departments invite both political support and imitation. Further, as revenue increases, teams responsible for successful products should be able to increase quality and enter the market for other types of software needed by the state. In other words, a market dynamic of robust competition can be built entirely within the state.
Further, G2G cases, by nature of choosing an already-tested solution, decrease risks for procurement shops. Eliminating RFPs avoids bid risk, and having further adaptions built by the original team—rather than a 3rd party contractor with little knowledge of the structure of the system—is a common industry practice for ensuring quality remains high.
Though the G2G sale appears unusual, it’s not without precedent. For example, cloud.gov and login.gov are projects of the General Services Administration that sell to other federal agencies on a cost recoverable basis.
CIOs and tech teams are the most critical mover in realizing G2G development models. They alone are capable of structuring products to suit multiple use-cases, massaging procurement shops into cooperation, and championing their products. There are numerous other roles to be played, however, in facilitating a G2G transformation.
Governors should direct their treasuries to prepare guidance for treatment of revenue for G2G sales. They should also consider an inventory of marketable and adaptable internal software assets. They may consider instructing procurement officials to bring the sale of those assets into their mandates. Further, one of the key difficulties in buying G2G software lives in cases of non-aligned legal structures between states—governors have a key role to play in pushing legislatures to harmonize laws in cases where it’s more reasonable than making major changes to software.
Procurement officers should consider lightening their workloads by soliciting information from other states on their systems before issuing an RFP. In the long term, procurement offices should transform into offices with both a buying and selling mandate, and they should advocate for a commensurate expansion of responsibilities.
NASPO should add questions to their annual survey on which states are able to sell G2G, and which are able to buy without an RFP. Similarly, they should add legal guidance on G2G purchasing to the 4th edition of their procurement guide. NASCIO should also adjust their annual surveys in order to better track involvement in G2G projects.
State Legislatures should ensure that their codes allow non-RFP buying of other state’s items. Concretely, they should ensure that when adopting the ABA Model Procurement Code, they include section 10-205 Alternative A. They should also ensure that appropriations aren't a blocker to purchases.
Federal funders also have roles to play—they should consider whether mandating a G2G approach, or considering them, may help improve certain types of acquisition. GSA should also consider whether their cooperative purchasing programs can be adjusted to facilitate G2G sales.
While G2G sales may appear unusual, they sidestep fundamental principal agent problems between contractors and the state, while allowing successful teams to scale up. This “market-within-the-state” approach avoids both the excesses of 90’s-style outsourcings, and the unaccountable, monolithic state-sector that preceded it. Though there are difficulties for states, they pale in comparison to the trillions in maladministration that they can help avoid by bringing high quality solutions to bear on their problems.
See, for example, 30B§1(b)9 in Title III of the Massachusetts General Laws. For a counterexample, see California’s procurement code. ↩
Navarrete, Michael, COBOLing Together UI Benefits: How Delays in Fiscal Stabilizers Affect Aggregate Consumption ↩
The Verge: Unemployment checks are being held up by a coding language almost nobody knows ↩
Bangor Daily News: People are still stuck in Maine's unemployment vortex while multi-state leaders haven't met ↩