In theory, an acquisition program, be it aircraft, ship, software, or whatever, lays out a set of requirements, locks them in, designs the product to those requirements, and then produces the product. In reality, the Navy constantly alters the requirements all the way through the design and construction phases which leads, inexorably, to massive cost overruns and schedule delays. However, for the sake of this discussion, we’ll ignore that reality and consider the ideal acquisition process.
Having produced a product that meets the requirements, that product then enters service and, if the requirements were well designed, the product winds up being reasonably useful and productive because it meets requirements that are relevant to the fleet’s needs – a win all the way around.
Let’s consider requirements. Even in the best case, where the requirements were reasonably and logically established and meet actual needs, the needs – and hence, requirements – begin changing the day after they’re established. Why? This isn’t a trick question. The answer is obvious. Threats change, circumstances change, technology changes, geopolitical strategies change, and, therefore, the needs of the fleet change on a daily basis. The longer the time span from the locking in of the requirements to the time of entering service, the greater the deviation will be between the design requirements and the current requirements. Thus, the longer the time span from the locking in of the requirements to the time of entering service, the more pronounced the loss of applicability and usefulness of the product will be relative to the current requirements.
The blindingly obvious conclusion from the preceding is that we must do everything possible to minimize the time between locking in of acquisition requirements and entry into service. The shorter the time span, the greater the usefulness of the product.
To illustrate what happens when we fail to minimize that time span, consider the example of the F-35. Conceptual design and, hence, the process of establishing requirements, began as far back as 1993 with the establishment of the Joint Advanced Strike Technology program and prototype construction contracts were awarded in 1996. Thus, requirements were being locked in as early as the early to mid 1990’s. It is now thirty years later and the F-35 is just now entering service and has yet to achieve full combat status as provided by Block 4 software and a functional ALIS support program. Without a doubt, requirements have changed drastically over the intervening thirty years. What might have been an applicable, useful, and capable aircraft if it had been fielded twenty years ago has become a marginally applicable, barely useful aircraft that is ill-suited for the Pacific/Chinese challenge we face today. The time span between establishment of requirements and entry into service was too long for the aircraft to retain applicability and usefulness.
Now consider the example of the WWII F6F Hellcat. The contract for the prototype XF6F-1 Hellcat was issued in 1941 and the Hellcat entered fleet service two years later in 1943. The Hellcat was relevant and useful because the time frame between requirements and service was short.
Well, sure, the Hellcat could be quickly fielded because the technology was so primitive. Okay, how about a more modern example?
The Grumman F-14 Tomcat contract was issued to Grumman in 1969. First flight occurred in 1970 and Initial Operating Capability was declared in 1973. First deployment occurred in 1974. The Tomcat went from design (requirements locked) to deployment in 5 years. The Tomcat was relevant and useful because the requirements were still applicable thanks to the short time frame. The Tomcat was every bit as advanced for its time as the F-35. We’ve just forgotten how to produce aircraft (or anything else!) in short, relevant time frames. Can we still produce aircraft quickly? Of course we can! See, “How To Build A Better Aircraft”.
Lest anyone think that the lag between requirements and service is only an aircraft issue, the same concerns apply to ships.
The LCS, for example, was conceptualized in the 1990’s and requirements were locked in in the 2003-4 time frame. Now, 12-17 years or so later, as the vessels are entering service and the Navy looks to actually employ the ship, the requirements have changed so much that the LCS is nearly useless - of course, a total absence of useful modules doesn’t help! The 12-17 year lag between requirements and entry into service proved too long and the ship had no role by the time it was completed. The littoral combat role it was intended for had vanished to be replaced by a Pacific/China focus that the LCS was entirely unsuited for.
Another example is the Zumwalt whose conceptual origins date back to the SC-21 program in 1994 and, subsequently, the DD-21 program whose requirements were being locked in via a 1997 Operational Requirements Document and an Advanced Development Memorandum. Many of these requirements eventually carried over to what became the Zumwalt program. Final requirements were set by 2005 when the detailed design phase began. Now, 16 years later, the Zumwalt, the lead ship of the class, has just completed the final combat systems installation and is undergoing final testing. There’s no rush, of course, because the ship no longer has a purpose and the Navy is relegating the ship to experimental unmanned squadron testing – of course, the utter failure of the Advanced Gun System didn’t help! The 16-27 year lag between requirements and entry into service proved too long and the ship had no role by the time it was completed. The littoral combat/bombardment role that the Zumwalt was intended for had vanished to be replaced by an open ocean, naval warfare need directed towards China and for which the Zumwalt was unsuited.
What we learn from this is that the time between requirements and entry into service is, arguably, the most important factor in determining whether a ship or aircraft will prove useful. An asset, no matter how well conceptualized and designed, will lose relevance with every day that passes after the requirements are set. It is imperative that the lag between establishment of requirements and entry into service be minimized. We need to recall the example of the F-14 development time frame and relearn how to quickly produce new ships and planes.
Contemplating the various programs that have come and gone over the last few decades, a very good argument can be made that any lag period that exceeds 5 years from requirements to service will result in an asset that is highly likely to have lost the majority of its usefulness. Recognition of this constraint mandates that we abandon our fascination with attempting to build in non-existent, fantasy level technology and, instead, stick to existing technologies – a theme ComNavOps has repeatedly preached.