Is that including lifetime sustainment costs? You know the feds like their numbers all in. It can be a bit confusing, because how much inflation should be calculated on future costs?
For this to be Agile, they need to incorporate improvements in small batches (lot size of 1 would be nice) as soon as possible and NOT wait until the next incremental (i.e. yearly) cycle to do so with a large batch of changes.
I agree with the overall idea. I suspect we’ll end up with something similar to aerospace: an open architecture that supports incremental upgrades between production batches.
The trade-off is configuration management. If you’re introducing changes every month, you can quickly end up with a non-standard fleet where each batch is slightly different. That drives up sustainment, training, and manufacturing costs because you lose some of the economies of scale.
I come from the aviation and industrial engineering world, and I’ve seen this firsthand. Aircraft that were supposed to be built to the same standard often weren’t, and our parts warehouse ended up much larger than it should have been because every airframe had its own configuration quirks. It’s always a balance between agility and standardization.
That's a good point. I come from the Automotive world, where this is much less common, but mid-year vin splits are a thing that will cause technicians and parts managers pull their hair out. I imagine it has to be a balancing act. If you want the benefits of agility, you can't tie yourself 100% to scheduled and extensively planned revisions, you have to be willing to pivot on short notice when something doesn't work, or upgraded designs become available. But if you care about sustainment, you need to be able reign in the worst tendencies of tech junkies who need to have the newest version of everything.
I think the more work is put into designing the process of integrating improvements incrementally, the better the end result. While I love that we are no longer moving at a arthritic snail's pace on military procurement, I worry that we will discard some gems and skip some important steps when discarding the dross. Only time will tell.
I could see GDLS-C creating an a la carte menu of individual components and systems and 'combos' that would put them together into distinct configurations. From there, as the next order tranche approaches, the CAF would review the current menu and combos and request to government X of this, Y of that, etc. This would avoid surprises on new builds where GDLS-C took initiative to modify the base platform without any fanfare but still give the CAF the ability to fine-tune the platform and create logical sub-variants without waiting for generational updates. If we end up with unwanted subvariants because someone ordered one of everything off the menu, that's nobody's fault but the CAF.
Are those numbers right? 3908 vehicles at 62-86 billion would make the unit cost 15-22 million per vehicle.
Is that including lifetime sustainment costs? You know the feds like their numbers all in. It can be a bit confusing, because how much inflation should be calculated on future costs?
Excellent question.
For this to be Agile, they need to incorporate improvements in small batches (lot size of 1 would be nice) as soon as possible and NOT wait until the next incremental (i.e. yearly) cycle to do so with a large batch of changes.
Indeed. Should have probably distinguished more lol. Excited?
I agree with the overall idea. I suspect we’ll end up with something similar to aerospace: an open architecture that supports incremental upgrades between production batches.
The trade-off is configuration management. If you’re introducing changes every month, you can quickly end up with a non-standard fleet where each batch is slightly different. That drives up sustainment, training, and manufacturing costs because you lose some of the economies of scale.
I come from the aviation and industrial engineering world, and I’ve seen this firsthand. Aircraft that were supposed to be built to the same standard often weren’t, and our parts warehouse ended up much larger than it should have been because every airframe had its own configuration quirks. It’s always a balance between agility and standardization.
That's a good point. I come from the Automotive world, where this is much less common, but mid-year vin splits are a thing that will cause technicians and parts managers pull their hair out. I imagine it has to be a balancing act. If you want the benefits of agility, you can't tie yourself 100% to scheduled and extensively planned revisions, you have to be willing to pivot on short notice when something doesn't work, or upgraded designs become available. But if you care about sustainment, you need to be able reign in the worst tendencies of tech junkies who need to have the newest version of everything.
I think the more work is put into designing the process of integrating improvements incrementally, the better the end result. While I love that we are no longer moving at a arthritic snail's pace on military procurement, I worry that we will discard some gems and skip some important steps when discarding the dross. Only time will tell.
I could see GDLS-C creating an a la carte menu of individual components and systems and 'combos' that would put them together into distinct configurations. From there, as the next order tranche approaches, the CAF would review the current menu and combos and request to government X of this, Y of that, etc. This would avoid surprises on new builds where GDLS-C took initiative to modify the base platform without any fanfare but still give the CAF the ability to fine-tune the platform and create logical sub-variants without waiting for generational updates. If we end up with unwanted subvariants because someone ordered one of everything off the menu, that's nobody's fault but the CAF.
Oh man! Noah, you dove head first into describing some fascinating continuous procurement! I love it!
I can't wait to see how it shakes out.