Why the Army ditched its organic design for OMFV

The Army’s decision to not submit its own design bid for the restarted Optionally Manned Fighting Vehicle (OMFV) prototype competition was to remove concerns over conflicts of interest and avoid potential protest-related delays, an official said Wednesday.

 

… “As you can imagine that, right off the bat, puts us in a significant potential conflict of interest, because we would’ve been the engineers helping with requirements development and characteristics development. We would be the engineers that support writing evaluation criteria and all the things involved that you would have in a competitive procurement,” Langhout said.

That was from a Defense Daily article, Army official details decision to drop idea of submitting its own design for OMFV.

The Army GVSC has worked with companies like BAE, GDLS, and so forth for years on ground vehicle design, including through CRADAs. They have access to all companies’ past bids. Engineers will have a hard time putting that proprietary data aside for their own bid. Then, GVSC has a large role developing the contract requirements as well as creating criteria for source selections. No wonder it is ripe for protest.

Another issue people may have is that GVSC may be able to design and even prototype a very exquisite vehicle, but would it be producible? And who would produce the design?

By the way, the RFP for the digital concept design phase released on Dec. 18, 2020. There will be five awardees, the top three of which will go onto the designing prototypes. Actual prototyping begins in fiscal year 2025. Testing then starts the next year and production in FY 2027. The long front end may be explained by the concept phase having pretty open ended requirements, and there’s a parallel phase for developing an open architecture.

That’s another point of contention. The Army wants to define the modular open systems architecture for OMFV to keep competition open. Yet that doesn’t seem to be mature yet. So much of the concept and prototype design may proceed based on the contractor’s own versions of MOSA — or there will be some evolving interaction there to keep everyone in step.

Owning the technical baseline

My current thinking is that the government needs to be able to own the technical baseline in order to contract more effectively. But what does that mean? That the government should actually design, prototype, and produce OMFV itself? Or perhaps be responsible for the MOSA? Or perhaps detailing stricter requirements based on its analyses?

Owning the technical baseline for me means having a large number of hands on engineers actively prototyping components and subsystems themselves. The intent shouldn’t be demonstrations or experiments, but successful transfer to contractors for integration and production. Government’s job isn’t to compete with industry, but to gain its own capabilities such that it can facilitate a thriving developmental ecosystem.

In the OMFV case, I would say that the Army shouldn’t have a competitive design itself. That’s biting off too much from the apple. Instead, it should consider its own continuous level-of-effort prototyping as a separate capability that continuously interacts with programs like OMFV, but doesn’t look to replace a prime integrator. This, I believe, reflects the heritage of the arsenal/bureau system in the 1910-1960s. Without a doubt, they produced some useful technologies.

Even if the government produces nothing tangible, it provides the overall benefit that the government can better understands what its contracting for. Eventually, as government offices start developing and transferring components and then subsystems, it can start taking a more active role in setting standards (MOSA). A higher level of sophistication would then be orchestration of competitive subsystem developments in real time — not doing the integration itself, but partitioning contract tasks across component and time rather than relying on the prime contractor’s teaming arrangement.

Be the first to comment

Leave a Reply