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.
NP. Agile is an overloaded term and means many different things to many different people. Expanding it to meaningful terms is a useful way of clarifying what we mean by it.
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 for the ACV-W 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, while still giving the CAF the ability to fine-tune the platform and create logical sub-variants without waiting for generational updates or GLDS-C to come up with everything on their own.
If the CAF want to experiment with an all-singing, all-dancing, all-loitering munition arsenal ship that crams 100+ drone VLS cells in the back, well, if GLDS puts the parts on the menu and the CAF is prepared to pay for a one-off, more power to them. I wouldn't be shocked if some solid concepts came out of such an approach.
And if we end up with a bunch of dead ends and unwanted subvariants because seemingly some maniac ordered one of everything off the menu, that's ultimately nobody's fault but the CAF (and government).
I like that idea. And it creates a record of variants that can be used for parts ordering and repair manuals. Still would require some planning to make that information available to downstream technicians and quartermasters in a usable form, and I would not want to rely on a completely supplier provided system, you need to provide a framework of expectations to get usable information out of manufacturers. They have a perspective that is intensively focused on manufacturability rather than repairability. Which is understandable, but not always ideal for the poor smucks trying to keep them operational on a day to day basis. But I can see a workable framework in the idea. Maybe standardize on a 6 month time period. If they can produce around 50 per year (190 ÷ 4yrs = 47.5), that would yield up batches of around 25 vehicles. Managable from the perspective of variant control, no need to use too many decimal points, lol. But still vastly more agile than a once per decade procurement.
I hesitated to add the reference to Ukraine and probably shouldn’t have forked on a side topic. My intent was to show that when « the ship is burning » people are much more open to different ways of doing things. In saying that, I’m probably forking a new side topic 🤦🏻♂️
You bring up good points again, showing the implications of adopting complex solutions. I suspect the shift towards autonomous and attritable systems will influence our choice of technologies going forward (oh no, just forked another side topic 🤦🏻♂️).
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.
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?
NP. Agile is an overloaded term and means many different things to many different people. Expanding it to meaningful terms is a useful way of clarifying what we mean by it.
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 for the ACV-W 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, while still giving the CAF the ability to fine-tune the platform and create logical sub-variants without waiting for generational updates or GLDS-C to come up with everything on their own.
If the CAF want to experiment with an all-singing, all-dancing, all-loitering munition arsenal ship that crams 100+ drone VLS cells in the back, well, if GLDS puts the parts on the menu and the CAF is prepared to pay for a one-off, more power to them. I wouldn't be shocked if some solid concepts came out of such an approach.
And if we end up with a bunch of dead ends and unwanted subvariants because seemingly some maniac ordered one of everything off the menu, that's ultimately nobody's fault but the CAF (and government).
I like that idea. And it creates a record of variants that can be used for parts ordering and repair manuals. Still would require some planning to make that information available to downstream technicians and quartermasters in a usable form, and I would not want to rely on a completely supplier provided system, you need to provide a framework of expectations to get usable information out of manufacturers. They have a perspective that is intensively focused on manufacturability rather than repairability. Which is understandable, but not always ideal for the poor smucks trying to keep them operational on a day to day basis. But I can see a workable framework in the idea. Maybe standardize on a 6 month time period. If they can produce around 50 per year (190 ÷ 4yrs = 47.5), that would yield up batches of around 25 vehicles. Managable from the perspective of variant control, no need to use too many decimal points, lol. But still vastly more agile than a once per decade procurement.
Maintainer: What in the actual fuck is a LAV 7.0.5.1 and why does the manual say I need to use an OEM-approved Bosun's chair?
I died... 🤣
I hesitated to add the reference to Ukraine and probably shouldn’t have forked on a side topic. My intent was to show that when « the ship is burning » people are much more open to different ways of doing things. In saying that, I’m probably forking a new side topic 🤦🏻♂️
You bring up good points again, showing the implications of adopting complex solutions. I suspect the shift towards autonomous and attritable systems will influence our choice of technologies going forward (oh no, just forked another side topic 🤦🏻♂️).