Why is technology such a struggle for government agencies?

From epic hold times at the Oregon Employment Department to the rocky rollout of rental assistance, government agencies have struggled to keep up with the demand for public assistance. A big part of that is the outdated and clunky technology these agencies are using and Oregon is certainly not alone. Remember Healthcare.gov? So, why is software such a struggle for the public sector? We get some insights from Mark Lerner, senior manager for federal technology strategy and programs at Partnership for Public Service.

This transcript was created by a computer and edited by a volunteer.

Dave Miller: This is Think Out Loud on OPB. I’m Dave Miller. Over the last few years, there have been plenty of examples of software problems at the state level that have directly affected the lives of Oregonians. During the pandemic, IT issues have slowed down unemployment claims, SNAP benefits and rental assistance. Last year, an audit found that the state’s child welfare computer system could place children at risk. And then there was the Cover Oregon debacle, where the state spent hundreds of millions of dollars on a website where people were supposed to be able to sign up for health insurance, a website that didn’t work. But Oregon is not alone. In fact, the Standish Group, which studies software development problems, has found that government IT projects have the highest failure rate of any sector. So why is this and what can be done about it? Mark Lerner joins us to talk about this. He is a Senior Manager for Federal Technology Strategy and Programs at the Partnership for Public Service. That’s a nonpartisan nonprofit focused on a more effective public sector. Mark Lerner, welcome to Think Out Loud.

Mark Lerner: Thanks for having me.

Miller: I gave a couple Oregon-specific examples, but I was hoping you could give us some other ones, over the last decade. Starting with a federal one, can you remind us what happened with healthcare.gov?

Lerner: Absolutely. The healthcare.gov story is one that I frequently come back to. The general picture of what happened with it is [that] this very large administrative priority from the White House that had a very specific launch date and a website that everyone was supposed to go to, to sign up for health care, failed, as soon as it was launched. And the way that the public saw it, there were tons of people who were trying to get health insurance for the first time to sign up and comply with this new law. And very few people could even make it through the system on that first day, the first week. It was a pretty tremendous failure. The lead up to that, the sort of background, was quite a lot of the things that we’ve since now learned as a sort of government technology community are fairly common struggles with government tech programs: things like people not really testing the system beforehand or relying on outdated technology or hiding potential failures from senior management, various different failures that ultimately led to it just crashing and not working at the end of the day.

Miller: California has provided an example, the state level. What’s the story with their DMV software?

Lerner: Yeah, this is actually an interesting one because it’s one that has made it into text books at this point. Many California.. well everyone that goes through the DMV, no one really has a good experience with it, right. But in specific in this case, you’ve got several different databases, several different systems, that work within the DMV that are not connected that make the system much more difficult to use. And they have been trying to modernize it and to replace it and to update it for years and years. You can see a long history -- if you just Google “California DMV software” you’ll see a long history of tons of money being spent and being put to this problem and it hasn’t really been effective, again for many of the same reasons of the ways in which government tends to build these tools.

Miller: Another example that you have written about in the past was the text alert that went out to everybody in Hawaii on the morning of January 13, 2018. It said, in all caps, “BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL.”

Lerner: Yeah.

Miller: It wasn’t a drill but it was also completely a mistake.

Lerner: Absolutely.

Miller: There was no missile coming. And what I remember from that time -- only three years ago -- was that it was a human error. But you’ve put this in the category of an IT problem. Can you explain that?

Lerner: Yeah absolutely. So, a lot of people were quick to jump and say, “Oh that one person that clicked the button that sent out the text, they’re to blame.” But there’s a deeper problem here which is that the system was designed in a way such that, if you take a look at what it actually looks like, the visual representation of it, the user interface, it is so easy for someone to have accidentally clicked that wrong button, to have actually selected the wrong message to send out. And this was just a person who was performing a routine test that selected the wrong option. There’s some really good investigative work done by a few folks -- Hana Schank is one that has done a lot of this work -- looking into this very specific problem where these systems don’t get designed with their end users in mind. People might just put a bunch of options into a drop-down and not realize there’s a human on the other side clicking these things and if two of them are really close to each other and one of them accidentally sends out a missile alert to the entire state, maybe there should be some more protections against that.

Miller: How can a problem like that happen? It seems preposterous that somebody would create a system without thinking about the people who are using that system. How could, not focusing solely on Hawaii, but how have we gotten to a place where that kind of an engineering project could even happen?

Lerner: To be frank, it happens a lot more often than you would think. In a lot of cases, you will see government tech projects, and frankly private sector tech projects in some cases as well, define all of their requirements up front. And by requirements I mean, what is this software, what is this website going to do? And that might be someone who is a business analyst; that might be someone who is the owner of that program, that writes down all the things that it needs to do. They’ll hand it off to a vendor who is going to build the software and just wait until they receive the product back. It’s very rare, unfortunately in government -- it’s getting more popular but it’s still rare -- for people to actually work directly with their end users, with the actual humans at the end of this system, at the end of this process..

Miller: Say the people at the DMV or at the Office of Emergency Management or whatever it might be.

Lerner: That’s exactly right. Yeah. We need to be doing a lot more of, while we’re actually building these tools, check in with [the end users], talk to them, show it to them, see, “Hey, does this actually match what your workflow is? Does this make it easier to do your job? Is there anything confusing about this?” Unfortunately, we sort of do a lot of that up front as opposed to just continuously checking over time.

Miller: It seems like this falls into the early stages of a project, acquisition and procurement. What are the broad issues there at the start of a big project?

Lerner: Yeah, absolutely. Acquisition and procurement: Two words that are sure to strike fear into the hearts of a dinner party. I think that..

Miller: [Chuckles] Meaning that they sound boring but they’re actually important here?

Lerner: Absolutely, yes, yes. They are so critically important. Because what you’re basically doing is you’re signing a contract. You’re coming into an agreement between government and a private sector company, saying this is the service that we’re looking to build. This is the website that we want. This is the app that we want. And if you structure that contract in an incorrect way or an outdated way, you will end up defining everything up front. And you basically say to everybody involved, “Listen, we might learn a bunch of stuff over the next five years of building this, but we’re not gonna take any of that into account. We’re just gonna agree up front to everything we’re going to build and that’s it.” You might even lock yourself into using the same vendor for five years where after six months you figure out these aren’t the right people for the job. Finding new ways and better ways to procure these services, to sign these contracts out, to work with private sector vendors in the software space is super important. Especially because the government just currently doesn’t have in-house technical talent that it needs to do this alone.

Miller: What are the differences between an IT project, say some new software for the DMV.. the differences between that and, say, a highway expansion? Two things now that state governments may be embarking on that involve procurement, that involve a request for proposals and an idea of: this is a problem -- this is a solution. What’s the difference between those two kinds of projects?

Lerner: So, when you’re looking at an infrastructural project, a physical one like building on a road, you can rely a lot more on knowing things up front. You know where you want it to go. You know what kind of materials you want to use. You have a lot of experience of how long it might take, even though the schedules can still be pushed out. And you know what you want it to do. You have a problem and you know that this is the solution. When it comes to building software, oftentimes we are building out the solution instead of making sure that it actually meets the problem, if that makes sense. So, [for example] we know the problem is, we want to get more people their veteran benefits, right? But people might jump to an assumption saying, “Oh, what we need is a mobile app.” when actually maybe you just need a mobile friendly website. Or maybe the paper forms that we send out are really confusing. There could be a lot of other solutions out there. When it comes to technology, things move so quickly and things are so fluid that we’re able to do much more rapid testing, much more checking with the actual people at the end to see what works for them and what’s actually gonna help us get to that end goal.

Miller: I mentioned that report that every couple of years this Standish Group has put out, a kind of grading of how big tech projects have gone. And it’s a very ugly picture broadly all across different sectors. I did note, and I mentioned it, that government projects fare the worst. But none of these sectors, whether it’s the for profit world or the government sector, none of them fare that well. I’m curious how big the differences are between how a state government or the federal government would pursue a big new tech project compared to, take your pick, some random Fortune 500 company.

Lerner: Sure. In a lot of cases, I think that you might see a lot of similarities. At the end of the day, some of these are really big bureaucracies; they have very set-in-stone ways of working. I will say that Fortune 500 companies don’t have to get new policies and laws passed through Congress. But, by and large, they still do have a lot of similar bureaucratic issues..

Miller: And they may be dealing with regulations that are based on laws passed by Congress.

Lerner: Yes. That’s very true. That’s very true. But in terms of building out their own tools and software, they do have a little bit more flexibility. But an element of it is also culture. An element of it is priority. A lot of these places, government included and especially government I should say, have not really prioritized building out their internal in-house technical knowledge and capacity. A lot of these larger companies do the same thing where they outsource a lot of technical knowledge and technical talent. To many of these places, technology is a silo in and of itself that you manage as opposed to something that is supposed to be integrated in everything that you do.

Miller: We’ve heard over the years that one of the problems is that the best tech talent is going to the private sector because they can make more money there. How big an issue is that? If you can hire that talent at some company to actually build the software, do they need to be government workers?

Lerner: That’s a good question. I think of it as this sort of pendulum. If you look back in history, the government was the place to be a technologist. We invented the internet in our government, we invented GPS in our government. Lots of great technical innovations have happened there. And then slowly with the Silicon Valley Californization of it all, things started swinging the other direction. So much so, to the point where government, in many places, does not have enough technical capacity to be able to tell good from bad. And so when you have vendors coming in, when you have these private sector companies coming in and trying to get government business, there’s often times where government folks, through no fault of their own, they are people who are well trained in the policies and regulations of, say, immigration law or customs or emergency management or what have you and they’re saddled with the responsibility of also making technical decisions. That’s a really hard place to put them. We need at least enough people to be able to tell good from bad in government, if not more, so we can actually take on this responsibility ourselves.

Miller: We’ve been focusing a lot in this conversation on new IT projects that have been failures in states or at the federal level. But there’s another problem which is seems almost like the opposite, which is that a lot of agencies are stuck right now with clunky old software that can only run on certain machines or is written in essentially obsolete computer language that few people can can get into and to fix, just archaic technology that they seem to have a hard time letting go of. What’s the solution for that?

Lerner: Yeah, this is another really good question. A colleague of mine, Marianne Bellotti, has a book very much on this topic called “Kill It with Fire.” The notion of the entire thing is that a lot of times people approach this problem with this idea that we should, oh my gosh it’s an old COBOL system; we should kill it with fire. And in reality, a lot of the times, these systems do have stability and they have stayed up for decades for a reason. That’s not to say that we shouldn’t replace them, of course. We have examples of, for instance, entire government services that are run off of a computer mainframe that is hosted in a flood zone. So, if that place floods, the entire system goes down; that’s something we should definitely fix. But, in terms of the fact that there are tons of these legacy systems that are out there, I see that more as a symptom than a problem itself. And the symptom being, we have under invested again in this technical talent, in our own internal capacity, such that we don’t actually have the people that know how to maintain this stuff or upgrade it or slowly start to replace it with something that’s more maintainable and more modern.

Miller: Mark Lerner, thanks very much for joining us today. I appreciate it.

Lerner: Thanks for having me.

Miller: Mark Lerner is a Senior Manager for Federal Technology Strategy and Programs at the Partnership for Public Service. That’s a nonpartisan nonprofit. Their mission is to help the government work more effectively.

Contact “Think Out Loud®”

If you’d like to comment on any of the topics in this show or suggest a topic of your own, please get in touch with us on Facebook or Twitter, send an email to thinkoutloud@opb.org, or you can leave a voicemail for us at 503-293-1983. The call-in phone number during the noon hour is 888-665-5865.