It’s 2023. Apps and software dominate Americans’ private lives. From Amazon to Uber, from DoorDash to Gmail, Netflix and Dropbox, U.S. consumers have become accustomed to fast, reliable software that typically works the way it’s promised and provides an exceptional user experience. In fact, we’re so accustomed to having a positive experience with the apps we use every day that we rarely think about the tool itself, including its interface and functionality, things like how many clicks it takes to perform an action, the placement of dropdown menus, the design of in-app messaging, or how it integrates with other technologies in a workflow. In essence, how easy the app is to use. Unless something is broken, we typically don’t dwell on these things, we just get on with what we set out to do: hail a car, order take-out, check our email, or watch a movie.

Yet, in government, both at the federal and the state/local level, this often isn’t the case. Clunky user interfaces, barren features and prompts and manual workarounds in place of easy integrations have become the norm. When it comes to the software government workers rely on every day to get their jobs done, the list of issues requiring efficiency-sapping extra steps and workarounds can range from the mundane and annoying to major roadblocks. All of which waste taxpayer dollars and hamper agencies’ ability to deliver on their missions.

Why is this the case and what can be done about it?

I believe there are three primary reasons for government software underperformance. By understanding what they are and why they occur, you can ensure your agency makes the best purchasing decision possible.

          1. Lowest price, technically acceptable

Lowest price, technically acceptable (LPTA) is a purchasing philosophy that’s been around for a long time. It means a bid must meet the minimum technical requirements at the lowest price. Yet, by definition, this means from the very start you’re already compromising on the final product by accepting a subpar experience. Typically, the rationale behind LPTA isn’t just to save budget, but that LPTA is seen as the “safest” approach with the lowest risk of protest, even if it doesn’t produce the best outcomes and often produces downright terrible ones.

Many times, there’s also a disconnect between agency leadership and the professionals who regularly use the software regarding what constitutes “technically acceptable.” “Technically acceptable” generally includes functional or regulatory compliance requirements set by the agency. But it would be more effective to focus on user experience requirements such as ease of integration with existing systems and efficiencies gained through automation. These are the things that most directly impact the government workers using the software who lose time and efficiency with a subpar user experience. While a lowest price bid could very well meet all functional and regulatory requirements and seemingly save some budget, it may not align to end users’ day-to-day processes and tasks, ultimately costing an agency much more in lost productivity than they save.

          2. Lack of innovation

Often agency leaders view the lowest risk option as not making a change in the first place. That’s partly because implementing new government technology is rarely painless. It starts with a complex purchase process and then requires installing new systems, testing them, teaching workers how to use them, then troubleshooting any issues. It’s one reason why legacy software somehow limps on, even when it clearly isn’t meeting the needs of its users. These dynamics completely disincentivize companies to innovate, since they know their customers aren’t necessarily clamoring for something new and better. Large software vendors have become accustomed to the fact that there’s rarely any meaningful repercussions for offering a subpar user experience with poor support, since the likelihood of their customers switching remains relatively low.

Keeping this type of legacy software in place well past its prime also makes it harder to attract top talent, especially younger employees who may evaluate a job based in part by the type of support and tools they receive.

According to a recent survey by Dell Technologies, 80% of Gen Z employees say that technology would influence their job choice. Maintaining legacy software for too long can make younger workers feel like they’re using outdated tools, which can also hamper their productivity and motivation. With Generation Z the fastest-growing group in the workforce, this critical issue will only grow in importance in the years ahead.

          3. Private-sector solutions don’t match public sector needs

The federal government has a massive budget, spending trillions of dollars each year. This obviously makes it a very attractive customer for technology companies. Yet, many of them bring in software and tools originally built for the private sector, then try to adapt them for public sector needs through extensive — and expensive — customizations. The result often underappreciates how the government works in terms of processes, workflows and reporting requirements, while requiring an army of consultants to maintain. Unfortunately, this process repeats every time an upgrade or change to an existing workflow is required. That may be great for software companies and systems integrators who get paid for their services and time, but terrible for users who are left waiting through delays for sub-optimal solutions.

Asking the right questions

So, knowing the possible pitfalls of government software, how can you ensure your agency gets the solution it actually needs? Start by asking some basic but important questions.

• Is the application designed for government?

Software originally designed for government needs is more likely to include the specific out of the box processes, workflows and reports you need to get up and running fast, with minimal additional customizations or tweaks. In addition, companies that build for the public sector often use a government-centric innovation process, meaning they are designed around government end users’ voice and requirements from the very beginning. At the end of the day, you want a software experience that’s been designed for your needs and accounts for critical security standards such as FedRAMP.

• What type of support are you entitled to receive and is there a direct line of communication after implementation?

Be sure to understand the type of support included with your purchase. Traditional commercial tech support is usually insufficient for government users who frequently want the ability to make business oriented “how to” inquiries or have questions about specific government processes. In addition, it’s important to make sure you’re comfortable with the process for support, including your specific point of contact and the preferred ways to communicate and resolve any issues before any purchase. If your agency or the software provider required a third-party consultant to install and configure new software, will the vendor be able to support your team’s ongoing support and service needs?

• Who is going to be using this software?

Too often, purchasing decisions are made by senior leadership who don’t use the software being replaced on a daily basis. It’s important to include end-users and make them a critical part of the decision-making process. Do they feel it will meet their needs? Do they see themselves using it? Does the user experience allow for greater daily efficiency? Does it empower them to deliver on their tasks more seamlessly?

• Are other government agencies with similar regulatory compliance needs using the software?

Ask around. Have colleagues at other agencies heard of the software? Have they had positive experiences? Do they think the vendor understands their specific compliance and regulation issues? How easy has it been to adopt the software? Is it intuitive by design and less clunky for their specific government use case? Does it require going outside the system to spreadsheets and other documents for workarounds, introducing inefficiencies and increasing the potential for errors?

By understanding the common reasons government software has lagged behind the commercial space and asking the right questions before making a purchasing decision, you can feel more confident you’re making the right acquisition choice. Given the stakes involved, including securing national security, protecting democracy, and working to improve the lives of American citizens, why should our government settle for technology user experiences that are outdated by decades or more?

It’s time to demand more of the technology government uses every day.

Software that’s designed with the specific needs of government in mind, that empowers end-users, and makes it easy to implement and use, means that agencies can more efficiently meet their needs and, in turn, spend more time focusing on their mission, not their technology.

Howard Langsam is CEO of OPEXUS.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.