Following a revenue decline in FY2023 and slow revenue growth in FY2024, the National Association of State Budget Officers reports that state general fund spending in fiscal 2025 enacted budgets is expected to decline slightly. Jurisdictions are operating with uncertainty when it comes to budget planning.
Drilling down into some specific examples of which there are countless more:
In budget-constrained environments, effective and efficient delivery of services across federal, state, and local government agencies is functionally impossible without technology. However, not all software investments are made equal, and there is one defining characteristic that separates good technology investments from the wasteful — how well it directly supports public servants’ ability to make an impact.
Technology that empowers public servants requires a few, mission-critical elements.
Technology deployed in government agencies isn’t new, but most of it wasn’t built for government agencies. The reality is stark: Government tech projects over $6 million only succeed 13% of the time and the average “large-scale” IT project takes nearly three years to deploy.
The Green Bay Police Department spent $1.2 million on a new computer-aided dispatch system that was plagued with foundational problems like locating the origin of a 911 call. The Los Angeles Unified School District (LAUSD) spent over a billion dollars on iPads, but teachers were “ill-trained on how to use the iPads and curriculum” and the program fell apart. Seattle Public Utilities and City Light’s new billing system was $43 million over budget and in its early days, “let thousands of customers see each other’s bills.”
There are myriad examples of government technology deployments mired in inefficacy and inadequacy. Technology supporting government operations must be built to be deployed and ready to use in days or weeks, not months or years.
Deployment speed is most directly impacted by how much manual work it takes to set up a government tech tool for public servants to use. Traditionally, tools are custom-built: A government agency would want to deploy software, an organization would build that software based on the government agency’s requirements — coding it from scratch — and then spend an inordinate amount of time setting it up within the agency’s environment.
More recently, govtech has moved towards configurability. A configurable tool doesn’t need to be built from scratch, but it does need to be, as the name would suggest, configured for the specific mission-set or use case for which it’s being used. Configurable technology can undoubtedly be deployed more quickly because it’s off-the-shelf, albeit in name only. The time spent configuring the tool is still time wasted.
Agile software development is a well-known methodology for building technology. It boils down to, simply, building a set of features that solve users’ problems and iterating on the technology based on user feedback to consistently refine the tool to meet users’ needs.
Govtech needs agile software deployment. When a private company invests in Google Suite, there isn’t a ton of legwork to set it up. It’s on and ready to use — Google isn’t sending an army of engineers to set up Google Drive before users can create a spreadsheet. Govtech needs to be built the same way, able to be deployed off-the-shelf in earnest so government agencies can nearly-immediately derive value from technology investments.
No government department delivers services alone. Government work is inherently collaborative — police departments work with fire departments, homelessness coordinators work with public health departments, local election officials work with their state and federal counterparts.
However, most govtech is built vertically: It’s designed to go deep on one use case or within one department without the requisite provisioning and security to enable collaboration with critical partners.
At scale, it’s a prohibitively expensive proposition for most governments — every government agency buys their own verticalized tech stack with discrete tools and then procures completely new systems designed to help these tools “talk” to each other so departments can digitally collaborate. The expense is twofold: The net costs of the tech tools themselves and the massive burden on IT, spending countless hours stitching together tools that aren’t really designed to work harmoniously together.
Horizontal government tools, on the other hand, are purpose-built to be deployed across not only government departments but also partner organizations. They improve how cross-functional groups of public servants work together to solve a problem, which is non-negotiable for effective govtech deployments.
Another lesson for govtech from agile software development (leveraging user feedback to consistently refine the tool to meet users’ needs) can be applied to mission efficiency.
Frontline public servants — those working in homelessness shelters, responding to emergencies, administering elections — have critical information that can and should inform how government agencies deliver critical services to their constituents. However, most govtech tools aren’t built to close the gap between information gathered in the field and action by department leaders based on that information.
Today, it looks something like this: A telephone-game of information shared from meeting to meeting to meeting paired with documents buried in Sharepoint instances. Extracting the valuable information from frontline practitioners, in essence, requires an exorbitant amount of manual work. Not only is this inefficient, but it creates an inherent latency in the information leaders have — by the time they get information, it may be out of date or inaccurate and functionally unusable.
Horizontal government technology tools must be built to quickly extract information from the field, aggregated and synthesized into real-time insights department leaders can actually use to make effective decisions and improve overall government operations.
A core aspect of deploying effective horizontal government technology is security. Legacy systems — especially those deployed on prem — struggle to deploy secure and flexible architecture.
One critical element of security is federated permissioning — that’s what enables people from multiple organizations to collaborate in the same digital space but still have access restricted depending on who the user is and what they should be allowed to see.
Flexible architecture also enables organizations to seamlessly update permissions based on policies and procedures, so if a policy changes, so too can the software. And none of these changes should require a custom services engagement from the vendor or days of dedication from an IT department to implement.
The underlying trend — government agencies needing to do more with what they have to serve their communities — is unlikely to go away any time soon. As departments turn to technology to increase the efficacy of public servants and their ability to deliver mission-critical services to their constituents, it’s vital to invest in the right tools that will get the job done.
Sources:
2024 State Expenditure Report, Summary: Fall 2024 Fiscal Survey of States, Illinois responds to federal funding threats over DEI policies, Federal policy choices in 2025 could impact state and local finances, How Would Potential Federal Budget Cuts Impact State Budgets? | Tax Policy Center, Government tech projects fail by default. It doesn’t have to be this way. | The Belfer Center for Science and International Affairs, Overspend? Late? Failure? What the Data Say About IT Project Risk in the Public Sector, New dispatch system's bugs frustrate police, county officials optimistic for improvement, What Went Wrong with L.A. Unified's iPad Program?, Why Seattle’s utility billing system was late and $43M over budget
