Creating space for innovation

"Innovation" is an overused buzzword that obscures the messy reality of making change happen. True innovation requires the right people, the proper mix of technologies and a critical grasp of customers' needs and expectations. For agencies, the many layers of federal governance and regulation add another degree of difficulty.

FCW recently gathered a group of IT leaders from across government to talk about the obstacles they're encountering and how they've addressed them. The discussion was on the record but not for individual attribution (see below for a full list of participants), and the quotes have been edited for length and clarity. Here's what the group had to say.

Procurement is no longer the obstacle -- security is

The Federal Acquisition Regulation's restrictions, both real and perceived, have long been a friction point for digital reinvention efforts, but most participants said the contracting process is not holding them back.

"It used to be the in-vogue complaint was, 'Oh, it's all procurement's fault,'" one executive said. "But actually, procurement has gotten much better. What our agency is grappling with is the IT monstrosity that came out of" the Federal Information Security Management Act.

"FISMA came out because we were doing these things wrong in government," he acknowledged. "But now we've created this very burdensome process that is not well-aligned to where cloud architecture is going," and agencies must find new ways to navigate that process. "Obviously, we can't bend security principles, [but without a new architecture,] you're waiting two years to deploy. That's not innovation. That's not acceptable in this day and age."

Another participant echoed that concern and pointed to a kickoff call he'd had earlier that day with a new procurement team. "It was a beautiful model," that executive said. "The acquisition and innovation advocate for the component was on the line. We had the attorney, the contracting officer, the program officer, even a user. And somebody from the CIO shop. So we were all talking about what the goals and objectives were, and one of the very first questions was, 'Who is involved in the [authority to operate]? What does that process look like?' Because inevitably what we're seeing is that's what's needed to be able to deploy technology."

A third participant, who brought a range of cybersecurity experience to the table, agreed that this was a common problem and noted that too many teams still approach security as a final layer rather than an integral part of their projects.

The problem is not FISMA or the Risk Management Framework, he said. "It's how the framework is implemented. [It] was always designed to be a life cycle-based process, [but] one of the things that it turned into was a paperwork exercise that may or may not have anything to do with good security."

"It all starts with a good set of security and privacy requirements," another participant said. "You can forget about FISMA" if those requirements are clear from the beginning.

Centralization: Impediment to innovation?

For some of the participants, a more insidious obstacle is the push to centralize and standardize IT.

"I think agencies that will struggle with modernization are those with centralized IT shops," one said. "Agencies that are oriented around the function of execution and delivering at the mission space, where the technology folks are sitting there with the mission folks and are executing to deliver that outcome -- I think they'll have an easier time."

"Certainly, we met with the CIO, and we met with the systems expert and chief technology officer and asked for their feedback," said another participant who had launched a mission-owned initiative. "But it wasn't a centralized Garden of Eden that's going to deliver an outcome. It's a decentralized capability where you control the systems. You have the funding. You have a couple of folks who work for you who have really deep knowledge in cybersecurity. You're able to build and innovate very quickly. And I think that's the difference."

"That's exactly the right model," a third participant said. "And by the way, that puts the risk management closer to the front lines, where it should be. Managing risk from the CIO shop sometimes is problematic."

Two other executives said that model resonated strongly with them because, as one put it, "we're moving in the wrong direction, toward a completely centralized model. I don't want to say it's the entirely wrong direction, but I think it's a direction that limits flexibility."

The group was sympathetic to the pressures on agency CIOs to instill some sort of structure and process, even as they pushed back against "a cookie-cutter approach."

"I think that the changes in the CIO function around process have been because they didn't have visibility into spending," one participant said. "So that drives the culture. But you're irrelevant if you're not a part of whatever the mission owners want to do. If you're just saying no, they stop working through you."

Who's going to support your great idea?

Not everyone wants to run their own innovation shop, however -- and not many mission owners are prepared to scale and support new systems over the long term.

One of the executives championing decentralized efforts acknowledged that when a new system breaks, the innovators often go running to the CIO shop to fix it. "And so it starts fights [over] innovation versus structure."

Another participant cited the inspector general community as an example. "They don't want to be in the IT business; they want to be in the enforcement business. They don't want to be worrying about clouds and infrastructure. So when the government has successes, why can't other agencies essentially find ways to leverage that?"

And another spoke of her search for a permanent home for a system that grew out of mission needs. After bootstrapping a machine-learning solution, she said, "we go to our leadership and say, 'Look what we built!' And leadership says, 'Wow, that's rich, but that's not what we do. We've got to find someone else who can take this amazing thing you guys built because we can't sustain it. We can't afford it.'"

That executive said her team is still looking. "Everybody said it's great, but no one's writing a check. And our particular division is not supposed to maintain and stand up products and put them in production."

Coming to terms with COTS

Several participants argued that commercial off-the-shelf solutions are the only practical way to innovate without running up unsustainable technical debt.

"We just can't do custom development on a large scale," one said. "The challenge is then the policy changes and mindset shift. It used to be: 'We're all going to have a perfect requirements process and a perfect building process and work to a 100 percent solution.'" Few mission owners are willing to adapt their approaches to the "70 percent solution" that a COTS product can offer, and they instead hold out for a custom solution.

But requirements evolve quickly, he noted, so "in five years, that custom system is not 100 percent. It's 10 percent. So you've got to break that mentality, which is hand-to-hand combat."

"We want to bend the organization to what's available in the commercial space rather than the commercial space bending to the regulations, requirements and compliance of government," another executive said. "What happens when you build it? You can't find additional funding, or the company that built it no longer supports it. Whereas if you have a commercial product that you're buying off the shelf, [the company is] doing real-time deployments to address security concerns. So find something that you can get tomorrow, and maybe it doesn't meet all your needs, but you can have it address your issues."

That mentality reflects the fundamental tension of shared services, another participant said. "Building the project and getting a lot of people to use it when they all have their individual needs is one of the classic challenges of the open-source world," she added. With successful open-source projects, "you have people who use it to pull their own things, but then they contribute back. That's the part that is currently missing in government, and I don't have an answer right now on how to get people interested in that part."

At a certain level, multiple participants said, agencies and components need to stop focusing on their uniqueness and compromise on common solutions for certain commodities -- to free up resources for innovation elsewhere and be more efficient in general.

"It may be OK to say, 'I want to do my own thing because I have a little bit of a nuance to a requirement here or there.' But I'm sure we can all agree on certain things -- financial services, HR, email. Sometimes we're going to have to make those tough choices and say, 'You can't have it all and be totally unique because it's not your money.'"

There are security arguments as well, another participant said. "Every system that's unique to an agency has a start-up cost, a maintenance tail, initial security deployment with the ATO and a continuous monitoring component. Those are four big-ticket items, times 24 agencies, times how many sub-agencies within the big 24. That's an enormous price tag, and it's hard to secure. It's more complicated."

"I think there's middle ground," another participant said. "Sometimes it's going to be a little bit of a forced agreement: 'These are going to be shared services. We're going to save a lot of money there.' And then we can redirect that money toward the individual innovations in the mission space."

The participant added: "We need to think strategically so that we're actually able to compartmentalize the supporting functions of government into shared services and then have these organizations become better at what they do."