USDR’s Suggestions for Funding Unemployment Insurance Modernization

At U.S. Digital Response, we have partnered with workforce development agencies in nine states — and counting — to help them improve their Unemployment Insurance (“UI”) websites, benefits portals, and processes to better serve their constituents.

Partner:

By Alyssa Levitz & Waldo Jaquith
Contributions By Jessie Posilkin

At U.S. Digital Response, we have partnered with workforce development agencies in nine states — and counting — to help them improve their Unemployment Insurance (“UI”) websites, benefits portals, and processes to better serve their constituents. Our approach is to identify the needs of a user (whether that’s a claimant, employer, or agency staff) and reduce their barriers to completing key tasks. We make iterative improvements to pieces of the UI system without tackling the entire system all at once.

While our approach is not flashy, it works. Historically, federal technology grants have resulted in “big bang” projects that try to do everything at once (and frequently fail). They measure success by the completion of static requirements and financial oversight processes, rather than in terms of the value delivered to end users. Based on our experience working with more than 20% of state workforce agencies, we instead see an opportunity for all states to embrace a hands-on oversight model and employ user-centered design, the now-standard Agile software methodology. User-centered design reduces wasteful spending of federal funding, incentivizes the creation of better software, and lets states work in the manner that they have found is more successful. We believe that projects that follow these guidelines (ideally driven by the agency itself) have a higher chance of success, and following are specific grant requirements that we recommend.

Lastly, we’re excited to see new practices by DOL and multiple states to avoid duplicative spending. For unemployment insurance administration, federal technology grants fund each state or territory to build functionally the same software, 53 times over. When the needs of states are identical (e.g., identity verification), DOL should provide application programming interfaces (APIs) and software as a service, instead of paying each state to procure identical software and services.

This document relies on GSA’s “De-risking Guide” (including the “Federal Field Guide” and the “State Software Budgeting Handbook”), H.R. 8235 (“Open Courts Act of 2020”), ACF’s Comprehensive Child Welfare Information System grant requirements (45 CFR § 1355.52–53), and EPA’s definition of “Open Source Software” (48 CFR § 1552.239–71)

Suggested Federal Grant Requirements for State Workforce Agencies

Based on our experience working directly with state workforce agencies, we believe that the following guidelines for federal dollars would significantly improve their efficiency and effectiveness.

  • Incremental, continuous delivery: States should not be permitted to award a large-dollar contract and then hope for the best until the end of the contract period. Instead, they should require vendors to deliver functioning software at regular intervals. This will allow states to see concrete evidence of improvements, for claimants, employers, or state workers to be able to realize some of the new technological improvements more quickly, and for the state and vendors to collaborate more effectively. Routine demonstrations of functioning software will provide DOL, Congress, and State workforce agencies with the insight into the project to provide effective oversight, and replace extensive reporting requirements.
  • Open source: States cannot collaborate with each other if they cannot share the source code that comprises the software. This is most effectively done by working in the open and releasing all federally funded work into the public domain, as is required by copyright law. This will allow, for example, a vendor in one state to begin from the work done by another vendor in another state, instead of performing costly rework for identical functionality, and will help to ensure software security. This will also allow future state RFPs to include links to the software source code, permitting vendors to evaluate it, which will reduce vendors’ uncertainty and consequently drive down their bids.
  • Data standards: States are unable to share components with each other or share data with the federal government if they all use different data standards. It is the proper role of the federal government to establish those standards, in close collaboration with states. Those data standards should include both data schemas and application programming interface (API) standards, to facilitate interoperability of both data and functionality.
  • Modularity: Each state should build or use a small ecosystem of dozens of loosely coupled software tools. This is the software architecture that makes it possible for states to reuse components from other states and to improve one piece of the system at a time, facilitating continuous improvement. The alternative is for states to replace their old monolith with a new monolith, which is modernization in name only.

Conclusion

Iterative improvements to the Unemployment Insurance System can lead to major improvements in the claimant, agency, and employer experience. State agencies can be challenged by the planning and oversight requirements of federal grants, because those requirements often make it impossible for agencies to employ the modern software development practices that are correlated with success. Changing how funds are allocated and how oversight is performed will free up state agencies to develop software in the manner in which they, and their vendors, are accustomed. This will get better software in the hands of government sooner, so that agencies can deliver on their missions. These suggestions are intended to allow us to start on the path to software as soon as possible for the benefit of all.