Implementing HB 1575: National Best Practices on Reducing IT Project Risk | Oklahoma House Interim Study | Oct. 8, 2025

In spring 2025, lawmakers approved a feasibility study (House Bill 1575) about creating a unified eligibility and application process for public assistance administered by state agencies. The Oklahoma House Committee on Children, Youth and Family Services held an Oct. 8, 2025, interim study to discuss best practices in this effort, as well as hear from Oklahomans about how the current system is ineffective and needlessly cumbersome.

OK Policy’s Research Director Anthony Flores presented on best practices for lawmakers and state agencies when it comes to initiating and managing large information technology projects like this. The following is a transcript of his comments. The full video of the interim study – IS-25-054, HB 1575 Implementation (Rep. Pae and Gise) – can be viewed at the Oklahoma House website.

# # #

Good afternoon. My name is Anthony Flores, Research Director for the Oklahoma Policy Institute. I am filling in for Waldo Jaquith of US Digital Response. Waldo Jaquith is one of the foremost experts on government software procurement in the country. Which unfortunately means he’s popular, so he’s double-booked presenting to the American Bar Association as I’m speaking.

Before we begin, I want to take a moment to thank our speakers, our legislators, the agency staff, and everyone in this room. I especially want to thank this committee and Representative Pae and Representative Gise for requesting this important study. When a bill passes, it’s easy to move on to the next shiny object, so I’m grateful for their attention to the implementation of this project. I’ve always respected their attention to detail and willingness to do hard work.

I also want to thank Representative Lawson and Senator Seifried for their work in getting this bill passed. And I want to thank the agency for the time and information they shared today. They have consistently proven themselves to be excellent public servants.

As I walk through national best practices for large IT projects, I don’t want folks to assume we aren’t doing any of those best practices. In fact, national experts I’ve invited to meet with our agencies have repeatedly said that many of the practices they usually have to spend time convincing agencies to adopt are already being done here, or met with an openness to learn and improve. That’s rare. That’s something Oklahoma can be proud of.

Now most of what I know about software procurement I learned from Waldo and his peers. That’s also true for countless state and federal agencies. Almost everything in my presentation is taken directly from his reports and presentations, so anything intelligent I say is him not me.

A bit about Waldo’s background, he has worked as a career software developer, served in the General Services Administration at 18F, where he worked directly with federal, state, and local governments as a technology fixer. He’s presented to the many other state legislatures, the National Association of State Chief Information Officers, the National Association of State Procurement Officials, National Association of Medicaid Directors, the Council of State Governments and the National Conference of State Legislatures, you get the point.

A bit about myself: I lead OK Policy’s Research and Data team. We focus on improving the data and IT infrastructure for Oklahoma. We primarily focus on criminal justice data where we’ve dealt with many of the issues we talked about today: Data that is siloed or messy; antiquated data systems; complex data sharing agreements; making sure that there is compliance with state and federal law; compliance with local and federal data privacy protections.

Through the work of my team and our predecessors before us, I think that we’ve done more to advance the accessibility and usability of that data for city, county, and state governments and service providers in a way that will be a model for other states to follow.

So, why am I speaking to this committee about this today? Because with technology it’s easy to find yourself buried in buzzwords or lingo that means nothing, and you feel disempowered to make decisions about how to budget software projects.

Usually Waldo and his team take one day to teach people the basic concepts you need to understand in order to budget and procure software effectively. Our goal is gonna be to do 10 minutes. This presentation will give you the tools to ask the right questions and be able to reduce the risk of big IT/software projects.

But first I want to talk about why you should care with a real example of what can go wrong.

In 2013, Rhode Island contracted Deloitte for their integrated benefit application and followed none of these best practices. The consequences of failure are real:

The price tag went from $100 million to $364 million. At launch, thousands of people lost their health benefits and several people likely died as a result. Many benefits were overpaid/underpaid. It caused tens of millions in federal fines.

Because the state outsourced all technical know-how, they had no choice but to stay with Deloitte with another $99 million contract. Things have not gotten better.

Ten months ago, Deloitte’s system was hacked and half the state’s residents’ data was held ransom. Deloitte tried to blame the state; that didn’t hold up, and the company is now paying millions as a result. And now in 2025, Rhode Island is planning to modernize what in 2016 was the “new modern system” and move away from Deloitte.

I’m not trying to single out Rhode Island and Deloitte. Every state has a dozen stories like this from the usual vendors who get most of the contracts. Everyone followed the rules and norms for software procurement in government. This is all normal. This is how normal it is.

One report by the Standish Group found that of all government software development contracts over $6 million, only 11% are successful – defined as being within 20% of cost, schedule, and performance.

Another study by the Department of Defense – which procures quite a lot of software – found that 40% of systems developed, representing over $35 billion of DoD spending, failed to meet real needs, even when they met contractual requirements. That means even when you get a report saying that on paper everything the vendor promised was delivered, you’re still not guaranteed to get something people actually need.

And a third study, looking at over 5,300 IT projects, found that the average government IT project costs around 310% of the originally estimated price. Again, this is all normal, but it doesn’t have to be.

So, we’re going to do something fun today. We’re going to try to make you all software project budgeting and procurement experts in just 10 minutes. We’re not gonna try anything new. In the private sector, our friends here at Google can attest, this is boring and normal. Dozens of state and federal agencies are adopting these practices recommended by Waldo and his peers to great effect. Not only is this proving to be a crucial difference between the projects that fail and those that succeed, but their staffs love it and want to do more of it.

So here are the five signs that a software project is set up to succeed, and we’re going to go through them one by one:

• Human-centered Design (HCD)
• Agile Software Development
• Product Ownership
• Building out of loosely coupled parts
• Modular Contracting

1. Human-centered design.

So, first what is design? “Design is deciding how a thing should be” – William Van Hecke, Facebook Employee.

It’s not what color something should be or a special flourish. It’s deciding every detail of what you’re building. To our friends from Google attending, you may want to cover your ears for this next part. An iPhone is an example of great design. Listen, I hear the Google Pixel is great as well. I just happen to own an iPhone… because it’s better. A two-year-old can start using intuitively without even being able to read. It took teams of user researchers who tested it with real users and saw all the weird ways people use things and thought of how to guide them back on the right path. Great software companies have teams of user researchers who do that. Agencies or the vendor should have them as well.

Now human-centered design is real easy. Human-centered design says all the work that’s done needs to be centered on satisfying the needs of end users of the software that tested it every step of the way. Everyone here knows what human-centered design is. It’s using something for the first time, and it’s so easy it feels like magic. Bad human-centered design is when it feels like you need to fight the machine to get it to do what you need. So how do you do it in practice?

1. Work is only performed if those actual end users approved it. Or in the service of their identified needs.
2. The work isn’t finished until the users say that it is.
3. You do what the actual relevant humans need, and not what the organizations think that they need.

That’s it.

If you don’t design with real people, you’re designing for imaginary people.

For an integrated benefit application, the primary users are:

• State employees like case managers who need to quickly be able to process applications. It means higher job satisfaction, retention, easier onboarding, and better outcomes for people.
• Local benefit navigators helping people apply for benefits and busy working Oklahomans applying for these programs. The easier it is for them, the more people they can help.
• And of course, just anyone in the public that wants to apply for these benefits.

So, what does user research look like? It looks like this slide. It’s watching real users – not a QA (quality assurance) tester – narrate out loud as they use the system, seeing what buttons make them confused, what makes them curse out loud, what makes them give up. Then deciding that pain is what you’re going to fix. Fixing it, then verifying with them that it fixed their problem. You don’t just say “mission accomplished.” The work isn’t finished until they say that it is.

User research helps human-centered-design by ensuring that the vendor is working on the actual needs of users, and that system will do what you need it to do. A vendor should have user researchers on staff working side-by-side with programmers.

Again, this isn’t hypothetical. Civilla and some human-centered design experts worked with Michigan DHS to improve the paper application. At the time, Michigan had the longest paper application in the country at 40 pages. Through human-centered design principles of interviewing users of the application, case managers, agency heads, etc., they cut down that application to 8 pages, and processing time went down 50%. This human-centered design should be used for all government services, not just digital services.

2. Agile software development

Agile is a common buzzword. Also real simple. It is used by 89% of professional software developers in the private sector. It’s growing in popularity in government, including in Oklahoma, just not everywhere. So what is agile? Let’s contrast it with what it’s not.

Agile is not waterfall software development, which is how many government projects are done. This is where some consultants come up with a bunch of requirements (usually from legislation), which go into an RFP (request for proposal) and then a contract is awarded. Those requirements go to some designers, who design screens, programmers write code to implement those designs. Then someone tries to verify that each requirement in the contract is satisfied by some requirement traceability matrix to show the work has been met. And then it goes into some maintenance phase.

As we saw in that DOD study, these projects go over budget and fail to meet the needs of the people using the software because they verified if it worked for the contract, not the people who use it. And because every contract requirement was met, the only way to fix that is giving the vendor an infusion of more money. This is contract-centered design, not human-centered design.

So, agile says instead of planning a multi-year project in great detail with every step over the whole time. You instead know the objective of the project: we’re going to create an integrated benefit system; we’re gonna reduce the SNAP error rate; we’re gonna implement work requirements. Then the vendor builds something small to build toward that objective, in two weeks. Not three years, two weeks. No excuses. Full tested, fully documented, ready to be used, even if it doesn’t look pretty. And after the two weeks, government and users can inspect the work of the vendor team. They can test it with the intended users to verify that they like it, and it’s making their life better. And from what they learn from that they go back and make a plan for what to do for the next two weeks. Then they just repeat.

In this way value is delivered constantly, until the software gets good enough to be used broadly by actual end users. And then you keep delivering value every two weeks until you run out of money or all the work is done, whichever comes first.

In this approach, government owns all software, and the vendors own nothing. You wouldn’t buy a car where you can’t look at the engine. Why would you buy software that you can’t maintain or modify? And if three months into the contract, the vendor turns out to be bad, everyone knows it quickly. You fire them and hire a new one to pick up where they left off rather than starting over. And we can be confident someone else can pick up where they left off because we made them deliver tested, documented code every two weeks. In a bit we’ll talk about how you can hire new vendors rapidly.

It also gives you, as lawmakers and agencies, tight contract oversight of vendor activities so you know you’re getting your money’s worth. It’s how the whole software industry works. At any point legislative staff can join a demonstration to see how things are going. Again, to software developers in the private sector, this is all completely normal.

How to use agile to develop an integrated benefit system? You require vendors to allow demonstration of the software at least every two weeks or more often if you wanted to. HB1575 is a feasibility study but that study doesn’t just have to be a report or list of requirements. It can be a working prototype of that WIC integration or that Medicaid integration – using fake data to protect privacy concerns – so you can prove that data can flow how we need it to. So then we can worry about the question about the data sharing agreements to get the actual data flowing, but that part isn’t hypothetical. We know that it can happen. Vendors love that reduced uncertainty, and it will lower the price tag of the project. That’s just economics. New features should be tested with real users of the software to verify it meets their needs. Agency staff should be able to review the source code itself after each sprint.

3. Product Ownership

Don’t worry, the rest of these get faster to go through. Central to agile is that someone has to be in charge of what the development team does every two weeks. This person is the product owner. The product owner’s first job is to make sure people are building the right thing that meets the real needs of real people, not just that they’re building it the right way.

This is not an “other duties as assigned” for big projects. This should be close to a full-time position. The product owner should be an agency employee from the agency procuring this work. That employee should be empowered to represent the government and the needs of end users when talking to the vendor. God help you if you outsource this to the vendor because now they have complete control over you.

For the full project, maybe not the feasibility study, this means if the OKDHS (Oklahoma Department of Human Services) procures the software, the product owner should be at OKDHS. It should be someone with deep knowledge of their benefits and user needs and preferably of the benefits and user needs of the agency whose benefits are being integrated.

We mentioned that government and users should be able to see a demonstration every two weeks. The product owner should be able to inspect every day

4. Building with loosely coupled parts

Large software projects are doomed to fail. They collapse under their own weight of administration so they must be broken down into a series of smaller mostly independent projects. Your new system will eventually be your old system. Each one of these components communicates with each other through simple modular standards, so anyone can be swapped out at any time. In this way you don’t build a monolith that everyone will hate in five years. You build a little ecosystem in which each piece can be upgraded and modified easily as changing needs will always demand.

This is how shipping containers work. The shipping company is able to load and swap out shipping containers without having to care about the messy details of what the cargo is like inside.

APIs (Application Program Interfaces) – another important bit of jargon – are like these shipping containers but for data. They help move data from one system to another without having to worry about the messy details of how each data system works.

Multiple teams or multiple vendors can work simultaneously on a system with minimal coordination. There’s no technical need to award a single contract for a large project.

Digital service delivery is not going to go away. In government, it’s going to continue growing, so you should budget for it accordingly as an ongoing operational expense and not a one-time capital expense. These are ongoing, never-ending tools that are constantly improving based on changing user needs, feedback, and laws.

For an integrated benefit system, this means every benefit integrated should be a separate project. You don’t have to do everything at once. APIs let you do things like. For an integrated benefit system, we don’t necessarily have to move all of OHCA’s (Oklahoma Health Care Authority’s) or OSDH’s (Oklahoma State Department of Health’s) systems to OKDHS. You can have an API connected to the application that securely ships that applicant’s relevant info to their system. Their system uses that data as if it came from apply.okhca.gov, and decides if they’re eligible – OKDHS doesn’t have to care how – and the applicant’s eligibility is shipped back via the API to OKDHS. Or, you can have it ship to an API at OMES (Oklahoma Office of Management and Enterprise Services) in the middle; it doesn’t matter.

5. Modular contracting

By employing all these techniques, you can now break your large huge risky contract into a handful of safe smaller contracts. The more you spend, the greater your odds of failure. So, don’t. Break up the contract – no longer than three calendar years, including options.

Projects over three years are statistically guaranteed to fail; so just don’t.

You want the contract to be small enough that you’ll have no worries about firing a bad vendor, knowing the rest of the vendors can keep working independently and keep making progress. Small contracts with agile development means shorter, simpler RFPs.

Waldo and his team at the General Service Administration – often with a single one-day meeting of stakeholders, similar to us here today – could get all the information to write an RFP, review it, publish it, send it to qualified vendors, review response, and award a contract within 60 days. For our agency folk here, if that sounds like it would save you so much time and headache, yes, he is grant funded to still do that-reach out to me after this.

6. Budgeting made simple

One team of five to nine software developers, user researchers and project managers here in Oklahoma, costs about $1 million per year. If you pay for developers in an expensive city, you’re gonna double or triple the cost just paying their rent. When possible, local is better. Also because they understand the needs of users, they probably have been users before. Of course, sometimes that’s not possible.

So here’s how you can budget or estimate cost yourself: How many teams do we need and for how long? Say a team is $1 million per year, so one team for two years is $2 million. For 6 months? $500,000.

So the final thing I am going to end on: let’s just say you wanted to ignore all this and your goal was to fail at one of these software projects. Here’s how you would fail:

• Don’t conduct user research
• Define lots of requirements up front
• Sign a $10+ million contract with a single vendor
• Conduct oversight via reports, not live software demos
• Punish projects that fail fast

So what are some executive actions you can take to incorporate all of this information? This would include:

• Require demos, not memos
• Limit contracts to $10-15 million and three years
• Require user research for $1+ million projects
• Require a named, empowered product owner for all projects
• Require twice-monthly demos to legislative staff
• Create a state digital service
• Allocate funding operationally

I will be including a handout called De-risking Government Technology, a guide that Waldo and his team developed. It goes into a lot more detail on the things I’ve talked about today.

If you need help, you can contact Waldo Jaquith directly. He is grant-funded to help evaluate vendors at no cost. I’ve also talked with Cindy Phan, who used to be with the Department of Labor and is now the User Research Lead at US Digital Response. She is willing to offer her assistance on one or more user research sprints as is desired for this project.

I am really grateful for this conversation today because it has been really needed for a long time.