In this episode of the Acquisition Talk podcast, I host an amazing panel on contracting practices for modern software with Florence Kasule (Director of Procurement, US Digital Service), Col. Eric Obergfell (Director of Contracts, Air Force Research Lab), and Caitlin Dohrman (President/GM, Improbable US National Security and Defense). The conversation hits a wide range of important topics that jump off of Mason GovCon’s recent Acquisition Next report, including:
- How defense contracts can align with agile/devops principles
- Whether fixed-price contracts work for modular efforts
- The role of leadership and training in business transformation
- The potential for the “as a service” model
- Tradeoffs between multiple award IDIQs and Commercial Solutions Openings
Download the full-text transcripts
What’s an Agile Contract?
One of the interesting topics was how these leaders thought about defining agile contracts. The US Digital Service has great resources on this at the TechFAR Hub, but Florence defined agile contracts by what they were not:
When the designers come onto the scene and are doing human centered design, and the results of that research create a pivot in terms of functionality, the contracts team says, “Oh, we need to mod the contract in order to allow for this or that.” That is not an agile contract.
That overspecification of requirements is a common problem in government contracting. Not only do they they stymie learning in the development process, they force contractors into a proposal based on fully costed waterfall tasks — if they want to win, that is. And then execution gets pre-set. Caitlin said that “Those kinds of requirements preclude flexibility and responsiveness that agile offers and forces companies into an old paradigm for software development.”
Florence advises contracting and program officials to take part in standup meetings, and actually evaluate what has been completed after a sprint. Leading with this context allows from quicker turnarounds on contract actions. “It should not look or feel like a waterfall contract at all.” For newcomers to agile contracting, start with smaller dollar contracts, never a “big bang.”
Firm Fixed Price for Agile?
One of the interesting discussions is whether agile contracts can use fixed price, or even firm-fixed price, contract structures. When you have short tasks in agile development, deliverables can be quite uncertain, potentially putting risk onto the contractor. As Col. Obergfell mentions, what could happen is that the contractor can become afraid to identify technical debt so that they meet their fixed price deliverable. He wisely cautions that “You’ve got to create the right contract that’s going to drive psychological safety for folks to be able to challenge each other and pivot when we need to get after it.”
Florence, however, encourages agencies to pair agile software with firm fixed price contracts. There is room to flex within the FFP bounds, and going with a T&M contract can be a lot of overhead for an office to get through. T&M and cost-plus also impose cost accounting issues which can be a major issue for nontraditionals. Caitlin agreed that while cost-plus has its place, their assessment of the cost to become compliant with cost accounting requirements in the FAR/DFARS was in the hundreds of thousands over the first two years. Then there’s the cultural aspect that could tip the scales towards compliance, making it hard to recruit and retain the best engineers.
Service Contracts and As A Service
Col. Obergfell brought up an interesting viewpoint on agile contracts at software factories:
Are they really personal services contracts? In a lot of cases, it does feel like it. I know that’s a dirty word in our business, but when we’re trying to be agile, we have government coders right along with industry coders trying to solve a hard problem.
This gets to an issue for me with agile software contracts. Sometimes they feel like your buying labor hours, such as for development support at a software factory or for customization to defense needs. But then at some point you also want to buy software on a product basis, like a cost per license or metered price (e.g., cloud compute). Is there a transition from one to another?
Caitlin remarked that working on joint industry/government teams on agile contracts was some of the most “fun work” she has done. But she also recognizes the value of DoD embracing a consumption-based solution (or “as a service”):
I really liked the “as a service” model. Especially when it comes to dual use technology, there often is going to be some kind of integration configuration — last mile requirement to get something ready for the DOD. So that either can be wrapped into a contract where customers purchasing the license and then the necessary configuration to fields and go live, or you could do it separately as a services contract, for sure. But on the broader point, software is no longer a capital investment. It’s a delivered utility.
Why It Matters
I want to bring it home with why this matters. Certainly there is an aspect of hopefulness about the future that is important. We want to see our government build amazing things that inspire a generation like the interstate highway system, the moon landing, or the human genome project. But just as important is the defense of liberal democracy, open markets, and human rights at home and around the world from authoritarian competitors. Even if the United States economy can outstrip any other, it matters little if we cannot harness that innovation for the common defense. “The threat is the why we do all this.” Col. Obergfell said. “That’s the why. So we can live a free life according to the foundation of our nation.”
Embrace of digital age practices in technology and business is critical to deterring future conflict through persistent overmatch. In the long run, it is the only thing that assures military overmatch. DoD’s Third Offset strategy was developed in the 2010s to regain the edge to strategic competitors. Here’s Col. Obergfell:
The third offset strategy, being if the Chinese and others are stealing our IP, how do we actually iterate faster? We make that IP stealing irrelevant because we’re continuing to deliver capabilities faster. So Acquisition Next I think is an interesting collision between the third offset strategy, our threat, and the acquisition world.
I couldn’t think of a better endorsement for the Acquisition Next playbook we released here at Mason GovCon!
I agree with Col. Obergfell that the strongest position to be in is moving at the edge faster than anyone else. Elon Musk took that stance when he opened up Tesla’s patents to the community so electric vehicles would accelerate as fast as possible. But that doesn’t mean other companies can use the IP to recreate the intangible knowledge built up at Tesla itself. The point is to build an enterprise that cannot be commodified, that is a complex adaptive system always evolving to higher states of complexity. That kind of Defense Department would make IP theft less relevant, and it all starts with business practices that align with modern software development.
Thanks Florence, Caitlin, and Eric!
I’d like to thank Florence Kasule, Caitlin Dohrman, and Col. Eric Obergfell for participating on this panel and sharing their insights. You can listen to Florence talk about these issues on the Gov CIO talkshow and a DAU webinar on software acquisition. Watch a great interview with Col. Obergfell at SOFIC 2021 and an article about how he implemented continuous process improvement at DCMA. Read Caitlin’s article at Army Mad Scientist, From Legos to Modular Simulation Architectures, and you can check out more about how Improbable is helping to build the US military metaverse at Wired.
Leave a Reply