Mobile Protected Firepower 2.0?

The United States Army is starting the development process for its Mobile Protected Firepower program — essentially a light, but powerful tank that can be airlifted into combat. The Army hopes it goes better than many Army acquisition programs before it. For two decades, Army programs have struggled to make their way through the acquisition process or been cancelled. For the Mobile Protected Firepower program, the Army is trying to revamp its acquisition process and prove that it can get better results. The reforms have potential, but they may be difficult to implement.

Primarily, the Army is altering its requirements process by bringing in major stakeholders in the project before funding it. Input from Army acquisition professionals, the Army Tank Automotive Research, Development, and Engineering Center (TARDEC) , and Army Material Command was requested for the initial requirements planning. The Initial Capability Document — which essentially provides the military rationale for a new program, along with the relevant timeframe, desired effects, and range of operations — brought in the units that would be using the vehicle if successfully procured.

The Army is also apparently trying to bring in industry early as well, sharing its Capabilities Development Document with vetted industry members earlier than it has previously. The Army is apparently seeking only proven technology on the weapons system. It wants to avoid the problems with immature technology that have led to program cancellations and plagued the Ford-class aircraft carrier and F-35 programs.

This is smart, but the Army’s new approach still has issues. The Army was hoping to bring in industry to help write requirements during a recent innovation summit, but its own lawyers argued that their interpretation of the Federal Acquisition Regulations precluded that possibility. The Army claims it is working to take industry ideas into consideration anyway, but it won’t be clear whether this is helping or not until a major project succeeds or fails. The Mobile Protected Firepower program is going through iterations of requirements, with industry input in the various stages. That is certainly better than previous approaches to requirements, but the Army’s willingness to adjust its desires to industry’s abilities will remain a concern until the new system is proven.

Placing requirements development earlier in the process, and taking industry concerns seriously, could help change requirements from ‘wish lists’ to genuine practical needs for the program. Once the requirements are built into the program, it is in industry’s interest to claim that it can satisfy those requirements. If industry can more realistically inform the military of its capabilities before requirements are locked in, some of the recent struggles to produce immature and untested technology later in the acquisition process might be avoided.

But larger problems in the requirements process will be harder to fix. The requirements process suffers from the long timeline of the overall acquisitions cycle, with operational needs changing due to inabilities to bring some technology to production, new technology, and competitor capability. This can be seen throughout the Department of Defense. The Army’s Future Combat Systems was plagued with overly optimistic requirements and constant changes when they couldn’t be achieved. The F-35, which had its contract awarded in 1997, has been criticized over whether its stealth technology will be made obsolete by developments in China and Russia’s radar technology. The Department of Defense lowered the number of Littoral Combat Ships (LCS) it would purchase in part because of the inability to finish some of the critical technology and the relative weakness of its capabilities compared to potential enemy systems. The operational requirements were changed as well when it was found that the LCS was, “less capable of operating independently in higher threat environments than expected.”

If this new system for the Army creates more realistic requirements that don’t rely on not-yet-existing technology, it will shorten the acquisition cycle. With a shortened acquisition cycle, there will be less need to alter the requirements after acquisition has already started. Fixing the requirements process can save a lot of time and money. But this means getting realistic requirements throughout the whole acquisition process, and not just at the beginning of a program.


Originally published at niskanencenter.org on August 31, 2016.

Show your support

Clapping shows how much you appreciated Josh Hampson’s story.