The Air Force’s ABMS is a family of systems intended to replace the command and control capabilities of aging legacy programs and develop a network of intelligence, surveillance, and reconnaissance sensors…
Air Force officials stated that they intend to use a flexible acquisition approach to develop ABMS, one that is outside of traditional pathways such as a major defense acquisition program or middle tier acquisition. According to the Chief Architect, this approach will allow ABMS to develop and rapidly field capabilities. Specifically, the Air Force intends to break up technology development into many short-term efforts, generally lasting 4 to 6 months each.
The Chief Architect stated that the goal of breaking up development into smaller increments is to increase innovation by requiring multiple contractors—including those that may not usually engage with DOD—to compete for contracts more frequently. These short-term efforts will include prototyping and demonstrations to prove that the capabilities work. Those that are proven will be delivered to the warfighter.
By using this approach, the Air Force intends to field capabilities sequentially and more quickly than if all were developed and delivered at one time as is typically done for traditional acquisitions. Additionally, Air Force officials indicated that this approach will not lock the Air Force into long-term development efforts with just one contractor and will allow the Air Force to more easily move on from unsuccessful development efforts.
That was from a General Accountability Office report on the Advanced Battle Management System. ABMS has received $172 million through FY 2020, and requested $302 million in FY 2021. HT: Alex C.
The Air Force’s strategy sounds reasonable. It hasn’t been assigned to an Adaptive Acquisition Framework pathway because it is not a traditional stovepipe program. It will be run by a Chief Architect responsible for coordinating across the Program Executive Offices. It seeks continuous delivery and updated requirements as knowledge grows, and always keeps multiple contractors involved.
Yet for the GAO, this agile/devops/modular approach reflects poor management. Best practice guides would have the Air Force fully define requirements, carefully specify the materiel solution, create a program office, and work out a fully costed plan complete with an integrated master schedule. The GAO stated:
The Air Force started ABMS development without key elements of a business case, including:
• firm requirements to inform the technological, software, engineering, and production capabilities needed;
• a plan to attain mature technologies when needed to track development and ensure that technologies work as intended;
• a cost estimate to inform budget requests and determine whether development efforts are cost effective; and
• an affordability analysis to ensure sufficient funding is available.GAO’s previous work has shown that weapon systems without a sound business case are at greater risk for schedule delays, cost growth, and integration issues…
Officials stated they intend to develop cost estimates for each of the 28 development areas in the future but did not identify a timeline. The GAO Cost Estimating and Assessment Guide acknowledges that cost estimating is more difficult when requirements—and the technologies and capabilities to meet them—are changing and the final product design is not known while the system is being built. In these cases, leading practices call for developing cost estimates that should be updated more frequently to reflect changes in requirements.
With the usual motions of the cost estimating process, even for the more agile Software Pathway, it takes an average of 210 days from start to finish to produce a cost estimate. But if ABMS hits four to six month iterations as planned, then it will be inside the OODA loop of the cost estimate.
Presumably, the resource level won’t vary so much from an initial cost estimate. As I’ve seen on numerous EVMS reports for software programs, after the ramp up period the contractor hits a steady burn rate and are essentially level of effort. The real challenge will be fully defining requirements and technical tasks very far into the future. And then attempts to do so and assign costs collapses the original intention to do things differently.
The GAO wrote “the lack of an ABMS business case introduces uncertainty regarding whether the needed capabilities will be developed within required time frames.” I think listening to Roper and Chaillan they lay out excellent business cases — it’s just that it doesn’t conform well to waterfall approaches demanded by the GAO. If all the usual prediction and control processes are applied to ABMS, then the software development team will be hemmed into a water-agile-fall environment. There needs to be a rethinking of what justifies a program justification.
Leave a Reply