Note: this article originally appeared on DefenseScoop
In this op-ed, Dcode’s Riya Patel speaks with DOD’s Jen Bird and Army’s Paul Puckett about supporting emerging, innovative companies in the defense landscape.
Having access to the latest technology is critical to maintaining a competitive advantage on the global stage. Agencies across government are being asked to “innovate,” often with little other direction. Business and technology leaders alike look to private industry to see what companies with businesses similar to their missions are doing. Implementing the same tools and processes used by these companies is difficult in government as it involves multiple aspects of contracting, tech development, policy, and program management. Even with the complexity involved in introducing new technology, forward-thinking government leaders have been taking steps to bring in the tech needed to make innovation a reality.
As we discussed in our last article, government and industry both struggle with bridging the “Valley of Death” — getting emerging tech solutions into government systems and then working to ensure they can scale to meet innovation goals. As such, there are a number of Department-wide efforts underway. The Accelerate the Procurement and Fielding of Innovative Technologies (APFIT) program run out of the Office of the Under Secretary of Defense for Research and Engineering (OUSD(R&E)) was designed to expeditiously transition technologies — with priority given to those developed by small businesses and/or nontraditional defense contractors — from pilot programs, prototype projects, and research projects into production. Additionally, the DoD Commission on Planning, Programming, Budgeting and Execution (PPBE) Reform is working to identify areas for future reforms that will ultimately improve the DoD’s ability to flexibly and efficiently match resources to strategy.
Dcode asked the same questions to government executives that we did to tech execs to help determine the best ways to work within existing governmental systems to develop and deploy solutions that look nothing like traditional government service. Below are insights from:
- Jen Bird; Director, Innovation Steering Group at Office of the Secretary of Defense. Jen serves on the Innovation Steering Group designed to improve the department’s ability to transition innovative technologies into programs of record.
- Paul Puckett; Director, Army Enterprise Cloud Management Agency. Paul led the effort to elevate the enterprise cloud office to a field operating agency, and currently leads the organization in its mission to deliver a secure, globally-dominant cloud ecosystem, foundational to the Army modernization strategy.
Q: From your view, what were the biggest blockers that prevent technology from being adopted across the organization and scaled?
Jen Bird (JB): I think one is general alignment between the science and technology community and the acquisition community. The department is so big and our science and technology personnel are working really hard at developing new technology, developing new concepts, they’re all across the country at different labs. They’re often working from a science-first perspective and that’s exactly what they should be doing. Meanwhile, the acquisition community is very closed off focused on program requirements and all of the sort cultural issues surrounding acquisition. When R&D comes to acquisitions and says, “here’s a solution to what the warfighter needs,” acquisition frequently has to push back and say, “I see that but it can’t get fielded exactly that way.” If there was earlier and more frequent communication this back and forth could be avoided and the time to field cut dramatically.
Paul Puckett (PP): The first blocker that needs to fall is how we write a requirement. Today we write requirements as if we can predict the future and oftentimes it takes us 5-10 years to validate whether we were right or not. Instead, we need to think that our requirements are really just hypotheses that we need to test as quickly as possible. We need to change a lot of Statements of Work to Statements of Objectives that articulate a domain in which there is a problem to be solved, the objectives we want to achieve and the metrics that help us know we’re on the right path. The second key blocker are our testing processes for security, usability, interoperability, etc. that are so painful to navigate that the thought of doing twice is nearly unbearable. We inadvertently are incentivizing programs to wait to push everything through at the same time because of how cumbersome our processes are. Our test processes need to be redesigned to be quick, painless and useful services so we can test, deploy and get user feedback to improve our next delivery capability.
Q: What should the tech companies and government know about how one another works?
JB: We know that the Department is difficult to work with and one of our priorities is to find ways to improve how we work with industry to get innovation into the field faster. We’re doing a lot of work right now to figure out how we can improve processes and cut through regulations to more rapidly onboard new capabilities. We’re also working to provide new tools to businesses to help them find the right customers within the Department.
PP: When you write a firm fixed price contract thinking you’re de-risking the government from going over budget with a crazy amount of unknowns and external dependencies that will probably make a company look bad if they fail to deliver, you’re just going to get more expensive costs to do the work up front. The same goes for massive contracts awarded to a single vendor who is now going to be forced to hire or sub to a bunch of people they don’t know, who don’t have their culture and who don’t understand how to work as a team yet they’re responsible for major outcomes at immense scale. I also wish the government and industry would align on business models that encourage the right behaviors for adoption and growth of a product. Too often the government does linear math where if we go all in on a software product it looks like it will be too expensive to even start when adoption is not linear. We need a reverse hockey stick graph to get to all-you-can-eat type models for products with mass adoption across the DoD.
Q: Are there short-term solutions the DoD can enact while we wait for policy to change?
JB: One way we’re hoping to improve how DoD works with industry in the short term is by ensuring that the innovation offices within the different services are cooperating on technologies of mutual importance. We’re improving collaboration in a few ways. First, we’re putting together an “innovation analytics” capability to help identify what companies may have technologies that are of use to the Department. Second, we’re meeting more frequently as the DoD “Innovation Community of Interest” to share news, opportunities and lines of effort. Third, we’re putting together a database to help DoD better understand who is doing what within the Department and where we might find synergies on tech pursuits.
PP: Sometimes policy is not the inhibitor. It’s our own skillsets and mindsets that we have to overcome. Writing more objective-based efforts with our Army Capability Managers are starting to really take hold and it is creating space for the PEOs to have more flexibility with how we acquire, design and deliver solutions. We’ve also been working within the Army about a new construct of “IT requirements box” that carves a ceiling of money to address an IT enabled capability of how we conduct the enterprise, business, warfighting, and intelligence mission of the Army. Within that ceiling we tag a portion of money that aligns with a more detailed capability drop that has a tighter window for design and delivery that focuses the work just enough for the program offices and gives the Hill the oversight they need. Human centered design practices can also make a difference. When we historically give the PEOs explicit requirements with specific solutions, user feedback doesn’t really have a place to go because a PEO has to do the thing they were told to do way back when. This can allow our PEOs to move from being requirements-centric to user-centric.