One of the hot topics in defense reform is the new Budget Activity 6.8 (or just 8), a “colorless” appropriation for Software and Digital Technology Pilot Programs. Basically, the problem is that funding is broken up into “linear” appropriations such as RDT&E, Procurement, and Operations & Maintenance. It forces iterative software programs to use waterfall processes designed for complex hardware.
In a perfect world, they say, a software program’s funding shouldn’t get broken into RDT&E and O&M. After the minimally viable product, the software should be field tested, and then quickly iterate between development and operations for experimentation (DevSecOps).
The acquisition organizations in charge of developing the software don’t have access to the O&M funding to do field testing and smaller deployments. And it’s not always easy to pay the O&M bills through transfers, even if there were extra funds around.
Then, when the software gets to a point where it’s fielded, the operators don’t have access to RDT&E funds to go and quickly improve the software on a reasonable timeframe. O&M funds are limited to sustaining activities, not creating new product features.
If the program pulled funds out of the RDT&E vs. O&M context, it wouldn’t find itself in these predicaments. Thus, the “colorless” appropriation for software.
One nuance is that RDT&E funds are “programmed” to a specific project that requires detailed planning and approval. O&M funds, because they are operating the investments planned for in RDT&E, are not outlined by “program” end items, but rather by organization, object of expenditure, or mission. So O&M funds are rather flexible. Commanders can move funds to the highest priority area. They are not locked into precise dollars for precise programs.
For example, if a materiel command has a set of business software systems, C2 systems, embedded mission systems, and so forth, there is some flexibility as to what particular software project gets funded and at what level to support field testing upgrades from the acquisition process. Unlike the RDT&E appropriation, it doesn’t need to specify program funding two years in advance. O&M funds can be treated more like a portfolio. And if there’s a software project that needs a critical update, then the commander can transfer funds over to an acquisition organization to get that coded.
O&M funds have more optionality built-in, unlike RDT&E funds. Why would you pull flexible O&M funds out and put them into this “colorless” appropriation which requires detailed budget programming from two years out, and all its bureaucratic approvals?
Well… that gives the program office who manages the software development a little bit more flexibility (though, not enough to offset the overall reduction in flexibility, in my mind). The program office should now theoretically have a higher budget, since it pulled out O&M funds for it. The program office can pay the O&M costs associated with fielding and testing the software. It gets what it wants in terms of development and testing/fielding, without having the same hassle of convincing the operators to use their dwindling O&M funds.
This, of course, assumes O&M funds will be pulled out with RDT&E funds for the new “colorless” appropriation. Another way about it is that the new appropriation only draws from RDT&E alone, but gives it flexibility to pay O&M’s bills. Then that makes it easier for O&M decision-makers to stop the flow of O&M funds to software deployments, paid by someone else, and instead direct that to numerous other priorities such as readiness.
Let’s presume that the new “colorless” appropriation draws from RDT&E funds and O&M funds. Moreover, let’s presume that a software program in this appropriation is owned completely by a program office in the acquisition organization. People who argue for this configuration are really making the following value statement: More DoD funding should go towards software development/deployment compared to other priorities.
The operators, after all, have some flexibility as to where they assign O&M funds. If particular software programs aren’t getting the O&M support they need to do proper DevSecOps and agile development, then that was a priority set by the operators themselves — supposedly the customer of the acquisitions folks! “Colorless” appropriations basically takes away that tradespace and says these particular software programs will have priority. This necessarily comes at the expense of other O&M tasks, like boosting fighter readiness or reducing ship maintenance delays.
In general, I don’t think it’s a bad thing that software developers and military operators have to negotiate about priorities on fielding and testing software. There’s something like a buyer-seller relationship there, each with their own equities and funding.
And more to the point, the “colorless” appropriation does nothing to address the larger issue of portfolio management. Software programs still need to be lined up in the budget 2 years ahead of time, not to mention requirements processes. That gives ample time for software to enter a detailed waterfall planning phase to get lifecycle cost estimates, sustainment plans, IP plans, etc. So the mere fact that software efforts have to be programmed means you lose the ability to start a set of projects, cancel some, scale others, and keep options open with an ecosystem of developments. In my mind, the DoD’s first priority should be aggregating program elements into portfolios of programs which allows management by real options. Then it can break down the barriers between RDT&E, Procurement, and O&M — but only to the extent that it aligns with organizational design. After all, should RDT&E and O&M be combined and assigned to a single organization, when that organization is not responsible or attached to the warfighter organization?
Leave a Reply