Building Out Digital Services Requires Balance and Customer Trust, Officials Say


Listening to users goes a long way toward building trust.

The hardest challenge in implementing digital services in federal agencies will always be cultural, convincing users that changing their methods and routines will result in a positive change.

A panel of government officials responsible for bringing digital services to their agencies made that point repeatedly during the Advanced Technology Academic Research Center Digital Services Virtual Summit on Nov. 30.

Sean Wybenga, informatics specialist for the Food and Drug Administration, said convincing his users that making changes to how they do their work is always difficult, “especially when you’re dealing with a doctor or medical professional who’s been doing it for 30 years.”

Wybenga said the way to overcome such resistance, unsurprisingly, is to listen to users and identify what they perceive to be their pain points before making changes. Then, he added, incorporate those pain points and how the solution addresses them when it’s time to train users on the new app or system or platform. “Don’t underestimate change management,” he said.

Maj. Evan Adams of the Army’s 101st Airborne Division is familiar with that need. He won the challenge mounted by the Dragon Innovation Program to identify a problem and to present a technology-based conceptual solution. “I’ve never done any software development before that,” he said. “Little did I know that no one else in the Army knows how to do software.” But he knew the problem to be solved inside and out, which made it far easier to work with the vendor to create the real solution.

“We sat down with the customers using it, and we kept making it easier and addressing their concerns until they found it was easier,” Adams said. Their attitudes were along the lines of, “Unless I can pick it up right now and use it, it’s useless to me,” he explained.

“One of the more prominent challenges I see daily is balancing the architectural, visionary structure with the need to provide value” while implementing the solution, said Sergey Trosman, CTO of the digital transformation division at ICF, “identifying that effective ratio.”

A related problem is finding ways to either incorporate or end ad hoc in-house solutions that different organizations within an agency or department may have created to address a problem, since the people who shape the informal solution are attached to them and resist being told the solution creates more problems than it solves.

“One of the things I struggle with as a headquarters entity [is] how do we delegate responsibility to the various organizations of what they can develop and what they can’t, [and] what needs to be centralized,” said Philip Letowt, executive director of the Department of Homeland Security’s Information Sharing and Services Office. “You can talk about digital transformation, but there’s a lot of shadow IT out there, or rogue IT, or however you want to characterize it … [It’s hard] to say not only is your baby ugly but it needs to go get a job.”

The vendor community is not always helpful in getting real solutions in place, Wybenga said.

“A lot of these solutions say, ‘Hey, we can do these in a month or two.’ Sure, you may get it demonstrated,” but if the vendor doesn’t understand the processes the solutions are intended to address or the structure of the underlying data, they may not scale or fit in with what is happening elsewhere in the process, he said.

The panelists disagreed about the usefulness of robotic process automation, or RPA. “We use it a lot of times when it comes to keeping legacy systems up to date,” Wybenga said. “We put a low-code solution on top [and] the bot goes in and puts the information into the legacy system, until we can decommission it.”

“If you mention RPA, I’m going to have to spit or something,” Letowt responded. “I’m very down on RPA – if you can spend the money on RPA you should” take those funds and invest in new systems. “RPA is nothing more than screen scraping … You need to invest your money into things that [look ahead], not kind of schmear over or paste things together.”

The panelists did agree that low- and no-code solutions are useful, but not the entire answer.

“In FDA, that issue is not 100% resolved,” Wybenga said. “With regard to our legacy systems, it was all government-developed … What we do is so unique that the solution needs to be highly customizable. [A] lot of the low-code platforms provide the option. Systems need to talk and be visible to a lot of other systems. It’s a balancing act, [moving toward] commercial solutions.”

Letowt noted there are pitfalls to low- and no-code. “The biggest is that it looks too easy,” he said. “Things like ServiceNow and Salesforce are very enticing because they can gather the data … until you start to confuse the underlying data model.”

He noted the key for his team is to have a repeatable set of design patterns. “They may not match everything 100%, but it’s much more effective in terms of getting things done faster,” he said. “That’s where low-code has become much more [valuable] – we’re able to do things in weeks rather than months.”