In a word, I think the one thing that differentiates A&D programs from others is the level of "COMPLEXITY". There is complexity of the system/product being developed because of its size and inter-relationships of its component parts to satisfy a mission and objectives. As the size of a system increases, so does its complexity and the need to manage its interfaces and interactions. Design and manufacture by a prime contractor with a team of subcontractors and suppliers adds complexity and the need to manage interfaces. Complexity is also added because the system under development generally is only a concept although technically feasible and change is expected over time. Federal Acquisition Regulations (FAR) requirements add complexity to the conduct of the program. In addition, we have identified 23 Knowledge Centers (KCs) on the A&D SIG website that are involved with A&D PM. These KCs are not stand-alone processes and when used on a program, they are all inter-connected. This is only a partial list, but you get the idea. Every person, process, tool and piece of documentation used on a program is inter-connected to come degree in order for the end-product/system to meet its objectives.
So, an A&D program is very complex with a lot of risk and uncertainty. It is initiated with much risk and uncertainty so these need to be managed and changes to baselines are inevitable. These are universal attributes of any A&D program whether it is initiated by the US Department of Defense, or any US or foreign entity. In the product development process, this is managed with the application of “systems engineering” which prompted me to investigate how it is used. The following definition of a “system” is from the ICOSE website:
http://www.incose.org/practice/fellowsconsensus.aspx
“Definition of a system:
A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected (Rechtin, 2000).”
I find it interesting (and very enlightening) that this definition does not specify a "system" being limited to a collection of hardware and software. Therefore, it could be applied to a "program" as a "system". The last sentence is especially important – “interconnections” is the key!! This requires management of “integration” aka “interface management”, which is missing from the PMBoK.
So, in conclusion of this posting, I believe any future A&D process or procedure should be able to be universally applied to any program, not just US DoD. It should address how to initiate, plan, execute and control a complex program with high uncertainty and high risk. It should describe how to manage the "interconnections" in all aspects of the product and program baselines and how to manage changes to them efficiently over time.