Peter Modigliani (00:09):
Good morning, everyone. I'm Pete Modigliani. I'm at Beacon Global Strategies, helping a lot of defense tech companies navigate the bureaucracy. A little background, 26 years, DOD Acquisition. I have the gray hair to show for it. I started in Air Force Acquisition and then helped build a lot of the major new pathways and strategic initiatives. So I want to share with you today some of the special authorities. Congress has given the department many authorities to actually move with greater speed and agility. There are, however, saboteurs in the mix across the Pentagon and Congress that are impeding some of the efforts. My personal mantra is to help DOD deliver better capabilities faster. So how do we get those solutions in the hands of the warfighter? Because we still cannot lose track that China is the pacing threat and we are far behind? So I want to give you a quick rundown.
(01:02):
Just lay out the strategic environment and hit three main areas. Middle tier of acquisition - rapid prototyping, rapid fielding. Software acquisition pathway, which I think most of the audience would be interested in. And then commercial acquisition. So part of the Atlanta Council Commission on Defense Innovation Adoption, we had a big report earlier this year, and it's starting to have some ripple effects in the NDA and within the building, and laid out some of the big challenges that DOD Acquisition is facing. So we're all familiar with the long timelines to deliver capabilities. When it takes 10 to 15 years to go from idea to IOC, that's a problem. The shrinking industrial base; in the last decade, DOD has lost 40% of its small businesses. NDIA talks about a 5% decline each year of the last five years. We absolutely have to rebuild the industrial base. We need all the leading defense tech companies to get in the mix and make it easier to do business with DOD.
(02:03):
The Valley of Death's been talked about at length. We spent billions of dollars on really cool tech, really cool prototypes. They never make their way into acquisition programs and ultimately, field it to the operators. Hamstrung workforce, been there for 26 years, know the absolute pain. It's more and more compliance, more oversight, more certifications, and more and more constraint. So that's where many people are leaving just because they're frustrated with the bureaucratic culture. So we'll get to it.
(02:31):
The biggest thing is understanding of the threat window and the speed of delivery. Admiral Davidson talked about the Davidson Window of 24 to 27 is the prime threat window of when China is going to act on Taiwan. That opens in two months from now. That was always years ahead. Now it's two months away. All of the major systems that DOD is developing to deter China aren't going to be delivered until the 2030s. So we need to think what capabilities can we deliver in the next two to four years, with the bias towards closer to now, that are actually going to have some effect to deter China because they're still operating with 30-year-old legacy systems for our forces.
(03:13):
Whereas China's building an entire navy in the last 20 years. Even the current NDS talks about our system is too slow, little incentive to design open systems, and incorporate cutting-edge technology. So even the NDS says it, but still, the bureaucracy impedes progress. And a key slide I always like to highlight is, an acquisition executive years ago at a conference said, "Hey, if you want things done right, you got to take your time and do it right." We always talk about burning down acquisition risk. Oh, let's do some more analysis, more paperwork, more reviews, more oversight.
(03:50):
We're going to have more people certify to make sure you didn't screw up like the last team. So we'll spend more time, burn down that risk, get a better understanding. We're going to test the heck out of it, and we're going to certify with all these reviews. Every month you do to delay that acquisition program just transfers the risk to the operational command. They're working with 30-year-old legacy systems that are falling apart, increasing cost, lower reliability. There's only so much duct tape to go around. So it's always striking a balance between speed and rigor. You can't say, "hey, we got to go fast. I'm just going to skip testing. We'll do that later." No, that doesn't make sense. But looking at what are the pacing elements that you can deliver so that the operators have some meaningful capability in a relevant timeframe.
(04:39):
So a few years ago, we blew up the entire acquisition policy, the 5,000 series, and really did some transformational efforts. And there were six key guiding principles in the new 5000.01 and 02. I want to foot-stomp the first three: empowering program managers, simplifying the policy, and tailoring the approaches. And then we explicitly wrote in "program managers will tailor processes, reviews, and documents based on the unique aspects of your program - size, complexity, risk, urgency, and other factors." So have clarity of purpose of what is your program trying to do, tailor the processes and reviews to go address that. This isn't the cookie cutter one-size-fits-all. This isn't the textbook approach that's been going on for 30 years. And the ugly DAU wall charts, that are two posters, five-point font, of all the boxes that you need to navigate. So tailor, tailor, tailor.
(05:33):
So we blew up the one textbook model into six acquisition pathways. And again, it's choose your own adventure, and then tailor within, and you can navigate multiple pathways along the way. So you want to urge capability in two years? Great. Take the first one. Middle tier, which we'll dive into. Rapid prototyping, rapid fielding within five years. MCA, the traditional pathway, you can still heavily tailor that to the unique aspects of what you're trying to do. Software pathway, I think I've read somewhere, software is uniquely different from hardware. So we actually tailored a process for that. Business systems has been around for a while. 1,700 business systems, most of them are struggling. Some of them are getting more and more involved with the software pathway. And then acquisition of services is more of a contracting pathway, but there's opportunities to expand that role.
(06:23):
So we built it all on a website, integrating policy guidance and other resources. So I want to dive into middle tier of acquisition. In 2016, the late Senator John McCain realized the issue. He saw what China was doing. He saw the US was far behind in delivering capabilities, put in the NDA, "go forth, and use middle tier." The DOD sat on it for two or three years, finally started implementing it. So there's two elements. Rapid prototyping, rapid fielding. For rapid prototyping. Hey, there's some emerging tech maybe coming from the commercial world, or defense, or there's a clear commercial technology that may have some military applications. Go prototype it, go experiment with it, see if there's a there there, and get a capability in the operational environment as quickly as possible.
(07:10):
Rapid fielding is, hey, there's something mature, readily available. Just turn on the production line and go off and run. The keyword here is always rapid, but then people still go, well, but the standard, 30-year lifecycle of an acquisition program, we're going to spend 10 to 15 years and use it for 30 to 50 years. It hurts their head when they see these processes.
(07:33):
So for middle tier, one of the beauties of it was Congress put in the statute, you're exempt from JCIDS. JCIDS is an evil bureaucratic process. It said get your requirements done in six months or less. So what did the Services do? They built a mini-JCIDS process within their Services, where the Chief of Staff of the Services are signing off on the requirements document for rapid prototype. And you're like, "you guys are killing me." But at least it's within the services and there's a six-month limit. But you can go through and do rapid prototyping. Hey, you could do a few prototypes. Eventually, you get a thumbs up and say, "hey, this works, this is great. Go build me 100 or 1,000 of them." You could pivot over to rapid fielding, and turn on the production line, and run. Or you can start with, "hey, rapid fielding, maybe there's a 50-60% solution readily available. Go produce the first batch, and rapidly prototype the next iteration. So you could still experiment with it. And again, it's not just the linear process of the traditional acquisition environment, but get it done within five years.
(08:34):
So DOD IG, I mean, this process has only been around for a few years. IT already did an audit on it. When the IG is coming in, they're usually not going to say nice things. The IG doesn't say nice things about their own mothers. They actually reported on middle tier and said "middle tier is actually helping the culture with greater speed and agility, increased efficiencies, and effectiveness." We're streamlining the acquisition processes, expediting, prototyping, and fielding the capabilities. Acquisition executives encourage the use, and the PEOs and program managers are actually using these new authorities.
Speaker 2 (09:11):
Are there any use cases that are supporting what the IG is saying that that is not classified?
Peter Modigliani (09:16):
Yes. I'll get to it in two slides.
Speaker 2 (09:17):
Perfect.
Peter Modigliani (09:19):
So one step forward, two steps back. So while DOD is starting to move out, experimenting with new authorities, there are some that go, "hey, don't run too far, you may fall and skin your knee." So SAC-D for the last few years...now these are the appropriators. These are the ones that focus on the budget. They hate this. So they go, "hey, for all the rapid prototyping, we want to see your acquisition strategy, your contract strategy. We want to see your cost estimate. We want to see you've certified full-funding for the entire program for the life of the program. We want DOT&E to certify your test strategy for a rapid prototype."
(09:58):
Now the new one is USD(I&S) to certify your lifecycle threat strategy. Joint Staff, who also is miffed that has the exemption from JCIDS, goes, "yeah, I know it says so in the law, but we still want to get involved because they're ****** that hundreds of programs are now used in this pathway, and they don't have the oversight from their perspective. Now Joint Staff has a need. They're trying to build that joint solution. We need a joint force. But there's that right mix. Do they need to certify and approve each requirements document? Maybe not.
(10:35):
So, to your point, there are success stories out there. Last year, we published an article, "Middle Tier of Awesome," and just highlighted six programs. You see a wide range of programs. It's not just some small little thing. We've got the F-15EX, we've got squad weapons, we've got autonomous systems. These programs are saving years off the timeline. They're rapidly iterating. They're actively engaging industry. I heard that's a thing these days to say, "hey, what makes sense?" They're working through designs, iterating, pivoting, and then delivering capabilities in record time. There are success stories out there. I think there are roughly 150 or more that have used the pathway, various stages of progress. So you could see the article at the bottom to get more details. But again, we need to get those success stories out there. Rapid prototyping, rapid fielding.
(11:30):
So some key lessons as we went through and reviewed a lot of the programs over the years, and there's a full range, there's some that tried to abuse the system with a massive multi-billion dollar approach that was constrained. They tried to do too much within a five-year window. So we said, "hey, smaller is better, faster is better." It's easier to do a $50 to a $100 million program than it is to do a billion-dollar system. If you want to spend five years, or we saw many programs come in and say, "hey, in four years, in 11 months, we'll deliver the first prototype because we're within that five-year window." I'd rather see, "hey, within the first two to three years, you're delivering major capabilities." I'd rather see 10 prototypes that you've iterated on, not just one big one at the end.
(12:15):
Obviously, more competition is better. That's universal to all programs. Delegated decision authority. So when Congress helped to break up AT&L, delegate decision authorities down to the lowest practical level, there was a great movement, a great shift down to the SAEs and down to the PEOs, the program executive officers. Yet decisions keep trickling back up. Tailor, tailor, tailor to the unique aspects of what your program is trying to accomplish, and then pivot. There are many that say, "hey, I built my strategy. I'm just going to execute towards that strategy for the next five years." Now if a year in you realize, "hey, the design isn't working, the contractor isn't working," pivot. If you say, "hey, I was going to build a UAS, but maybe a small stack could address that need more effectively," cancel the program, that's okay, do a radical pivot. Just don't follow down the wrong approach because you've committed to a strategy for the next five years. Then active user engagement throughout is key.
(13:16):
So I want to pivot over to the software acquisition pathway, which I think this audience will really resonate with. Again, we were already in the process of building this pathway, and Congress said, "hey, go do it." So it had the authority of law to help reinforce, help overcome some of the blockers. It said create two pathways, one for applications and one for embedded software, software in the major web systems. And then, after a few years, because of the success, they said, "hey, also do that for business systems." So four key things in the law, it says you shall not be treated as an MDAP. The Major Defense Acquisition Program.
(13:51):
So all the statutory burdens that are put on the major billion-dollar systems, doesn't apply to software. You're exempt from JCIDS, streamline requirements acquisition and budget, and then deliver software in a relevant environment within one year of first obligating funds. Now people would be shocked at, "hey, a year is a lifetime for software." But when DOD was delivering in three to five-year timelines, a year is great for the statutory. Congress is like six months or less. We want month, we want weeks, we want daily. But at least getting that first software release out the door is key.
(14:27):
Yes.
Speaker 3 (14:30):
When you say software acquisition pathways [inaudible 00:14:33] in depth, how does that work for software acquisition pathways that are wrapped up within a [inaudible 00:14:38] programs? So like a Sentinel program, for example. Huge software effort. But I know one of the issues we ran into was the OUSD (A&S) was our process decision authority, and a lot of the OUSD staff was very, very critical of our software acquisition.
Peter Modigliani (14:58):
So I won't go into the individual program, but so there's a lot of nuance of when you're doing, is the core element software or is it a hardware system that just has a big software element, and how much they separated or how much it's integrated goes into a whole morass from an acquisition policy and oversight perspective. Obviously, with A&S as the MDA, 99% of the software programs are usually at a lower level. But if it's a pure software-play program, you could spend a billion dollars, and you're not at the OSD-level oversight with all the MDAP issues. So Sentinel has a whole variety of other issues. So it's delineating the hardware versus the software. But I could talk to you offline about some of the nuances there.
(15:46):
So some key elements, all this is pretty common sense. Use modern software development practices, DevSecOps. Actually talk to humans when you're designing it. User engagements, leverage enterprise services, and automated tools. So here's the pathway. We really wanted to streamline it, it's not your traditional DAU wall chart. Two phases: planning and execution. And the vision is get through that planning phase within six months or less. Define your needs, define your core element to your strategy, acquisition, contracting, IP test, and the like, and get a high-level cost assessment. And then it doesn't have to be perfect. It's never going to be perfect out of the gate, but it should be good enough to say, I can start development. I've managed enough risk. I have enough of a plan together to begin development, and I'm going to iterate on my needs, on my strategies, and my approach. And then same at the bottom for the design, how I'm going to leverage enterprise services, bake in cybersecurity on day one.
(16:43):
And then the other key one is on active user engagement. So there's a user agreement that's signed between the acquisition community and the operational community that will actually have end users interact with the development team and the acquisition team on a regular cadence. They'll provide insight into the operational environment. They'll provide feedback on draft software and a constant iteration; "where are the priorities? How does this work? Hey, the software's great, what if it also did this?" But hightouch points between the two communities. And then, you go through, you have Minimum Viable Products where you're demonstrating capability. And then the MVCR, the Minimum Viable Capability Release, that's that it delivers something in an operational relevant environment within that first year. Software's never done. You're going to continue to iterate on all of it, but the key is rapid iterative releases, regular cadence with the broader user community. Over 60 programs are using it. We publish on the website exactly which programs. You can always reach out and engage them for insights.
(17:47):
Some key nuances just going down the left, high-level requirements document. You're not writing a 500-page technical detail. High-level needs, down to a roadmap. What are you going to do over the next few months and years? Down to the more tactical backlogs. Across the top, your strategy, your user agreement, that cost estimate, we're not locking down requirements upfront. So you can't do a detailed cost estimate. So that cone of uncertainty will narrow over time. For budget, the reality is, it's build to budget. You give me $10 million, I could deliver you this amount of software. You give me 15, I'll deliver you this much more. You give me nine million, I'll give you a 90% solution. That flexibility is also a risk in the budget process because it's easier just to trim a little from the software programs. So you got to have that protection.
(18:37):
And then the last one is the value assessment. At least annually, the operational community will provide a report card back to the acquisition community. "Hey, we delivered four major releases. We spent $50 million. We delivered you this capability." The operators would go, "hey, that's great. We saved, we had huge mission impact here. We retired legacy systems and manual processes, huge mission impact, great ROI." Or, "hey, this was a glorified Excel file. This wasn't worth $50 million. Try again." But you use that insight to then shape requirements, shape your design, shape your strategies, and move out. Again, active iterative releases with the broader community.
(19:19):
And then the final area I want to hit is buying commercial. It's in law, "thou shall buy before build." So across the top is the traditional acquisition process. We'll define requirements, do a whole bunch of analysis, develop tests, and produce the system under tight DOD controls.
(19:38):
I'd rather industry react to some communicated needs, use their own R&D, and then we can acquire a commercial solution. It may not be 100% out of the gate, but we can iterate. But in statute, it says define requirements to the maximum extent practical that commercial solutions can meet those needs. Acquisition executives shall acquire commercial solutions. And similarly, you require the primes to do the same for all their sub-components. And then there's even breakouts for non-traditional defense contractors treating them as commercial.
Speaker 3 (20:13):
Can I ask you a question about that?
Peter Modigliani (20:15):
Please.
Speaker 3 (20:15):
So from a commercial software perspective, would them leveraging open source software satisfy that requirement?
Peter Modigliani (20:28):
I don't know. Let me circle back to you on that one.
(20:33):
Jonathan could probably help answer that one as well. I'm a Program Manager by trade. I know enough about contracting to get myself into trouble. So I was taught early on, partner with the CEOs that get it, and be tied at the hip into co-developing strategies. So how do you buy commercial? So one of the things I'm always a strong advocate is breaking things up into more portfolios. I want to break down the big, major systems, and I want to deliver an integrated suite of capabilities. So for a PEO, instead of overseeing 50 stovepipe programs, I want that suite of capabilities. And if you break down these big systems that only the primes could deliver into smaller elements, you're going to open up more opportunities for commercial solutions to meet these smaller elements. Engage industry early. DIU is a valuable resource. They have a valuable team that goes out and does tech scouting.
(21:29):
They know the tech, leverage the pathways and the strategies. And then there's also novel approaches, prototyping, procurement for experimentation. It used to be 2373, there's a new number, but you can buy tech, experiment with it, test, see if there's a there there. And then explore other means to acquire a full-up solution. Harness the technical standards, but really get that training, that education, get the community, get the workforce to fully understand how do I buy commercial solutions? Are you doing the vetting in the requirements and acquisition reviews to say, did you explore commercial first? And do you have the senior leaders that are constantly championing commercial solutions? Because we don't have 10 years to wait to develop the new solution.
(22:15):
So one last thing I want to share with you is the program side of the Valley of Death. We talk Valley of Death at length. If I'm still an Air Force Program Manager and you come to me and say, "hey, I've got this great new tech sub-component for what you're trying to do, it's going to double your performance at half the costs." And I can look at it and go, "wow, that's great, go away." Because I just spent years getting my requirements document through JCIDS, my acquisition strategy done, program budgets through Congress. I'm constrained with an acquisition program baseline for cost schedule performance because that's the only thing that matters, not mission impact. And I've got a contract with the prime.
(22:52):
I've got to break all those things to get your new tech inserted into the program. That's cost, that's risk, that's time to my program. So I fully agree that tech is needed. I can't do it. That's a common barrier that many programs are facing. It's not because they're bad people, just the environment we're in. Now, there's strategies to overcome each of those barriers, but that often doesn't get discussed enough. Everyone thinks, "hey, I'm going to be the new programmer of record, or if I want to do tech insertion, here are the major challenges to that that we need to work through those issues."
(23:28):
And then the closing thing is we have to fix this before it's too late. China's the pacing threat. Our major systems aren't going to be delivered till the 2030s. We need capabilities delivered in the next two to four years before it's too late. We've made great progress. There are great authorities. DOD has a lot of the authorities out there, yet there are still some within the Pentagon and in Congress that want to sabotage these authorities. So we need to continue to rally as a community, work together, build on our success stories, and then deliver better solutions faster. Thank you.
